Shifting Your Security Testing Left

How Your Development Team Can Take Part in API Security
  April 25, 2019

Recently, SmartBear presented “Shifting Your Security Testing Left: How Your Development Team Can Take Part in API Security.”

As teams are challenged with creating and releasing software faster than ever, the conversation often turns to shifting left in testing . However, while the overall quality of an application is a worthy reason to include testing sooner in the software development life cycle, security is another issue that demands our attention -- and it's often overlooked.

While we continue to make strides in quality, security should be top of mind in order to create a safe and trusted experience for our users, which is where API security testing comes into play.

So, what is API security, why does it matter, and how can teams make a point to prioritize it? We discuss DevSecOps and provide insight into how teams can make more room for security in the following webinar takeaways:

More Connections, More Vulnerabilities

As we develop microservices, we’re seeing many more connections with internal and external APIs. The more connections, the more vulnerabilities there are, which is where API security testing comes into play.

API security is protecting the APIs you build and consume from nefarious use. Because businesses transfer data and connect services via API, they are especially prone to attacks.

In fact, Gartner predicted that, by 2022, API abuses will be the most frequent attack vector resulting in data breaches for enterprise web applications.

Right now, we often see security as a siloed team, just as we used to see QA, development and operations separated. We need to see a shift to DevSecOps and an emphasis on embedding security into the CI/CD pipeline.

The Basics of Security Testing

There are a few basic, commonly known practices that every organization should follow when it comes to security. These should make of the foundations of your DevSecOps strategy:

  • Only legitimate users should be able to access the system - Authentication of a user is going to look different at the UI layer than the API -- it won’t just look like a simple login with a username and password. You need to be sure that only legitimate users should be able to access the data once their logged in. While this may seem straightforward, forgetting it can cause a lot of harm.
  • The system doesn’t allow users to do more than they should - When we are testing at the API layer, we often test what the system can do. However, we also want to make sure that it doesn’t allow users to do more than they actually should, which can create security vulnerabilities.
  • Confidential data can only be seen by intended users - You want your users to trust that their data is safe with your organization. Not everyone should be a “super user” -- there should be a limit on who can see what data, and even those users that have more access should only be able to access the information they need.
  • Transaction information is protected - If you’re asking users to input financial information for processing, it will always create a risk for identity theft. If you have an API breach, having two-factor authentication can help, especially with transaction information.

How Developers and QA Can Help

After understanding the pitfalls, there are certain improvements we can make to the way we approach security from a development and QA perspective:

Defensive Programming - They say the best offense is a good offense, which is why defensive programming starts before the API is built. By proactively addressing security issues in the design of the API, the programmer must consider all the ways it could be missued or exploited during development. Using tokens, encryption and signatures, quotes and throttling, and an API gateway will all assist you in defensive programming.

Early Hardening - Early hardening happens during the SDLC and in the CI/CD pipeline to identify where testing can help improve security. It consists of running tests before your code hits production such as vulnerability scanning, security scanning, penetration testing, risk assessment, security auditing, posture assessment, and ethical hacking. These methods are intended to exploit bugs that could create security vulnerabilities before they’re found in production.

API Management - API gateways are program layers that sit in front of the API and acts as a single point of entry, and they can be critical to API security. This is especially useful when clients build with microservices and make use of multiple disparate APIs to decouple the client from the API. Additionally, API management assists with intelligent monitoring and throttling, centralized security audits, and version control.

Creating a strategy that considers all of these steps will help you be more intelligent in secure API development.

Building a DevSecOps Strategy

How can DevSecOps be adopted by teams and baked into the CI/CD pipeline in a way that is pratical for teams?

SecurePro, a feature in SoapUI Pro, can help organizations take a giant step forward in their DeSecOps journey, enabling them to embed hardening security test right into their CI/CD pipeline with minimal effort and maximum scalability.

SecurePro allows any user to run a dynamic scan and test against any API endpoint in a matter of minutes. It also comes with a test runner that makes embedding security testing into the CI/CD extremely simple.

Find out more about API security, watch the full webinar. To find out how SoapUI Pro can help you achieve DevSecOps, check out the demo below: