Bas Dijkstra – Are you sure your APIs are secure?

For a long time, API security testing was seen as a job only for specialized security experts. It was thought to require deep knowledge and complex tools. While security specialists are still vital, there is much that regular development and testing teams can do to find security weaknesses.

You do not need specialized tools or deep security knowledge to start evaluating API risks. You only need the common API testing tools you already use, plus a healthy dose of curiosity, creativity, and common sense. These three traits are often what testers already bring to the table.

Getting Started with Basic API Security Testing

You can use standard API testing tools to uncover serious security issues. Tools like Postman, Bruno, Karate, or Rest Assured work perfectly well for initial security checks.

The main idea is simple: Do not just check if the API works correctly. Check how it responds when things go wrong. Treat every error or unexpected behavior not just as a functional bug, but also as a potential security risk.

Risk 1: Exposing Sensitive Implementation Details

When an API fails, it should give a clean error message, not a detailed technical breakdown.

The Security Risk:

If you try to use an API endpoint incorrectly (for example, by leaving a required parameter blank), a system might respond with a stack trace. A stack trace is a detailed error message meant for developers.

Hackers look for these messages because they reveal valuable implementation details, such as:

• The programming language being used (e.g., Java).
• The libraries used to build the back end.
• Sometimes, the specific version of a library.

If an attacker knows you are using a specific version of a library that has a known security vulnerability, they can easily exploit that weakness.

How to Test It:

Try to intentionally break the API by:

• Omitting required fields or parameters.
• Sending empty values.
• Sending unexpected data types.

If the API returns a technical stack trace, treat it as a major security vulnerability. The system should only return what the user needs to see, not internal implementation data.

Risk 2: Injection and Unsanitized Input

Injection is one of the biggest risks. It happens when an API accepts malicious data, stores it, and potentially executes it later.

The Security Risk:

APIs must properly sanitize all input. Sanitizing means cleaning or filtering data to ensure it is not harmful. If an attacker submits a piece of malicious code (like JavaScript or a SQL command) where a username or product description should be, the system might store that code.

If that stored code is later pulled up by a user’s web browser, the browser might execute the script. This is often called cross-site scripting (XSS). An attacker could use this to steal cookies, credit card data, or access keys.

A famous example of SQL injection happened when a student entered a name that was actually a malicious SQL command, which caused the entire student database table to be deleted.

How to Test It:

You need to check how your API handles potentially malicious content in every field it accepts (query parameters, JSON bodies, headers, etc.).

A powerful resource for this is the Big List of Naughty Strings. This collection contains thousands of input strings designed to test applications for handling unexpected or malicious input, including JavaScript snippets and SQL injection commands.

Testing Steps:

1. Identify all points where the API receives data.
2. Use strings from the Big List of Naughty Strings in those input fields.
3. Check if the API rejects the input, filters it, or stores it harmlessly. If the malicious input is stored or accepted without cleaning, you have found an injection vulnerability.

The OWASP API Security Top 10

The Open Web Application Security Project (OWASP) maintains a widely recognized list of the most critical security vulnerabilities. Since 2019, they have also maintained a specific list for APIs. Examining these top vulnerabilities gives testers clear ideas on where to focus their efforts.

Risk 3: Broken Object Level Authorization (BOLA)

BOLA is typically the most common API security issue. It occurs when an API allows a user to access resources (objects) they are not authorized to view, based on their identity.

The Security Risk:

Imagine you are logged into a bank website. You should only see your own account details. If the API endpoint that retrieves your data uses a predictable ID (like GET /accounts/543), an attacker might simply change the ID to guess others (e.g., GET /accounts/572). If the system only checks if you are logged in but fails to check if you are the owner of account 572, the attacker gains unauthorized access to Andrew’s account details.

The US Postal Service had a major BOLA flaw in 2018. The weakness allowed any account holder to view the user data of millions of other users.

How to Test It:

1. Identify Predictable IDs: Look for numerical or easily guessed resource IDs (account numbers, user IDs, order numbers).
2. Iterate or Predict: Use a common API testing tool to loop through a list of potential IDs.
3. Check Responses: Log in as a regular user (Susie) and try to retrieve data associated with another user (Andrew). If the response status is 200 (Success) instead of 404 (Not Found) or 403 (Forbidden), the API has a BOLA vulnerability.

Risk 4: Insufficient Rate Limiting (Unrestricted Resource Consumption)

Rate limiting restricts how many requests a user or machine can make to an API within a certain time frame.

The Security Risk:

If an API lacks rate limiting, an attacker can send thousands of requests very quickly. This makes BOLA testing much easier, as they can quickly iterate through a massive list of potential account numbers. It also makes it easier for attackers to try many combinations of passwords or authentication details (brute-forcing).

How to Test It:

Try running a high volume of requests (like 100 requests in a row) against a sensitive endpoint. If the API continues to process all requests without slowing down or rejecting later requests, it has insufficient rate limiting. This vulnerability is also known as Unrestricted Resource Consumption.

