OWASP API Security Top 10

Introduction

APIs have become the backbone of modern software. Web applications use APIs to load data without refreshing pages. Mobile applications depend on APIs for login, payments, notifications, profile updates, search, order tracking, and account management. Cloud platforms use APIs to connect microservices, automate workflows, manage infrastructure, and exchange information with partners. In many systems, the API layer is where the most important business operations actually happen.

This also makes APIs a major security target. An API may expose customer records, employee data, payment information, healthcare details, business reports, user permissions, administrative actions, and integration workflows. If an API is poorly protected, attackers may not need to break the user interface at all. They can send requests directly to the API, manipulate identifiers, reuse stolen tokens, bypass authorization checks, flood expensive endpoints, or abuse business processes at scale.

The Open Worldwide Application Security Project, known as OWASP, publishes the OWASP API Security Top 10 to help teams understand the most critical security risks affecting APIs. It is a widely recognized reference used by developers, testers, architects, security engineers, and engineering leaders. The list does not replace detailed threat modeling or application-specific security design, but it gives teams a strong starting point for identifying common API weaknesses.

For API testers, the OWASP API Security Top 10 is especially useful because it translates security risk into practical testing areas. It reminds testers that API quality is not limited to correct status codes and valid response bodies. A good API test strategy should also verify authentication, authorization, object ownership, property-level access, rate limiting, business flow restrictions, server-side request forgery protection, secure configuration, inventory management, and safe handling of third-party API responses.

What Is OWASP?

OWASP stands for Open Worldwide Application Security Project. It is a non-profit organization focused on improving software security through open resources, community projects, documentation, tools, standards, and guidance. OWASP is well known because its materials are freely available and widely adopted across the software industry.

Many teams first hear about OWASP through the OWASP Top 10 for web applications. However, OWASP also provides resources such as the OWASP API Security Top 10, OWASP Application Security Verification Standard, OWASP Testing Guide, OWASP Cheat Sheet Series, and many other projects. These resources help teams build, test, review, and operate more secure systems.

OWASP is important because it gives security discussions a shared vocabulary. Instead of saying "some access issue exists," a team can identify a problem as broken object-level authorization, broken function-level authorization, excessive data exposure, or security misconfiguration. This makes defects easier to discuss, prioritize, document, and fix.

What Is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a list of critical security risks that commonly affect APIs. It highlights patterns that appear repeatedly in real-world incidents, security assessments, penetration tests, and API implementations. The list helps organizations focus on areas where APIs are most likely to fail and where failures can cause serious damage.

The 2023 OWASP API Security Top 10 includes Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs.

The value of the list is not only in memorizing the names. The value is in understanding how each risk appears in real applications and how testers can create meaningful checks to detect it. An API may pass happy path functional tests and still have several of these risks. That is why security thinking must be part of API testing from the beginning.

Why the OWASP API Security Top 10 Is Important

The OWASP API Security Top 10 helps teams identify vulnerabilities before attackers do. It gives developers a checklist of risk areas to consider while designing endpoints. It gives testers a structure for building positive and negative security scenarios. It gives architects a way to review authentication, authorization, gateway rules, rate limits, inventory, and integration boundaries. It gives product and business stakeholders a clearer way to understand why security testing is necessary.

Another reason it matters is that API security defects can be quiet. A broken screen is easy to notice. A broken API authorization rule may remain invisible until someone intentionally abuses it. For example, if User A can change `/orders/101` to `/orders/102` and see another user's order, the normal UI may never reveal the issue. A tester who understands BOLA will intentionally test that behavior.

The Top 10 also helps teams prioritize. Security can feel too broad if every possible threat is considered at once. The OWASP list focuses attention on common, serious, API-specific categories. It does not mean other risks are irrelevant, but it provides a practical foundation for API security maturity.

API1: Broken Object Level Authorization

Broken Object Level Authorization, often called BOLA, occurs when an API does not properly verify whether the caller is allowed to access a specific object. The user may be authenticated, but the API fails to check whether that user owns or is permitted to access the requested record. This is one of the most common and dangerous API security risks because APIs frequently expose object identifiers in URLs, query parameters, or request bodies.

