Application programming interfaces, or APIs, are software interfaces that allow computer programs to communicate with one another to perform services without needing to know the internal details of how the other system functions. As application development shifts to the cloud, APIs have become indispensable, allowing us to connect microservices and conveniently take advantage of software, platform, and infrastructure services. As API use increases, however, attackers have come to see APIs for what they are, a vulnerable entry point to access our data and the backend of our operations. According to Salt Lab’s State of API Security Report, API attack traffic increased by 681% in 2021. API security is now an undeniable facet of application security, and as such, the same standards of testing must be applied.
Types of API Security Testing
Dynamic API Security Testing
With today’s focus on continuous integration and continuous delivery, application security testing has shifted left and become integrated into the app development pipeline. Static and dynamic testing tools are used to identify vulnerabilities in application code throughout the development lifecycle. As APIs have grown in popularity, many of these tools have expanded their capabilities to include API testing. Static Application Security Testing (SAST) can be applied to APIs to analyze the source code. However, these tools are not always designed to identify API ingress points, and they are language specific, meaning you will need to use a tool that matches the language your API is written in. Some legacy Dynamic Application Security Testing (DAST) tools also do not support APIs, but for the most part, DAST tools can be used to run active tests against your API endpoints, simulating the attacker’s perspective. SAST and DAST tools are a great place to start for API testing.
Software Composition Analysis
Today’s applications increasingly rely on open-source code libraries, and APIs are no exception. Software Composition Analysis (SCA) tools are used to map dependencies in your APIs and identify known vulnerabilities. These tools can help you keep your open-source code updated but should be used in conjunction with other types of testing tools, as they do not address proprietary code bugs.
Interactive Application Security Testing (IAST)
Interactive Application Security Testing (IAST) tests your application for vulnerabilities while in use, either by an automated or human tester. It essentially combines SAST and DAST to give the benefit of access to all of the code, with the additional context of runtime information, to reduce the number of false positives. It can identify a vulnerability while the code is being executed and locate the place in the code where that vulnerability is located. IAST does require building test suites and may slow down your CI/CD pipeline. IAST is a good option for testing APIs that are already in use.
Feedback-Based Fuzzing
Fuzzing is a type of testing in which inputs are provided to an application to see if any fail the program. The goal is to find bugs before an attacker does. These inputs can be random, a kind of brute-force fuzzing, but in the case of feedback-based fuzzing, an algorithm is used to increase the amount of code tested and evolve with results. Fuzzing is helpful for testing unexpected edge cases with fewer false positives.
What to Test For
Testing tools such as the ones discussed above are great for identifying problems in your code, but they are not always able to identify all vulnerabilities. Just like in any other facet of your vulnerability management program, penetration testing is required to fill in the gaps and simulate attacker behavior.
In 2019, OWASP released a list of top ten API vulnerabilities. This list can serve as a checklist for manual testing as these are the issues that are most commonly exploited, and not all of them can be found with scanning tools.
- Broken Object-Level Authorization: BOLO can’t be identified by automated testing tools, which means that you will need to test this manually. You’ll need to experiment with passing IDs in the URL or as part of the query parameters, essentially penetration testing by mimicking the attack, to see what the API returns. API developers should be aware of this vulnerability so they can identify it during the code development process through regular code and architecture reviews, as well as review of API request logs.
- Broken User Authentication: Make sure that the API has protections against brute force attacks, that a user is not able to bypass the login procedure, and that passwords are not sent in clear text. Test to make sure that session tokens generation is random, tokens are encrypted, the hash is correct, and a 404 error is returned if the session token is removed or changed.
- Excessive Data Exposure: This is hard for scanning tools to detect because it is difficult for them to differentiate between sensitive data that should not be returned and legitimate data without understanding the context. WAFs and API gateways can detect this if it matches a pattern that has been defined for it as sensitive data, but you may not want to block all sensitive data. To test this, again, it will require some pen testing. You will need to come up with some scenarios and simply analyze what the API returns.
- Lack of Resources & Rate Limiting: Fuzzing tools, as well as traffic analyzing tools, can come in handy here. You will need to make sure that the application is able to cope with large requests and that rate limiting is in place where appropriate.
- Broken Function-Level Authorization: The simplest way to test this is by experimenting with parameters while logged in as various user types and see if you get something other than a 403 error.
- Mass Assignment: Mass assignment occurs when submitting extra parameters such as “role”:“admin” would overwrite backend data to change your role to admin. To test for this, you can use a fuzzer to inject commonly used parameters into a request and observe the re
- Security Misconfiguration: Stress test your API and look at the 500 internal server error messages to make sure they don’t include debug information that should only be available to developers. Check to make sure that unnecessary HTTP methods are disabled and that cross-origin resource sharing (CORS) headers are appropriately configured. Check to make sure that unnecessary HTTP methods are disabled and that cross-origin resource sharing (CORS) headers are appropriately configured.
- Injection: Injection is not as big of a problem with APIs as it is in application security in general, which is why it is lower on this list than the application OWASP list. SQL and XSS injections can be partially avoided with modern frameworks and architectural patterns, however, it is not completely avoidable, so you should still perform injection testing with tools such as Burp Suite or Postman. so you should still perform injection testing with tools such as Burp Suite or Postman.
- Improper Assets Management: Make sure that you have an asset inventory and your development teams are mindful of old containers and outdated versions, particularly in a CI/CD pipeline.
- Insufficient Logging & Monitoring: Make sure that events such as authorization and authentication failures or input validation failures are being logged. Your API logging should be integrated with your SIEM for monitoring and alerting.
Tool Considerations
There are a number of API testing tools on the market which can make it difficult to know what to look for. Here are a couple of considerations:
- Developer friendly: With security shifting left, developers will be using these tools to identify vulnerabilities during development which means that the tools you choose should integrate with the CI/CD pipeline and include other developer-first features such as cURL command generation and the ability to run testing locally.
- Compatible with what you’re using: Make sure that the tools you use can support REST APIs, GraphQL, and SOAP APIs if you are using a combination of these across your environment.
- Upgrades from legacy tools: Modern API tools use technologies such as GraphQL introspection or OpenAPI Specification as opposed to relying on HTML spider or proxying production traffic to find API routes for testing. Similarly, modern tools will understand data-driven nodes to perform testing of underlying route as opposed to iterations, speeding up scanning.
RH-ISAC members have access to a community of cybersecurity professionals who share identified attempted exploits and can provide advice for strengthening your APIs against common vulnerabilities. Not an RH-ISAC member? Learn more about how being a part of the RH-ISAC’s member community can benefit you.
