DevSecOps and APIs: How to Automate Your API Testing

According to Gitlab surveys, DevSecOps is now the single most popular SDLC methodology for devs. Given the abrupt rise of microservices, APIs, and Kubernetes, finding ways to shift testing left and create a continuous cybersecurity ecosystem is paramount in today’s hyper-aggressive threat landscape. Forty-nine percent of organizations have delayed moving an app into production due to container security concerns, and a surprising 16 percent of organizations say their APIs are under attack daily. On top of this proverbial ocean of cybersecurity threats, there’s a continent of consumer expectations threatening successful launches.

Two-thirds of companies compete solely on the basis of customer experience, and 33 percent of customers will leave a brand they’re loyal to after a single poor experience.

To win in today’s SDLC, companies are embracing automated testing, DevSecOps principles, and shift-left methodologies. But there’s a bump in the road. As container usage continues to increase and cloud architecture rapidly replaces traditional in-house systems, ensuring your APIs stay functional, secure, and relevant can be challenging. The average company is managing over 400 APIs, with nearly 8 percent managing over 1,000. That’s a lot of fail points. And keeping those APIs in tip-top shape requires robust automated testing strategies.

But how do you automate API testing?

Understanding Automated API Testing

Trying to pin down exactly what to test on APIs will leave you with a relatively long list. You need to verify schemas, check for bugs, validate keys, etc. So, instead of diving down into each, let’s simply discuss how to test one small aspect of your API, your HTTP request commands.

APIs request commands require five layers of testing. Since APIs use 5 unique HTTP request commands, each of them needs to be tested for accuracy. These include:

1. Put
2. Get
3. Post
4. Delete
5. Patch

Each of these types of request commands pulls back what’s called an HTTP "status code." In general, you want to receive HTTP codes between 100 and 399. If you start receiving 400 – 599 status codes, there’s an error of some sort. These errors may involve security vulnerabilities or user experience hiccups that need to be corrected. So, testing APIs is actually an incredibly simple process. You send some commands, receive some status codes, and check to see if you have any errors.

But there’s a problem.

You likely have hundreds of APIs. And that number is likely increasing year-over-year as you modernize, containerize, and "cloudify" your IT architecture. The feasibility of checking each of those commands on a set schedule using manual throughput is unimaginable. In other words, automation is really your only choice. You can’t afford to set your security team aside each day to run manual HTTP checks on each API, and you certainly can’t afford to offload it onto your sysadmins who are likely already struggling with infrastructure spins in your containerized ecosystem. They’re already trying to wade their way through ingesting an IaC solution. APIs testing needs to be automated.

Why Automate API Testing?

So far, we’ve only discussed the stick (i.e., you can’t possibly manually test each API daily, weekly, or monthly without significant costs and time sinks). So what about the carrot? According to the 2021 GitHub survey, organizations with automated, shift-left testing are more likely to feel comfortable with their security ecosystem and less likely to spread blame across teams. In fact, 30 percent of devs now believe AI/ML is the most important skill for their future, and DevSecOps teams are running more DAST, SAST, API, container, and dependency scans than ever. Automated API testing works, and it significantly reduces strains on your SDLC and teams.

How Do You Automate API Testing?

Most organizations automate API testing using:

• Postman
• Newman
• Custom-built solutions

Both Postman and Newman automate API testing, but Newman is a Cl version of Postman. You can also ingest a custom solution, though the feasibility of this depends on how many APIs you’re running. If you have under 1,000, it probably makes more sense to use Postman or Newman. Of course, there are other solutions like TestProject, Paw, and SoapUI, but Postman is the most popular solution on the market.

Using Postman is relatively straightforward. You set up an account, input your API, and test it against various HTTP requests. You can even set up collections (which are groups and sequences of tests for APIs) and run them on a regular basis. In other words, Postman makes it easy to quickly send HTTP requests to your APIs and verify them. If Postman sees an error on the return, it shoots it to your team. You can integrate it with Jenkins to add it your CI/CD workflows, and you can easily monitor tests using Postman’s monitoring tool or via the Newman CL line.

That was simple, right? Of course, there are some obvious concerns. To use Postman effectively, you need a CI/CD ecosystem that supports shift-left testing and DevSecOps. Don’t worry! We can help.