Consider an endpoint such as `GET /users/101`. User A may legitimately access user record 101. If User A changes the request to `GET /users/102` and receives User B's data, the API has a BOLA vulnerability. The defect is not that authentication is missing. The defect is that object-level authorization is missing or insufficient.

GET /users/101
Authorization: Bearer userAToken

GET /users/102
Authorization: Bearer userAToken

Testers should verify resource ownership, ID manipulation, unauthorized object access, horizontal privilege escalation, tenant isolation, and cross-account access. They should use valid tokens for different users and attempt to access records that belong to someone else. A secure API should deny the request, return a safe error, or sometimes hide the resource with a documented response such as `404 Not Found` depending on the design.

API2: Broken Authentication

Broken Authentication occurs when the API's identity verification is weak, incomplete, or bypassable. Authentication is the control that proves who the caller is. If authentication fails, every authorization rule built on top of identity becomes unreliable. Broken authentication can include weak passwords, missing multi-factor authentication for sensitive access, predictable tokens, missing token validation, session hijacking, credential stuffing, accepting expired tokens, or allowing anonymous access to protected endpoints.

API testers should verify login security, token validation, session expiration, credential handling, authentication bypass attempts, malformed tokens, revoked tokens, disabled accounts, wrong issuers, wrong audiences, and unsupported authentication methods. A token should not be trusted simply because it is present. It must be valid, unexpired, signed correctly, intended for the API, and associated with an active identity.

A missing or invalid token should commonly result in `401 Unauthorized`. The response should not reveal secrets, token internals, stack traces, or overly detailed information that helps attackers. Authentication testing should include both expected success and deliberate failure paths.

API3: Broken Object Property Level Authorization

Broken Object Property Level Authorization happens when users can read or modify object properties they should not access. This risk is about fields inside an object, not only the object itself. A user may be allowed to view an employee profile but not salary details. A customer may be allowed to update a shipping address but not account status. A support agent may be allowed to view an order but not payment token fields.

A common example is mass assignment. The API may accept a JSON body and automatically map it to a backend object. If a regular employee sends a restricted field such as `salary`, `role`, `isAdmin`, or `accountStatus`, and the API applies that field without authorization, the API has a property-level authorization weakness.

{
  "name": "John",
  "salary": 100000,
  "role": "Admin"
}

Testers should verify hidden fields, read-only fields, writable fields, sensitive property exposure, response filtering, request body filtering, and mass assignment protection. It is important to test both read and write paths. A field may be protected from updates but still leaked in responses, or hidden in responses but accepted in request bodies.

API4: Unrestricted Resource Consumption

Unrestricted Resource Consumption occurs when an API does not adequately limit how much system resource a caller can consume. Resources include CPU, memory, database capacity, network bandwidth, storage, file processing, third-party service calls, SMS messages, email sending, and payment gateway calls. An API can be functionally correct but still unsafe if it allows unlimited or expensive usage.

Examples include unlimited requests, very large payloads, expensive database queries, unrestricted file uploads, unbounded pagination, deeply nested JSON, excessive report generation, and repeated requests that trigger costly external services. The result may be denial of service, degraded performance, higher infrastructure costs, or business abuse.

Testers should verify rate limiting, request throttling, payload size limits, timeout handling, pagination limits, maximum file size, maximum page size, retry behavior, and protection around costly operations. When limits are exceeded, APIs often return `429 Too Many Requests`, `413 Payload Too Large`, or another documented response. The exact code depends on the API design, but the important point is that consumption must be controlled.

API5: Broken Function Level Authorization

Broken Function Level Authorization occurs when a user can access functions or operations that should be restricted to another role, permission, scope, or trust level. Unlike BOLA, which focuses on access to a specific object, function-level authorization focuses on whether the caller is allowed to use a capability at all. Examples include admin-only actions, delete operations, approval workflows, refund operations, export functions, configuration changes, and privileged reports.

For example, an employee may call `DELETE /employees/101`. If only administrators should delete employee records, the API should deny the request. Hiding the delete option from the UI is not sufficient because the endpoint may still be called directly.