Risk 5: Broken Function Level Authorization (BFLA)

BFLA is similar to BOLA but deals with the actions a user can perform, not just the data they can view.

The Security Risk:

BFLA occurs when a regular user is able to access or modify data using high-level functions or administrative actions that should be restricted based on their role.

For example, a regular user might successfully use a PATCH request to modify a fine they owe, changing the status to “deleted” or the amount due to “zero.” If the system does not check the user’s role (i.e., if they are an Administrator or a basic User) before executing the deletion, the function is broken.

Coinbase had a BFLA issue where a researcher was able to conduct trades using cryptocurrency they did not own, simply because the system failed to verify the user’s authorization to perform that function.

How to Test It:

1. Map Functions: Note down all API functions (GET, POST, PUT, DELETE, PATCH).
2. Test Roles: Log in as a low-level user.
3. Attempt Modification: Try to use functions reserved for higher-level users (like deleting an item, changing a status, or accessing an /admin endpoint). If you can perform these actions, you have found a BFLA vulnerability.

Risk 6: Unrestricted Access to Sensitive Business Flows (UASBF)

This vulnerability is about circumventing the business rules that are built into your system.

The Security Risk:

A sensitive business flow is a process that needs careful control (like placing an order, registering an account, or purchasing a limited item). If a game shop implements a rule that says “no more than one copy of the rare game per customer,” an attacker might try to bypass this rule. They might not be able to order 10 copies in a single API call, but if they place 10 separate orders, each for one copy, and the API allows all 10 orders, the business rule has been circumvented.

This vulnerability often enables scalping, fraud, and resource exhaustion.

How to Test It:

1. Identify Sensitive Flows: Find processes where business rules limit user behavior (e.g., ordering limits, registration steps).
2. Look for Workarounds: Try different ways to achieve an unauthorized outcome. If ordering multiple items is blocked in one request, try subsequent requests immediately after.

Prevention Measures:

Preventing UASBF often requires layered defenses:

• Rate Limiting: Slowing down the speed of subsequent requests.
• Human Detection: Using CAPTCHAs or biometric checks to distinguish humans from automated bots.
• Behavior Analysis: Checking the time between user actions (e.g., if an item is put in a cart and checked out in milliseconds, it is likely a bot).

Risk 7: Improper Inventory Management

This vulnerability relates to poor housekeeping of deployed API versions.

The Security Risk:

When a team deploys a secure new API version (e.g., V2), they must ensure they fully remove the old, vulnerable version (V1). Large companies often struggle with inventory management and forget to decommission older endpoints. If an old V1 endpoint is still running, it may contain security weaknesses (like accepting blank passwords) that have been fixed in the new V2 version. An attacker can easily find and exploit these older, insecure paths.

How to Test It:

If you see an endpoint URL containing version indicators (like /v2/user/changePassword), it is a red flag.

1. Guess Older Versions: Try accessing the immediately older version (e.g., try /v1/user/changePassword).
2. Test Beta/Dev Versions: Look for path indicators like /beta/ or /live/ which might point to unsecure test endpoints.

If you can access an older version, immediately check for known security flaws that the new version was supposed to fix.

Risk 8: Broken Authentication

Authentication is the process of verifying a user’s identity (e.g., logging in with a password). When the authentication system fails to verify identity correctly, it leads to Broken Authentication.

The Security Risk:

Broken Authentication can take many forms:

• Allowing users to bypass password complexity requirements (e.g., accepting an insecure password despite the rules requiring uppercase, lowercase, and symbols).
• Using session tokens that never expire, allowing continuous access even after the user should be logged out.

How to Test It:

If the UI or front end forces strong passwords, you must check if the API also enforces those rules.

1. Test Requirements: Try to submit a weak password (like “password123”) through the API directly.
2. Bypass Logic: See if you can use an old, vulnerable endpoint (due to Improper Inventory Management) to accept an empty or weak password.

A Quick Look at the Rest of the OWASP API Security Top 10

While the examples above cover the most common issues, the OWASP list includes several other critical risks:

Conclusion: Reducing Risk with the Swiss Cheese Model

You do not need to be a security guru to improve the safety of your APIs. Starting with basic tests using common tools like Postman can reveal serious issues like BOLA, Injection, and Improper Inventory Management.

Remember that no single security measure is completely foolproof. This is known as the Swiss Cheese Model. Each measure (like rate limiting, strong authorization checks, or input sanitization) is like a slice of Swiss cheese. Each slice has holes, but when you stack multiple slices together, the likelihood of a threat passing through all the holes is greatly reduced.

By combining your existing testing skills with guidelines like the OWASP API Security Top 10, you can significantly lower the risk profile of your applications. This work is crucial for protecting user data and maintaining system integrity.

If you want to learn more, a highly recommended resource is APIsec University, a free learning platform that offers high-quality, self-paced video courses related to API security.