OWASP API Security: Complete Guide to Risks, Testing, and Protection

What the Framework Covers

The OWASP API Security Project helps developers, architects, testers, security practitioners, and organizations understand and mitigate vulnerabilities that commonly affect application programming interfaces.

Its principal awareness document is the API Security Top 10. The current edition, published in 2023, identifies ten significant risk categories:

1. API1:2023 Broken Object Level Authorization
2. API2:2023 Broken Authentication
3. API3:2023 Broken Object Property Level Authorization
4. API4:2023 Unrestricted Resource Consumption
5. API5:2023 Broken Function Level Authorization
6. API6:2023 Unrestricted Access to Sensitive Business Flows
7. API7:2023 Server-Side Request Forgery
8. API8:2023 Security Misconfiguration
9. API9:2023 Improper Inventory Management
10. API10:2023 Unsafe Consumption of APIs

Together, these categories provide an API-specific awareness and prioritization model. They do not cover every application, infrastructure, supply-chain, identity, and operational risk that can affect an API-based system.

How the 2023 List Was Developed

OWASP used the methodology from its 2019 edition and added a three-month public Call for Data between September 1 and November 30, 2022.

The project collected and categorized publicly available information about API security incidents reported between 2019 and 2022. Sources included bug-bounty platforms and public reports. The project also considered feedback on the first edition, changes in the security landscape, discussions with specialists, practitioner review, and community contributions.

OWASP applied its Risk Rating Methodology to the proposed categories. The project team determined prevalence ratings through consensus based on members’ industry experience.

The public Call for Data did not produce enough consistent information for meaningful statistical analysis. The final list is therefore a forward-looking awareness and prioritization document informed by public incident reports, bug-bounty findings, practitioner review, and expert judgment. It should not be interpreted as a statistical ranking of vulnerability frequency across the industry.

A Brief Timeline

• 2019: OWASP publishes the first API Security Top 10, establishing a dedicated list of risks affecting APIs.
• September 1 to November 30, 2022: OWASP conducts a public Call for Data while reviewing incidents, bug-bounty findings, practitioner feedback, and changes since the first edition.
• 2023: OWASP publishes the second edition, including updated categories for sensitive business flows, SSRF, property-level authorization, and unsafe consumption of upstream services.
• June 27, 2025: NIST publishes SP 800-228, Guidelines for API Protection for Cloud-Native Systems.
• March 13, 2026: NIST publishes SP 800-228-upd1, superseding the original publication and adding appendices that group API risks by category and recommended controls by lifecycle stage.

The two bodies of guidance are complementary. OWASP organizes the principal risk categories, while NIST provides lifecycle controls and implementation patterns for cloud-native environments.

What Each Risk Means

API1:2023 Broken Object Level Authorization

Broken Object Level Authorization, commonly called BOLA, occurs when an endpoint accesses an object identified by the client but fails to verify whether the caller is permitted to view or modify that specific object.

Consider this request: GET /orders/1001

API2:2023 Broken Authentication

Broken Authentication includes weaknesses that allow attackers to impersonate users, compromise credentials or tokens, interfere with sessions, or bypass identity controls.

Common examples include:

• Weak credential and password-recovery processes
• Missing protections against credential stuffing
• Insecure storage or exposure of access tokens
• Improper session expiration
• Token-validation mistakes
• Incorrect OAuth 2.0 or OpenID Connect implementations
• Missing replay protection
• Long-lived credentials without suitable rotation

OAuth 2.0, OpenID Connect, and JWT should not be treated as interchangeable. OAuth 2.0 is an authorization framework, OpenID Connect adds an identity layer, and JWT is a token format. Using any of them does not automatically make an implementation secure.

Controls should match the client and associated risk. Human users may require multi-factor authentication, while services may use workload identities and short-lived credentials. Sensitive operations may require recent authentication, step-up verification, or transaction-specific approval.

Server-side sessions should be invalidated appropriately. Opaque tokens may require introspection and revocation, while JWT access tokens should normally be short-lived when immediate revocation is unavailable. Refresh tokens require secure storage, rotation, and misuse detection.

API3:2023 Broken Object Property Level Authorization

Property-level authorization controls which fields a caller may read or modify. The 2023 category combines problems previously associated with excessive data exposure and mass assignment.

A disclosure failure occurs when an endpoint returns internal attributes:

{
"id": 183,
"displayName": "Example User",
"role": "administrator",
"riskScore": 89,
"internalNotes": "Manual review required"
}