DELETE /employees/101
Authorization: Bearer employeeToken

HTTP/1.1 403 Forbidden

Testers should verify role-based access, scope-based access, privileged operations, admin-only endpoints, vertical privilege escalation, method restrictions, and endpoint discovery. They should use lower-privilege tokens and attempt restricted functions directly. A secure API must enforce permissions on the server side for every protected operation.

API6: Unrestricted Access to Sensitive Business Flows

Unrestricted Access to Sensitive Business Flows is about abuse of important business processes. The API may require authentication and may technically perform valid operations, but it may allow those operations too frequently, too easily, or without enough business protection. Attackers can automate workflows in ways that harm the business even when individual requests look valid.

Examples include unlimited coupon redemption, unlimited money transfer attempts, unlimited OTP requests, automated account creation, bulk ticket purchasing, rapid password reset emails, loyalty point abuse, fake referral creation, repeated inventory reservation, or mass scraping of business-sensitive data. These issues are not always simple technical bugs. They are failures to protect business workflows from automation and abuse.

Testers should verify workflow restrictions, abuse prevention, automation resistance, request frequency controls, business limits, duplicate action prevention, fraud checks, lockouts, and monitoring. The expected behavior may be throttling, temporary blocking, captcha at the client layer, additional verification, manual review, or denial of repeated requests depending on the business process.

API7: Server Side Request Forgery

Server Side Request Forgery, or SSRF, occurs when an API fetches a resource based on a user-supplied URL without proper validation. The attacker does not directly access the target system. Instead, the attacker tricks the server into making the request. This can be dangerous because the server may have access to internal networks, cloud metadata services, private APIs, or protected resources that external users cannot reach directly.

POST /fetch
{
  "url": "http://internal-server"
}

If the API blindly fetches the supplied URL, an attacker may attempt to reach internal hosts, cloud metadata endpoints, local services, or restricted network locations. SSRF prevention requires strict validation, allowlists, protocol restrictions, network egress controls, DNS protection, and careful handling of redirects.

Testers should verify URL validation, allowed destination rules, internal network protection, protocol restrictions, redirect handling, blocked IP ranges, and safe error responses. SSRF testing must be done carefully in approved environments because unsafe tests can affect internal systems. The goal is to prove that the API refuses unauthorized destinations rather than actually attacking infrastructure.

API8: Security Misconfiguration

Security Misconfiguration occurs when the API, gateway, server, cloud environment, framework, or supporting infrastructure is configured insecurely. A secure codebase can become unsafe if deployment settings are wrong. Common examples include debug mode enabled, default passwords, unnecessary HTTP methods, missing security headers, overly permissive CORS, exposed admin consoles, verbose error messages, open cloud storage, weak TLS settings, and public access to internal endpoints.

Misconfiguration is common because modern APIs depend on many layers. There may be an API gateway, load balancer, container platform, service mesh, framework, identity provider, logging system, storage bucket, database, and CDN. A mistake in any layer can expose risk. Security therefore requires configuration review as well as code review.

Testers should verify security headers, HTTPS enforcement, disabled debug features, proper server configuration, CORS behavior, allowed methods, error message exposure, environment isolation, and whether admin or diagnostic endpoints are reachable. Production APIs should not expose stack traces, framework debug pages, test credentials, server internals, or unnecessary metadata.

API9: Improper Inventory Management

Improper Inventory Management happens when organizations lose track of API versions, endpoints, hosts, documentation, owners, environments, or deprecation status. An endpoint that everyone remembers may be tested and protected. A forgotten endpoint may remain exposed with old authentication, weak authorization, debug behavior, or outdated dependencies. Attackers often look for older versions because they may have fewer protections.

Examples include old API versions still available, forgotten test endpoints, deprecated services left online, undocumented partner APIs, staging APIs reachable from the internet, duplicate endpoints with inconsistent security, and unclear ownership. Inventory problems grow as systems scale, especially in microservice environments where many teams publish APIs independently.

