What’s the best way to test an API for vulnerabilities? RTFM

If you’re a child of the 80s like me, you may have had the distinction of being the only one in your house who knew how to program your VCR. My motivation was strong. Clarinet lessons were interfering with my favorite show, the A Team. I was the one in the family who handled most AV responsibilities at the time and I was confident that this would be a simple task. Nope. After fighting with the VCR for 20 minutes, I went digging through the stack of manuals in our kitchen drawer and found the one that said Sylvania. Five minutes later, I had the weekly recording set up and took comfort in knowing I’d never miss another episode.

These days, reading a manual to do anything seems practically medieval. I can now record my favorite shows with a click of my Roku remote. And thanks to a trend Apple started long ago with the iPhone, most of the consumer electronics that I buy don’t even come with a physical manual. And yet, there are still many cases where having accurate and complete documentation pays big dividends. API Security testing happens to be one of them.

Know before you test
But why be so specific? Isn’t good documentation useful for any software security testing, not just APIs? Of course! Having deep knowledge about how a web application functions, how it’s built, and even how it’s deployed is a huge advantage for anyone wishing to perform security testing. Armed with this knowledge, a security engineer can model specific threats and formulate a custom test plan that covers all components of the application. As a result, the testing can be far more effective than if the tester had minimal knowledge of the application.

So why aren’t all web applications tested this way? In short, because this approach takes too much time and requires too many people. Developers have little time to produce technical documentation and even if they did, security engineers are so vastly outnumbered by developers they’d struggle to keep up and take advantage. In reality, most security teams rely on traditional DAST scanning tools (often based on something like OWASP Zap) that utilize a one-size-fits-all library of dynamic tests against their applications. While these tools can be useful in finding common vulnerabilities, they are usually accompanied by a high volume of false positives and fail miserably at finding most of the top API vulnerabilities.

OpenAPI as a boon for security
Speaking of APIs, let’s get back to how they’re different from web applications. One major difference is that web and mobile applications are heterogeneous by nature. Because there’s no standard approach to building a web application, there’s also no standard way to document how they work. In contrast, REST APIs are highly structured and adhere to various RFC standards. This has led to the emergence of a widely adopted documentation standard that describes every aspect of an API called OpenAPI Specification (OAS) or more commonly Swagger. The original purpose of OAS was to provide a human and machine readable language for producers to share information about APIs with consumers. In fact, producers that publish Swagger files early can enable consumers to build integrations at the same time that the API is being built.

Based on the points in the previous section, you can see why OAS should be viewed as an absolute gift for security testers. Along with the many business benefits of having good API documentation, the value that this provides to security teams can’t be overstated:

• Developers can leverage a common framework for communicating how an API works to security testers, avoiding miscommunication and ambiguity.
• Security testers can craft precise tests customized to each API that detect truly exploitable vulnerabilities without generating false positives.
• Automation can be leveraged to build and execute tests with stage gating to ensure APIs meet minimum security and quality standards before moving to production.

Despite these significant benefits, many AppSec teams continue to use their legacy DAST tools to test APIs. I get it – these teams are already stretched and are not looking to add yet another tool that might introduce more false alarms and slow their devs down. At a time when CISOs are looking for tool consolidation, a specialty API security testing tool might not make the cut. However, those organizations that view APIs as a large and fast growing attack surface with minimal governance and control are ready for a better approach to security testing.

At 42Crunch, we’re dedicated to helping customers drive security into their API development lifecycle. We have been evangelizing the use of OpenAPI Specifications for testing and protecting APIs for years and have seen our customers make huge strides in their API security programs through continuous and increased adoption of our approach. If you’re ready to begin this journey, we’d be proud to help.