If you’re responsible for web application security, then you know how important it is to test application programming interfaces (APIs). But do you know how to use the guidance provided by OWASP as part of your API security testing blueprint? In this article, I’ll show you how!
What is OWASP and what do they offer for API security testing
OWASP is the Open Web Application Security Project. They are a worldwide not-for-profit charitable organization focused on improving the security of software.
One way they do this is by providing resources and guidance for testers and developers to improve manual testing around functional tests, performance tests, and security testing.
It can even help to automate testing within your CI CD pipelines to better streamline the process in your test environment.
For example, they offer the OWASP API Security Top Ten. This project outlines the ten most common attacks against APIs and how to prevent them. At the bare minimum, every API owner should strive to ensure that they adequately conduct API testing to verify they defend against application security vulnerabilities that are easy to discover and are defined in this top ten list.
They also offer the OWASP Application Security Verification Standard (ASVS). This project provides guidance on what should be included in a comprehensive web application security testing program. In fact, at its core, the ASVS framework defines several security verification levels, whereas the OWASP API Security Top Ten list forms the bases for the most basic assessment level only.
Both of these projects can be used as blueprints for your own API security testing efforts!
Getting started with the guidance in the OWASP API Security Top 10 list
As mentioned earlier, all APIs should try to adequately defend against security issues described on the OWASP API Security Top 10 list.
You will not be able to even meet the base assessment requirements of the ASVS without it. So let’s discuss these classes of vulnerabilities, and how to approach your API security tests.
If this is new to you, I highly recommend you consider reading my Beginner’s Guide to API Hacking first. It will help you understand some of these vulnerabilities better.
In any case, let’s explore the top ten API security vulns.
#1 – Broken Object Level Authorization
Broken object level authorization (BOLA) is when an attacker is able to bypass the security controls that are put in place to restrict access to objects. This can allow the attacker access to data or functions that they should not have access to by understanding how to manipulate explicit API routes.
Read more on GitHub on how to test for this.
#2 – Broken User Authentication
Broken user authentication allows attackers to gain access to an API with improperly validated credentials. There are many ways that you can exploit broken authentication, including guessing passwords, abusing leaked API keys, stealing session IDs, or exploiting vulnerabilities in the API authentication process itself.
To learn how to abuse authentication mechanisms and improve your API tests, check out the guidance published by OWASP on the matter.
#3 – Excessive Data Exposure
Excessive data exposure can occur when an API returns too much data to the client. This can include sensitive information such as user information, passwords, or credit card numbers. It can also include sensitive configuration elements or other proprietary information.
An attacker can use this information to gain a competitive advantage or to launch a more sophisticated attack against the API or its users. To test for this, you should define test cases that try to access as much data as possible through the API calls. You should also look for any fields in the response that are not necessary for the function that is being performed.
You can read more about this in the Github repo for the top 10.
#4 – Lack of Resources & Rate Limiting
Quite often, modern application architecture for APIs don’t impose any restrictions on how much, or how many, resources can be requested by an HTTP client. This can negatively impact the performance of the API and can lead to abuse in things like bruteforcing the authentication process of the API server.
Learn more about detecting these security issues in the OWASP API Security Top Ten guide, and how to improve your performance testing.
#5 – Broken Function Level Authorization
One common way for attackers to gain access to restricted data or functions is through broken function level authorization. This occurs when the security controls that are put in place to restrict access to specific functions are not properly implemented.
This type of vulnerability can be difficult to detect, and can often go undetected for long periods of time. It is important for API owners to properly test their systems for these types of vulnerabilities. To learn how to look for potential API security issues around this you can check out this guidance.
#6 – Mass Assignment
Rapid iteration of APIs within modern software development leads to generic object reuse. When testing for mass assignment vulnerabilities, you should try to inject illegitimate values into the API. This can include data that is not authorized or random data that is not intended for the current function.
You can try this by sending a request to the API that includes invalid input. You can also try to tamper with the input before sending it to the API. This can help you identify any vulnerabilities that may exist in the mass assignment process.
You can check the OWASP guidance for more information on mass assignment, and what you can check for when testing APIs.
#7 – Security Misconfiguration
Security misconfiguration is one of the most common types of vulnerabilities that exist in web applications. It can be caused by errors in the configuration files, mistakes made during the deployment process in the CI CD pipeline, or by vulnerabilities in the software itself when security teams don’t know how the API works.
Security misconfiguration can allow attackers to gain access to sensitive information or take control of the system. It is important for API owners to properly test their systems for these types of vulnerabilities, especially when offloading configuration to a third-party API gateway. To learn how you can run tests against your REST APIs to ensure you are maintaining API security check out this guidance.
#8 – Injection
Injection vulnerabilities can occur when an API accepts input from the client that is not properly sanitized. This can allow the attacker to inject illegitimate information into the system, which can be used to execute malicious code or access sensitive data.
To test for injection vulnerabilities, you should try to send a request to the API that includes invalid input. Your test cases can also try to tamper with the string inputs before sending them to the API. Many testing tools like BurpSuite or ZAP can really help here.
Check out some of the example injection scenarios OWASP discusses for more information.
#9 – Improper Assets Management
With the agile development processes of today, it’s common for API owners to manage their assets improperly. This could be through poor documentation as endpoints change, weak access controls to data between versions, or even the lack of maintenance and patching of old APIs or systems that aren’t part of an automated CI CD pipeline.
Check out some of the attack scenarios in OWASP’s top ten guidance on the matter.
#10 – Insufficient Logging & Monitoring
API owners should test their systems for insufficient logging & monitoring vulnerabilities to ensure that they are able to track and monitor all activity that occurs on their systems. Without proper logging & API monitoring, it can be difficult to track down the source of an attack or identify any suspicious activity.
The attack scenarios and additional resources included in the OWASP guidance about this are helpful. You can check it out here.
How to use the OWASP API Security Top Ten in your testing blueprint
Now that you have a good understanding of the top ten vulnerabilities, how exactly can this help you?
To start with, understand that these are the most common vulnerabilities found in API endpoints. That means at the bare minimum you should be building an API security testing process that includes test definitions for these vulnerabilities.
The problem is, the top ten isn’t very prescriptive in exactly HOW to do that, or what testing tools you should use.
So what do we do? It ends up that while the top ten is helpful in identifying the most common vulnerabilities we need more structure around how to test for them. And this is where the Application Security Verification Standard (ASVS) comes into play.
Let’s talk about that.
Using ASVS as the backbone of your API security testing blueprint
The Application Security Verification Standard (ASVS) was originally developed to normalize how people conduct and receive application security tests. Up until it was published, there was no agreed-upon methodology in the industry on what makes up successful security tests. ASVS changed that.
It’s now possible for application penetration testers to follow structured guidelines of what should be tested, and how. It also strengthens meaningful conversations between penetration testing firms and their clients on exactly what level of assessment needed to be completed during an external engagement.
It gets everyone on the same page. And you can leverage ASVS in your API testing in a very similar manner to test for potential vulnerabilities.
The Basics of ASVS
The ASVS establishes a framework of security requirements and controls that focus on defining the functional and non-functional security controls required when designing, developing, and testing modern web applications and web services.
There are two main goals of the framework:
- To help organizations develop and maintain secure applications.
- To allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.
To provide a baseline for security testing that can be used by both pentesters and application development teams, the ASVS defines three security verification levels, with each level increasing with depth:
- ASVS Level 1 – Basic is for low assurance levels and is completely externally penetration testable. Testing at this level can be done with a combination of automatic and manual methods without access to source code, documentation, or developers. This is where the OWASP API Security Top ten fits in.
- ASVS Level 2 – Standard is for applications that contain sensitive data, which requires protection and is the recommended level for most apps and APIs. This level requires access to documentation, source code, configuration, and the people involved in the development process.
- ASVS Level 3 – Advanced is for the most critical applications – applications that perform high-value transactions, contain sensitive medical data, or any application that requires the highest level of trust. This level requires a more in-depth analysis of architecture, coding, and testing than all the other levels.
Building your API security testing blueprint
The ASVS includes specific guidance for API testing in section 13 called API and Web Service. It describes how API security testing works to ensure that a verified application that uses trusted service layer APIs (commonly using JSON or XML or GraphQL) has:
- Adequate authentication, session management, and authorization of all web APIs.
- Input validation of all parameters that transit from a lower to higher trust level.
- Effective security controls for all API types, including cloud and Serverless API
What’s nice is that OWASP describes clearly how to test for this, and links it to the corresponding Common Weakness Enumeration (CWE) number published by Mitre which you can leverage in your report to improve the developer experience as they fix vulnerabilities you find in your API security tests.
Let’s look closer at the guidance specific to API security testing published in ASVS that you can use as part of your blueprint.
V13.1 Generic Web Service Security
- 13.1.1 – Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks. This relates to CWE-116, Improper Encoding or Escaping of Output.
- 13.1.3 – Verify API URLs do not expose sensitive information, such as the API key, session tokens, etc. This relates to CWE-598, Use of GET Request Method With Sensitive Query Strings.
- 13.1.4 – Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions. This relates to CWE-285, Improper Authorization.
- 13.1.5 – Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type). This relates to CWE-434, Unrestricted Upload of File with Dangerous Type.
V13.2 RESTful Web Service
- 13.2.1 – Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources. this relates to CWE-650, Trusting HTTP Permission Methods on the Server Side.
- 13.2.2 – Verify that JSON schema validation is in place and verified before accepting input. This relates to CWE-20, Improper Input Validation.
- 13.2.3 – Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks. This relates to CWE-352, Cross-Site Request Forgery (CSRF).
- 13.2.5 – Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. This relates to CWE-436, Interpretation Conflict.
- 13.2.6 – Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits. This relates to CWE-345, Insufficient Verification of Data Authenticity.
V13.3 SOAP Web Service
- 13.3.1 – Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place. This relates to CWE-20, Improper Input Validation.
- 13.3.2 – Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service. This relates to CWE-345, Insufficient Verification of Data Authenticity.
V13.4 GraphQL
- 13.4.1 – Verify that a query allow list or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used. This is related to CWE-770, Allocation of Resources Without Limits or Throttling.
- 13.4.2 – Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer. This relates to CWE-285, Improper Authorization.
Wrap-up and final thoughts
I hope I’ve been able to give you a glimpse into a way to leverage OWASP guidance to help build your own API security testing blueprint.
By understanding your API usage you can use the right API security testing tools to ensure that you verify that the OWASP API Security Top Ten vulnerabilities found in typical APIs don’t exist in your projects.
That’s the WHAT.
Then by applying the descriptive guidance provided in the ASVS, you make it easier to define the right tests and testing methodology to ensure you have the right coverage.
That’s the HOW.
Combined, they provide the foundation for a great API security testing blueprint. Use it.
Found this interesting? Over the years I’ve been collecting a ton of resources around API security testing and hacking. I’ve consolidated all that into the most comprehensive guide of online resources out there.
You might find it useful.
You can download my FREE PDF of the Ultimate Guide of API Hacking Resources here.
Enjoy!