Testers should verify API version management, deprecated endpoint removal, environment isolation, documentation accuracy, API gateway registration, ownership metadata, and whether old endpoints behave according to lifecycle policy. A deprecated API version may return a documented response such as `404 Not Found`, `410 Gone`, or a controlled deprecation message depending on the organization's policy.

API10: Unsafe Consumption of APIs

Unsafe Consumption of APIs occurs when an application trusts data received from third-party or external APIs without sufficient validation. Many systems call external APIs for payments, shipping, identity verification, maps, tax calculation, fraud scoring, analytics, messaging, or partner workflows. Those responses should be treated as untrusted input because external systems can fail, change, be compromised, return malformed data, or behave unexpectedly.

Examples include blindly trusting external response fields, failing open when an external service returns an error, accepting unexpected data types, exposing third-party error details to users, not validating signatures or webhooks, using insecure integration credentials, and allowing external API failure to corrupt internal state. The risk is not only that the external API is malicious. The risk is that assumptions about external data may be wrong.

Testers should verify response validation, error handling, timeout behavior, retry behavior, input sanitization, third-party API reliability, webhook verification, signature validation, fallback logic, and safe dependency usage. A secure application validates what it receives before using it in decisions, storing it, or returning it to users.

OWASP API Security in API Testing

QA engineers can use the OWASP API Security Top 10 as a practical testing map. Authentication tests align with API2. Authorization and ownership tests align with API1, API3, and API5. Rate limiting, payload size, and timeout tests align with API4. Workflow abuse tests align with API6. URL-fetching and integration tests may align with API7 and API10. Configuration and lifecycle checks align with API8 and API9.

This approach helps testers avoid a narrow test suite. A functional suite may confirm that valid requests work, but an OWASP-informed suite also asks what happens when a user changes an ID, removes a token, uses the wrong role, sends restricted fields, floods an endpoint, calls an old API version, or supplies a malicious URL. These are the kinds of scenarios that reveal API security defects.

Security testing does not mean every QA engineer must perform advanced penetration testing. It means API testers should understand common risk patterns and include relevant negative tests in normal API validation. Complex security assessments may still require specialists, but everyday API test design can catch many important problems early.

Example Test Cases

For Broken Object Level Authorization, a tester can authenticate as User A and attempt to access User B's resource. If the API returns the other user's data, the endpoint is unsafe. The expected result is commonly `403 Forbidden` or a documented `404 Not Found` response that avoids revealing whether the object exists.

For Broken Authentication, a tester can call a protected endpoint with no token, an invalid token, an expired token, a malformed token, or a token signed by the wrong issuer. The API should reject the request, commonly with `401 Unauthorized`. It should not return protected data or expose sensitive token validation details.

For Broken Object Property Level Authorization, a tester can attempt to modify a restricted field such as salary, role, status, discount limit, or approval flag. The API should reject the update, ignore the restricted field safely, or return a documented error. The behavior should be intentional and consistent.

For Unrestricted Resource Consumption, testers can exceed configured request limits, submit oversized payloads, request huge page sizes, upload large files, or trigger expensive queries in an approved test environment. The API should enforce limits and return controlled responses such as `429 Too Many Requests` or `413 Payload Too Large` where appropriate.

For Broken Function Level Authorization, a lower-privilege user can attempt admin-only operations such as delete, export, approve, refund, configure, or create privileged users. The expected response is commonly `403 Forbidden`. For Sensitive Business Flows, testers can verify throttling or duplicate prevention around OTP requests, coupon redemption, account creation, password resets, and transaction attempts.

For SSRF, testers can provide disallowed internal URLs or unsupported protocols to endpoints that fetch remote content, but only in safe test environments and within approved boundaries. For Security Misconfiguration, testers can inspect headers, error responses, debug behavior, CORS rules, and exposed routes. For Inventory Management, testers can check old versions and undocumented endpoints. For Unsafe Consumption, testers can simulate invalid third-party responses, timeouts, and unexpected data.

REST Assured Example

REST Assured can be used to automate OWASP-style API checks in Java. A positive authorization test may prove that a valid user can access an allowed resource.