The legitimate client may need only the identifier and display name. Returning an entire database or ORM object exposes unnecessary information.

The write-side problem occurs when an application accepts properties the caller should not control:

{
"displayName": "Example User",
"role": "administrator",
"accountCredit": 50000
}

If the application maps the payload directly to an internal model, a normal user may be able to modify privileged fields.

Defences should combine request allowlists, explicit data-transfer objects, response views, framework-level mass-assignment protection, and authorisation checks for sensitive properties. A schema establishes whether a field is technically valid, while authorization determines whether a particular caller may read or change it.

API4:2023 Unrestricted Resource Consumption

Requests consume processor time, memory, storage, database connections, network bandwidth, email messages, SMS messages, and paid third-party services. Inadequate limits can support denial-of-service attacks, brute-force attempts, expensive automation, and unexpected operational costs.

Common weaknesses include unrestricted pagination, large uploads, computationally expensive filters, excessive batch operations, recursive processing, repeated report generation, and missing timeouts. GraphQL deployments may permit deeply nested or complex queries that consume disproportionate resources.

Protections include:

• Identity-aware rate limits
• Per-user and per-tenant quotas
• Request-size restrictions
• Pagination limits
• Query-cost and depth controls
• Execution timeouts
• Concurrency limits
• Circuit breakers
• Spending thresholds for metered integrations

Limits should reflect both technical capacity and business purpose. A single global request limit may not protect a computationally expensive operation, while an excessively restrictive control may block legitimate users.

API5:2023 Broken Function Level Authorization

Function-level authorization determines whether a caller may invoke a particular operation. The weakness occurs when administrative or high-impact functionality is available without the required role, permission, or policy decision.

Potentially sensitive routes include:

GET /admin/export-users
POST /billing/apply-credit
DELETE /accounts/{id}
POST /reports/generate-all

Authentication establishes who or what is making the request. Function-level authorization determines whether that principal may perform the requested operation.

Applications should not rely on hidden interface elements, undocumented routes, or unpredictable paths as access controls. Attackers may discover operations through client-side code, API specifications, mobile applications, error messages, predictable routes, or endpoint enumeration.

Every sensitive operation should enforce authorization on the server. Policies should account for roles, permissions, tenant boundaries, separation-of-duty requirements, and operation-specific conditions.

API6:2023 Unrestricted Access to Sensitive Business Flows

Some API attacks do not exploit a conventional software vulnerability. Instead, attackers automate legitimate functionality to cause financial, commercial, or operational damage.

Sensitive flows can include:

• Ticket and limited-inventory purchases
• Coupon or promotion redemption
• Account registration
• Reservation systems
• Referral programs
• Password-recovery requests
• Comment or content submission
• Expensive verification services

An attacker may use bots to buy scarce inventory, create thousands of accounts, repeatedly redeem a promotion, reserve resources without completing payment, or trigger a service that costs the organization money.

Each individual request may be technically valid. The harmful effect appears when the process is automated or repeated at scale.

Protection requires resource controls and business-specific rules. Depending on the workflow, safeguards may include limits per account, device, payment method, address, or time period; behavioral analysis; bot detection; queueing; additional verification; and monitoring for abnormal patterns.

The rules must reflect the workflow’s economic purpose. A technically valid request can still constitute abusive behavior.

API7:2023 Server-Side Request Forgery

Server-Side Request Forgery occurs when an application retrieves a resource from a location influenced by user input without adequately restricting the destination.

A vulnerable feature may accept an external image:

{
"imageUrl": "https://example.com/image.jpg"
}

{
"imageUrl": "http://169.254.169.254/latest/meta-data/"
}

Depending on the environment and available controls, SSRF can help an attacker access internal APIs, administrative interfaces, loopback services, cloud metadata endpoints, or other destinations that are not directly accessible from the internet.

Defences should not rely on simple keyword or string matching. Applications should parse URLs with trusted libraries, restrict schemes and ports, apply destination allowlists when permitted services are known, and revalidate destinations after redirects and DNS resolution.

Network-level egress policies should prevent components from reaching unnecessary internal systems, metadata services, and external destinations. Applications should block prohibited loopback, private, link-local, multicast, and metadata addresses while accounting for IPv4, IPv6, alternate address representations, redirects, and DNS rebinding.

Cloud environments should also apply platform-specific metadata protections and workload identity. Content retrieved from an approved destination must still be validated before it is stored, rendered, parsed, or passed to another service.

API8:2023 Security Misconfiguration

