APIs Exposed by Manual Penetration Testing
You’ve got your road map. You’ve got a backlog of features. You’ve got bugs to fix. You’re pushing new code to staging nightly. Updates are moving to production daily. And your pen testing program? Well, the next test is scheduled three months from now.
The most egregious exception to agile/lean development and continuous integration/continuous delivery (CI/CD) automation is the penetration test, or, the pen test. For APIs, the process of pen testing is still manual. It relies on humans to understand your code, craft tests to identify vulnerabilities, execute the tests and then interpret the results. This manual approach is, by definition, slow (weeks, not minutes), reactive (often a once- or twice-a-year effort), and costly. Often, the main objective isn’t even security – it’s getting the pen test report to hand to auditors and clients to demonstrate the robustness of security programs.
Meanwhile, organizations are trying to operate at the speed of DevOps. New code gets pushed to production every day. So, how can companies afford to wait for manual security? They can’t. That means tons of defects do make it into production, and those turn into serious breaches (think Venmo, Starbucks, the IRS, United States Postal Service and many, many more).
With the move towards API-driven applications and functionality, the challenge of security testing code gets even harder. There are three main issues: coverage, scale and speed.
Coverage of APIs
The ultimate goal of security testing is to make code less vulnerable to attack, misuse and exploits. To achieve this, testing MUST cover every corner of the API’s capabilities, not just what’s expected. Corey Ball, author of the upcoming book “Hacking APIs” puts it succinctly, “You can design an API you think is ultra-secure, but if you don’t test it, then a cybercriminal somewhere is going to do it for you.” So, the testing scheme needs to look at every API endpoint and method, and consider all the possible ways your API can be used, not just the most likely.
Scale
The coverage problem leads right into the scale problem – how do you create test scenarios to cover the entire range of API functionality? Consider a relatively lightweight API with, say, 50 endpoints. Each of those endpoints can support multiple POST, GET, PUT and DELETE methods. You’re already up to ~250 endpoint-method permutations. And then, consider the myriad API breach categories – the OWASP API Security Top 10 is a great starting point, especially the top 5:
- Broken Object Level Authorization
Translation: Are API users restricted in what data they can access? - Broken Authentication
Translation: Is there strong authentication to ensure users are legitimate? - Excessive Data Exposure
Translation: Does the API only return needed data, or does it return much more? - Lack of Resources & Rate Limiting
Translation: Will the API allow users to query by the thousands/millions? - Broken Function Level Assignment
Translation: Can users execute any operation they want, or just those they need?
Testing needs to cover all these permutations and scenarios, otherwise you’re just hoping the vulnerabilities don’t get discovered by someone else.
Speed
Speed measured in CI/CD time means seconds or minutes. When fixes and new functionality need to move to production, testing can’t delay progress. But given the complexity of APIs and the breadth of possible scenarios to cover, testing speed is more realistically measured in weeks or months.
Organizations need to rethink how they approach testing and drive more automation, more integration and more velocity. Here’s some guidance to get started.
1. Document your APIs
If you’re going to achieve any level of test automation, you’re going to need a properly documented API to start. Fortunately, this isn’t complicated, and doesn’t require excessive detail. The OpenAPI specification is an industry standard for documenting APIs, though you can also get there with Swagger files, Postman collections, RAML or other documentation. If you’re using an API gateway like Apigee, Mulesoft, Kong – they’ll create the API definitions automatically.
2. Automate API test creation
Given the size and complexity of APIs, manual test creation cannot scale to cover every endpoint, method and attack scenario. But with AI and ML advances, it’s now feasible to automate test creation. Make sure tests cover the top 5 OWASP recommendations, as these represent the vast majority of attack vectors for breaches.
3. Integrate into CI/CD
Testing should be another automated step in the CI/CD pipeline. Orchestrate testing into the pipeline to ensure every new code release gets pressure tested. Have the test automation tool reevaluate the API code on every release, and add missing tests for any changes in the API. Finally, failed tests should automatically trigger tickets in your development workflow tools – JIRA, ServiceNow, etc. – and include all the necessary details a developer would need to understand and fix the issue.
None of this is to say pen testing isn’t important. Actually, it’s critical – even more so with APIs, as they can provide even greater access to sensitive data, at incredible speed. That’s why pen testing must modernize, as well, and eventually be completely automated, to cover every corner of APIs. With automated pen testing, we can focus more energy on fixing issues than finding them – or discovering them after a breach.