given()
    .header("Authorization", "Bearer " + token)
.when()
    .get("/employees/101")
.then()
    .statusCode(200);

A negative authorization test can use a lower-privilege token against a restricted function. This maps to broken function-level authorization testing.

given()
    .header("Authorization", "Bearer " + employeeToken)
.when()
    .delete("/employees/101")
.then()
    .statusCode(403);

For BOLA testing, the same authenticated user can attempt to access another user's object. The expected status should follow the API contract, but the response must not reveal protected data.

given()
    .header("Authorization", "Bearer " + userAToken)
.when()
    .get("/users/102")
.then()
    .statusCode(403);

Postman Example

Postman is useful for both manual exploration and repeatable API security collections. Testers can maintain environment variables for valid token, expired token, invalid token, admin token, employee token, guest token, user A ID, and user B ID. This makes it easier to run the same endpoint with different identities and verify security behavior.

A Postman collection can include tests for missing tokens, invalid tokens, expired tokens, role validation, resource ownership, rate limits, invalid payloads, unsupported methods, and unauthorized endpoint access. Test scripts can assert that protected fields are absent, that status codes match the contract, and that error responses do not expose sensitive details.

Postman variables should be managed carefully. Real secrets, API keys, and tokens should not be exported into shared files or committed to source control. Security testing tools must be used with the same discipline as application code because careless handling of test credentials can create new security risk.

Karate Example

Karate can express API security checks in a concise, readable format. A valid access check may look like this:

Given header Authorization = 'Bearer ' + token
When method GET
Then status 200

A negative authorization check may reuse the same flow with a restricted role and expect a denial:

Given header Authorization = 'Bearer ' + employeeToken
When method DELETE
Then status 403

Karate works well for data-driven role and permission checks because examples can drive many role-resource combinations. However, testers should keep scenarios meaningful. A failed security test should clearly show which user, role, endpoint, operation, and expected control failed.

Benefits of Following OWASP Guidance

Following OWASP guidance helps teams build more secure APIs and reduce the attack surface. It encourages teams to think beyond happy path behavior and consider how attackers may interact with endpoints directly. It improves testing coverage by giving QA engineers clear risk categories to validate. It supports compliance conversations because teams can show that they are testing recognized API security areas.

OWASP guidance also improves collaboration. Developers can design authorization checks with BOLA and function-level risks in mind. Testers can create negative scenarios around those checks. Architects can review gateways, rate limits, versioning, and third-party integrations. Security teams can use the same categories during threat modeling and assessments. A shared model reduces confusion and makes security work more actionable.

Another benefit is better production reliability. Several OWASP API risks are not only confidentiality problems. Unrestricted resource consumption affects performance and availability. Improper inventory management creates maintenance risk. Unsafe consumption of APIs affects integration resilience. Security quality and operational quality often overlap.

Best Practices

Implement strong authentication and validate tokens fully. Enforce authorization on every protected endpoint. Validate object ownership for every resource that belongs to a user, account, organization, or tenant. Apply property-level controls so users cannot read or modify sensitive fields. Use least privilege for roles, scopes, service accounts, and integration credentials.

Apply rate limits, payload limits, pagination limits, timeouts, and quotas to reduce resource abuse. Protect sensitive business workflows from automation and repeated misuse. Validate URLs and restrict destinations when APIs fetch external resources. Disable debug features, enforce HTTPS, configure security headers, restrict CORS appropriately, and avoid exposing internal errors.

Maintain an accurate API inventory. Know which endpoints exist, which versions are active, who owns them, which environments are public, and when deprecated APIs should be removed. Validate data from third-party APIs before trusting it. Perform regular security testing based on OWASP guidance, and update tests when endpoints, roles, permissions, integrations, or business workflows change.

Common Mistakes

One common mistake is testing only functional scenarios. Functional tests are necessary, but they do not prove that APIs are secure. A protected endpoint must be tested with missing tokens, invalid tokens, expired tokens, wrong roles, wrong users, invalid payloads, and abuse patterns where relevant.