API deployments often involve application code, gateways, ingress controllers, containers, service meshes, cloud settings, identity providers, and third-party infrastructure. An insecure setting at any layer can expose information or functionality.

Common examples include:

• Permissive CORS policies
• Default or shared credentials
• Exposed development and debug routes
• Missing TLS enforcement
• Unnecessary HTTP methods
• Verbose production errors
• Publicly accessible storage
• Inconsistent gateway and application policies
• Unprotected administrative interfaces

Configuration security should be automated where practical. Teams can use hardened templates, infrastructure-as-code reviews, policy checks, approved baselines, secret-management systems, and deployment-time validation to reduce drift.

Development, testing, and staging endpoints need the same inventory discipline. A forgotten non-production route may process real data while receiving less monitoring and maintenance than the main service.

API9:2023 Improper Inventory Management

Improper inventory management includes undocumented services, old versions, forgotten test endpoints, shadow APIs, duplicate deployments, and interfaces without an accountable owner.

An older version may retain a vulnerability that was corrected in the current service while remaining accessible via another route, hostname, or gateway. Undocumented endpoints can also escape routine testing, logging, deprecation, and incident-response processes.

A useful inventory should record:

• Service name and business purpose
• Environment and base URL
• Version and lifecycle status
• Technical and business owners
• Authentication method
• Data classification
• External dependencies
• Internet exposure
• Deprecation and retirement dates

Discovery tools can identify unregistered traffic and endpoints, but discovery alone is not governance. Every interface needs an owner, a documented purpose, a maintenance status, and a removal process.

Without an accurate inventory, an organization cannot apply authentication, testing, monitoring, ownership, and retirement policies consistently across its exposed interfaces.

API10:2023 Unsafe Consumption of APIs

Applications often treat responses from partners and third-party providers as trustworthy because the data originates from another server rather than directly from an end user. That assumption can create risks to injection, integrity, availability, and business logic.

An upstream provider might be compromised, return malformed content, redirect requests unexpectedly, change its response structure, or supply values outside the expected range. Attackers may also manipulate an integration through compromised credentials or an insecure webhook.

Responses from external services should be validated against explicit schemas and business rules. Integrations need timeouts, response-size limits, restricted redirects, secure credential handling, sensible retry policies, and proper error management.

Trust should remain limited even when the provider is reputable. A response that is validly authenticated is not necessarily safe to execute, display, store, or pass to another system.

Cloud-Native Protection and NIST Guidance

Cloud-native architectures increase the number of service-to-service requests and distribute security enforcement across gateways, workloads, identity systems, orchestration layers, and infrastructure controls.

NIST SP 800-228-upd1 addresses risks during API development and operation. It organizes protection into pre-runtime and runtime stages and examines the advantages and disadvantages of different implementation patterns.

The March 13, 2026 update superseded the original June 2025 publication. It added Appendix D, which lists API risks by category, and Appendix E, which organizes recommended controls by API lifecycle stage.

Pre-runtime protection includes maintaining specifications, identifying sensitive properties, reviewing design decisions, establishing configuration baselines, managing inventories, and determining how policies will be enforced before deployment.

Runtime protection includes encrypted communication, service and user authentication, authorization, request and response validation, resource controls, telemetry, and monitoring.

This lifecycle perspective complements the Top 10. The OWASP categories describe what can go wrong, while NIST helps teams decide where and how to implement protections.

Essential Protection Practices

Effective API protection requires consistent controls across design, development, deployment, and operation.

Establish Reliable Identity

Choose authentication mechanisms appropriate to each client. Protect credential flows, validate tokens completely, restrict scopes, rotate sensitive credentials, and require stronger verification for high-impact operations.

Enforce Authorization at Multiple Levels

Function-level checks protect operations, object-level checks protect individual resources, and property-level checks protect sensitive fields. Multi-tenant platforms must also explicitly verify tenant boundaries.

A central policy service may improve consistency, but each service must still enforce the decisions relevant to its own resources and operations.

Validate Requests and Responses

Maintain accurate OpenAPI, GraphQL, gRPC, or equivalent contracts. Validate data types, formats, ranges, sizes, and the presence of unexpected fields. Apply the same discipline to responses received from upstream providers.

Minimize Exposed Data

Return only the information clients need. Avoid serializing complete database objects by default. Separate public response models from internal records and administrative views.

Control Resource Usage

Apply limits according to identity, operation, cost, and business context. Use quotas, rate limits, pagination caps, timeouts, concurrency restrictions, query-complexity rules, and circuit breakers where appropriate.

Harden Configuration

Enforce TLS, restrict CORS, remove unnecessary methods and endpoints, protect administrative interfaces, secure secrets, and prevent verbose production errors.

Maintain an Accurate Inventory

Document every service, version, owner, environment, and exposure point. Detect shadow endpoints, define deprecation periods, and remove retired versions rather than leaving them available indefinitely.

Monitor Security-Relevant Activity

Record useful events with correlation identifiers while avoiding passwords, tokens, and unnecessary personal information. Monitor repeated identifier changes, failed privilege checks, abnormal request rates, suspicious outbound destinations, and unexpected behaviour from third-party services.

Building a Risk-Based Testing Program

Automated scanners can identify some configuration errors, injection patterns, exposed services, and known weaknesses. They are less reliable at detecting business-logic problems and authorization failures that depend on user, tenant, object, and workflow context.

A mature testing program combines automation with manual, specification-driven, and scenario-based methods.

Test Object-Level Authorization

Create a resource under one account and attempt to read, modify, or delete it with another account. Repeat the test across path parameters, query strings, JSON bodies, nested objects, filenames, and GraphQL variables.

Test Authentication Controls

Attempt to use expired credentials, malformed tokens, altered JWT claims, and incomplete authorization flows. Review password recovery, session termination, refresh-token rotation, replay protection, token audience, signature, issuer, expiration, and scope handling.

Test Sensitive Properties

Add restricted fields to requests and inspect responses for internal attributes. Confirm that unauthorized write properties are rejected or ignored and that protected data is excluded from responses.

Test Resource Limits

Send controlled request bursts, large payloads, deep GraphQL queries, expensive filters, and oversized pagination values. Confirm that gateway and service-level controls behave predictably without causing downstream instability.

Test Privileged Functions

Invoke administrative and high-impact routes with ordinary credentials. Examine alternate HTTP methods, versions, path variations, old endpoints, and undocumented operations rather than checking only actions visible in the user interface.

Test Business-Flow Abuse

Automate legitimate workflows in a controlled environment. Determine whether an attacker could repeatedly register accounts, redeem benefits, reserve inventory, post content, or trigger costly third-party operations.

Test SSRF Defences Safely

In an authorized testing or staging environment, assess URL-accepting parameters with controlled callback services and approved internal test destinations.

Review webhook targets, import locations, image sources, document links, feed readers, URL previews, and proxy functionality. Confirm that parsing, destination policies, redirect handling, DNS validation, cloud metadata protections, and network egress controls block prohibited access.

Test Configuration and Inventory

Check TLS enforcement, CORS behavior, production error messages, debug endpoints, administrative interfaces, old versions, and undocumented services. Compare observed network traffic with the official inventory.

Test Third-Party Failure Conditions

Use controlled mocks or staging integrations to return malformed, delayed, oversized, malicious, or unexpected content. Confirm that the consuming service validates responses and fails safely.

High-risk tests should be incorporated into CI/CD where practical. Business-logic scenarios still require thoughtful design, authorized human testing, and periodic review as applications evolve.

Case Study: The 2019 Capital One Incident

Capital One announced in July 2019 that an outside individual had gained unauthorized access to information belonging to credit card customers and applicants. The company said it discovered the incident on July 19, 2019, and attributed the unauthorized access to an exploited configuration vulnerability.

Capital One reported that the incident affected approximately 100 million people in the United States and six million in Canada. The exposed information included credit card application data and portions of existing customer information.

The company reported that approximately 140,000 U.S. Social Security numbers, approximately 80,000 linked bank account numbers, and approximately 1 million Canadian Social Insurance Numbers were compromised. Capital One stated that credit card account numbers and login credentials were not exposed.

Public technical analyses and legal summaries subsequently described an attack chain involving SSRF, cloud instance metadata, temporary IAM credentials, and access to information stored in Amazon S3. These technical accounts should be distinguished from Capital One’s official disclosure, which described the exploited weakness more generally as a configuration vulnerability.

The incident illustrates several connected security failures:

• Server-Side Request Forgery
• Security misconfiguration
• Excessive IAM permissions
• Insufficient blast-radius controls
• Weak protection around sensitive cloud resources

Excessive IAM permissions are important to the attack chain but do not map directly to API10:2023 Unsafe Consumption of APIs.

The broader lesson is that cloud-facing services require several defensive layers. Resource-fetching components need destination controls, workload identities should follow least privilege, metadata services require platform-specific safeguards, storage access should be monitored, and unusual data retrieval should generate actionable alerts.