Another mistake is ignoring object ownership. Many APIs correctly check that a user is logged in but forget to verify that the requested object belongs to that user or is within that user's allowed scope. ID manipulation tests are simple and valuable because they often expose serious authorization defects.

Missing rate limits are also common. Teams may focus on response correctness and overlook request volume, expensive queries, repeated OTPs, repeated password reset attempts, and large payloads. APIs should restrict excessive requests and expensive usage.

Trusting third-party data blindly is another mistake. External APIs can return unexpected data, invalid values, errors, delays, or malicious content. Applications should validate external responses and fail safely. Leaving deprecated APIs exposed is also risky because old endpoints may not receive the same security updates as current versions.

Practical Review Checklist

Before finalizing API security coverage, ask whether every protected endpoint requires authentication. Confirm that invalid, missing, expired, and revoked credentials are rejected. Verify that tokens are checked for issuer, audience, signature, expiration, roles, and scopes where applicable.

Review authorization next. Can each user access only the objects they should access? Can lower-privilege users call admin functions? Can users modify restricted fields? Can a customer view another customer's order? Can a tenant access another tenant's data? These questions directly target BOLA, property-level authorization, and function-level authorization.

Review resilience and abuse controls. Are there rate limits? Are payload sizes limited? Is pagination bounded? Are expensive operations controlled? Are sensitive business flows protected from automation? Are URLs validated before server-side fetches? Are debug endpoints disabled in production?

Review operations and lifecycle. Is the API inventory accurate? Are old versions removed or controlled? Are staging endpoints isolated? Are third-party responses validated? Are security events logged safely? If the answer is unclear, the API security posture needs more review.

Interview Questions

A common interview question is: what is the OWASP API Security Top 10? A strong answer is that it is a list of the ten most critical API security risks published by OWASP to help organizations build, review, and test secure APIs. It provides a practical structure for identifying common API vulnerabilities.

Another common question is: what is BOLA? Broken Object Level Authorization is a vulnerability where users can access resources belonging to other users because object-level authorization checks are missing or insufficient. A typical example is changing an ID in a URL and receiving another user's data.

Interviewers may ask which risk is related to authentication. The answer is API2, Broken Authentication. They may ask which risk is associated with rate limiting and resource limits. The answer is API4, Unrestricted Resource Consumption. They may ask which risk involves unauthorized admin functions. That relates to API5, Broken Function Level Authorization.

For testing questions, explain that API testers should validate authentication, authorization, object ownership, property-level access, role permissions, rate limiting, business logic protections, SSRF prevention, secure configuration, API version management, error handling, and third-party integration behavior. Good API security testing includes negative scenarios, not only valid requests.

Interview-Ready Explanation

The OWASP API Security Top 10 is a widely recognized industry standard published by the Open Worldwide Application Security Project. It identifies critical security risks affecting APIs and helps teams build and test APIs more securely. The 2023 list includes Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs.

For testers, the OWASP API Security Top 10 is important because it turns security concerns into practical validation areas. Testers should verify that users cannot access other users' resources, tokens are validated properly, restricted fields cannot be read or modified, rate limits and payload limits are enforced, admin functions are protected, sensitive business flows cannot be abused, server-side URL fetching is restricted, debug features are disabled, API inventory is maintained, and third-party responses are handled safely.

A strong API test strategy combines functional testing with security-focused negative testing. It validates what should work and what must be blocked. This helps reduce data exposure, unauthorized access, service abuse, production vulnerabilities, compliance risk, and customer trust issues.

Key Takeaway

The OWASP API Security Top 10 is a practical guide for understanding the most common and serious API security risks. It helps teams look beyond basic functional testing and examine how APIs behave when callers manipulate IDs, use invalid tokens, access restricted functions, submit sensitive fields, exceed limits, abuse workflows, supply dangerous URLs, call old versions, or rely on unsafe external data.

For API testers, the most important lesson is to test both permission and prevention. A secure API should return correct data to authorized users and deny unsafe requests from unauthorized, underprivileged, excessive, malformed, or untrusted callers. Using OWASP guidance makes API testing more complete, more realistic, and more valuable to the organization.