Securing APIs Used by AI Agents

Agentic AI systems can plan actions and invoke tools through APIs and connection standards such as the Model Context Protocol. This creates risks beyond those for conventional application clients, as a single manipulated instruction can trigger multiple automated operations.

OWASP published the Top 10 for Agentic Applications 2026 on December 9, 2025. It is a separate framework covering agent-specific risks such as goal hijacking, tool misuse, identity and privilege abuse, insecure inter-agent communication, unexpected code execution, and memory or context poisoning.

The two frameworks overlap in important areas, but they should not be treated as equivalent. An overprivileged agent does not automatically indicate BOLA. BOLA exists when an endpoint fails to verify whether the represented principal may access a particular object.

An agent may also misuse permissions that the service correctly enforces but that were granted too broadly.

Agent integrations should use narrowly scoped identities, short-lived credentials, explicit tool permissions, validated parameters, and approval requirements for irreversible or high-impact operations. Logs should preserve which user, agent, tool, and policy decision produced each sensitive request.

The underlying interfaces still require conventional access control, SSRF prevention, schema validation, resource limits, and safe handling of upstream responses. An AI agent should never be treated as a substitute for server-side enforcement.

Security Review Checklist

1. Maintain an inventory of services, versions, environments, owners, data classifications, and dependencies.
2. Keep API specifications accurate and identify sensitive request and response properties.
3. Protect credentials, validate tokens completely, restrict scopes, and use stronger verification for sensitive operations.
4. Enforce function-, object-, tenant-, and property-level authorization on the server.
5. Validate client requests and upstream responses against schemas and business rules.
6. Apply rate limits, quotas, pagination caps, timeouts, query controls, and circuit breakers.
7. Enforce TLS, restrictive CORS policies, secure secret handling, and hardened production configurations.
8. Restrict outbound destinations, validate URLs correctly, control redirects, and enforce egress policies.
9. Monitor suspicious access patterns, privilege failures, unusual traffic volumes, and unexpected external responses.
10. Give AI agents and third-party integrations only the access required for their defined purpose.

Turning the Framework Into an API Program

Establish the Baseline

Build an inventory and identify the interfaces that process sensitive data, expose administrative functions, retrieve remote resources, or implement economically important workflows.

Map those services to relevant risk categories. Prioritize endpoints whose compromise could expose substantial data, affect multiple tenants, interrupt critical operations, or provide access to internal systems.

Define Internal Standards

Document requirements for identity, access control, data handling, schema validation, resource limits, outbound requests, logging, versioning, and deprecation.

Translate the standards into reusable libraries, gateway policies, deployment templates, and infrastructure controls where practical.

Automate Verification

Add authentication, authorization, schema, resource-consumption, SSRF, and configuration tests to development pipelines. Use traffic analysis and service discovery to compare deployed endpoints with the approved inventory.

Automated tools should support the program without replacing threat modelling, architecture review, or manual business-logic testing.

Monitor Runtime Behavior

Collect telemetry across gateways, services, workloads, and significant third-party integrations. Detect repeated identifier manipulation, privilege failures, abnormal request rates, suspicious outbound destinations, unusual data volumes, and unexpected AI-agent behavior.

Improve Continuously

Review incidents, penetration test results, near misses, architectural changes, and new integrations. Update threat models, controls, and test scenarios as services evolve.

Track meaningful outcomes, including fewer authorization failures, faster retirement of obsolete endpoints, reduced exposure of sensitive properties, and improved detection of abusive workflows.

Final Thoughts

API protection is not a one-time compliance exercise. Modern applications depend on microservices, cloud platforms, third-party providers, and AI tools, with each connection introducing another trust relationship that must be understood and controlled.

Use the OWASP API Security Top 10 as an initial threat-modelling and prioritisation tool. Use the OWASP API Security Top 10 as an initial threat-modeling and prioritization tool, then incorporate its risk categories into a broader API security strategy.

Prioritize weaknesses with the greatest potential impact, including object-level authorization failures, broken authentication, SSRF-capable functionality, exposed business flows, configuration drift, and unsafe third-party integrations.

Test those controls through realistic and authorized scenarios rather than assuming that an API gateway, authentication library, or automated scanner provides complete protection. Reassess the system whenever endpoints, identities, infrastructure, business workflows, or external dependencies change.

Securing an API protects more than individual records. It safeguards the users, business processes, connected services, and automated systems that depend on each request being handled within its intended trust boundary.