OWASP API Top 10 Threats & 10 Ways to Mitigate Them

• Why API Security Requires a Dedicated Risk Framework
• The OWASP API Security Top 10 Vulnerabilities (2023)
• Key Differences Between OWASP API Top 10 2023 vs. 2019

• Best Practices for Preventing OWASP API Top 10 Risks
• API Security with Radware

Reconnaissance: In the first stage, attackers probe for exposed endpoints, analyze API documentation, inspect request/response patterns, and identify potential entry points. Tools like Postman, Burp Suite, or custom scripts are commonly used during this phase.

Authentication and authorization testing: Attackers try to bypass authentication mechanisms or escalate privileges, often exploiting weaknesses like predictable tokens, poorly managed sessions, or missing authorization checks at the object or function level.

Exploitation: Attackers attempt targeting vulnerabilities such as broken object level authorization or injection flaws to access or modify sensitive data. This may also involve chaining multiple issues, like combining improper inventory management with insecure direct object references (IDORs), to maximize impact.

Persistence or abuse: Attackers may leverage access for data exfiltration, service disruption, or financial fraud. This lifecycle highlights the importance of continuously monitoring and securing all stages of API interaction.

API1:2023 Broken Object Level Authorization (BOLA)

Broken object level authorization (BOLA) remains one of the most common and serious security risks in APIs. This vulnerability occurs when API endpoints fail to properly enforce authorization on object references, allowing attackers to access, modify, or delete data belonging to other users simply by guessing or manipulating object identifiers.

For example, if an API allows a user to retrieve account information by specifying an account ID in the URL, incomplete authorization checks may let one user view or edit someone else’s data. Mitigating BOLA requires strict checks at every endpoint that accesses resources or objects. Authorization must be implemented server-side and should verify not just authentication, but also whether the authenticated user actually has permission to interact with the specified object.

API2:2023 Broken Authentication in API Contexts

Broken authentication refers to weaknesses in how APIs manage identity and session controls, leading to unauthorized access when these processes are bypassed or subverted. Unlike traditional web applications, APIs must handle stateless authentication and may expose multiple endpoints that require unique authentication flows.

Sending tokens over insecure channels, failing to enforce token expiration, or mismanaging session states are all common errors that attackers exploit to impersonate legitimate users or escalate privileges. Securing authentication in APIs goes beyond simple password controls. Robust implementations should include strong token management, support for standards like OAuth or OpenID Connect, and should strictly validate every authentication attempt.

API3:2023 Broken Object Property Level Authorization (BOPLA)

Broken object property level authorization (BOPLA) introduces a finer distinction in API vulnerabilities, focusing on authorization checks at the individual property level of objects returned by the API. Even if a user is entitled to access an object, they may not have access to all its fields.

For example, a standard user may be able to see their own account record but should not be able to see sensitive fields like internal flags, administrative notes, or third-party identifiers. Lack of granular controls at this level enables data exposure that attackers can exploit.

Addressing BOPLA means ensuring that every property in response payloads and request bodies is subject to proper access controls. Developers must implement field-level authorization logic, typically enforced by the backend, to prevent overexposure of sensitive data attributes.

API4:2023 Unrestricted Resource Consumption

APIs without limits on resource consumption present a massive risk surface, easily exploited by attackers or misbehaving clients. Unrestricted resource consumption occurs when APIs allow excessive use of compute, memory, storage, or network bandwidth, leading to denial-of-service (DoS), increased operational costs, or cascading system failures.

These vulnerabilities are particularly dangerous in cloud and microservices contexts where APIs underpin business processes and automation. To prevent these attacks, APIs must enforce strict resource quotas such as rate limiting, response size reductions, and concurrent request controls at both the gateway and backend layers.

API5:2023 Broken Function Level Authorization (BFLA)

Broken function level authorization (BFLA) occurs when APIs fail to verify whether a user is authorized to execute specific actions, even if object-level permissions are enforced. For example, administrative functionalities, such as user management or configuration changes, may be accessible to unauthorized roles because the API only checks authentication or does not enforce sufficient role-based access control (RBAC).

Attackers who gain access to these endpoints can conduct privilege escalation or abuse critical functions. Defending against BFLA requires clearly defined privilege boundaries and tight mapping of business roles to function permissions. Every sensitive operation exposed via the API should trigger explicit access checks, not just authentication.

API6:2023 Unrestricted Access to Sensitive Business Flows

APIs frequently automate business processes, and unrestricted access to sensitive business flows creates opportunities for attackers to manipulate business logic for fraud, abuse, or unauthorized operations. This vulnerability extends beyond technical exploitation to encompass misuse of the legitimate behaviors APIs enable, such as repeated purchases, transaction bypasses, or privilege escalations simply by automating API calls without checks.

Mitigating this risk involves understanding business logic as an attack surface. Organizations should document critical paths, enforce rate limits, and build contextual validation into API endpoints that process business transactions. Continuous monitoring, anomaly detection, and regular reviews of transaction flows help ensure only intended patterns are supported, blocking business logic abuse before it leads to systemic impact or monetary loss.

API7:2023 Server-Side Request Forgery (SSRF) in APIs

Server-side request forgery (SSRF) in APIs happens when an endpoint allows attackers to cause backend servers to make unintended requests, often targeting internal systems inaccessible to the public. SSRF may arise if an API accepts user-supplied URLs or request destinations without validation, and then fetches data or triggers actions on behalf of the client.

This can result in internal data leakage, enumeration of private infrastructure, or remote code execution. To defend against SSRF, APIs must tightly validate any external requests, implement allow-lists for destination hosts, and reject potentially dangerous protocols or IP ranges. Network-level segmentation and firewalls further reduce risk, alongside input sanitization and output filtering.

API8:2023 Security Misconfiguration in API Infrastructure

API infrastructures often consist of layered components (API gateways, reverse proxies, microservices, databases) each introducing opportunities for misconfiguration. Security misconfiguration in APIs may manifest as default credentials, unnecessary HTTP methods, overly permissive cross-origin resource sharing (CORS) settings, missing encryption, or inconsistent error handling.

Attackers actively look for these weaknesses to gain unauthorized access, intercept data, or disrupt services. Preventing misconfiguration requires strong change management, automation, and adherence to configuration baselines. Organizations should establish consistent deployment patterns, use secure-by-default templates, and regularly audit configurations for drift.

API9:2023 Improper Inventory Management

APIs evolve rapidly, and improper inventory management creates risks when organizations have incomplete visibility into the APIs they expose. Orphaned, deprecated, or undocumented endpoints become easy targets for attackers, especially in complex environments with continuous integration and deployment. Without accurate asset tracking, security monitoring and risk assessment are unreliable, leading to blind spots and unpatched vulnerabilities.

Solving this challenge requires automated API discovery, continuous cataloging, and rigorous version control. Visibility must extend to internal, partner, and public APIs. Effective inventory management enables timely incident response, mapping of data flows, and proper decommissioning of obsolete components. Organizations need reliable processes and automated tooling to keep pace with rapid growth and evolving API portfolios.

API10:2023 Unsafe Consumption of APIs

APIs commonly depend on third-party or partner services, introducing risks if external APIs are integrated or consumed without proper safeguards. Unsafe consumption of APIs includes trusting responses without validation, failing to handle errors or malicious payloads, and exposing sensitive credentials in outbound requests.

Attackers may manipulate external dependencies or inject malicious data to compromise the local system or trigger data exfiltration. Mitigating this risk requires adopting defensive consumption patterns, including rigorous response validation, fallback mechanisms, and secure storage of connection secrets. Ongoing vetting of third-party APIs for security maturity, compliance, and reliability is also essential.

1. Enforcing Strong Object- and Property-Level Authorization

To prevent unauthorized access to sensitive resources, APIs must implement strict controls at both the object and property levels. This involves enforcing precise access rules based on user roles, ownership, and the business context of each request.

• Enforce authorization at both the object and property levels to prevent broken object level authorization (BOLA) and broken object property level authorization (BOPLA). Define granular access controls that align with user roles and scopes.
• Use allowlist-based access enforcement to explicitly define which users or roles can access specific resources or fields. Avoid relying on deny lists or default access.
• Apply business logic checks to ensure users cannot traverse to unauthorized objects or manipulate fields beyond their privileges. Validate ownership and context-specific constraints on each request.
• Validate authorization after authentication and any contextual checks. Ensure that all data access and operations are gated by explicit and validated access policies.

2. Implementing Robust Authentication Flows

Strong authentication flows are critical to defending against unauthorized access and automated attacks. A secure implementation combines multiple layers of protection to verify user identity and detect suspicious behavior.

• Enforce multi-factor authentication (MFA), strong credential policies, and secure session management. Ensure sessions are short-lived, tied to specific devices, and protected against hijacking.
• Protect against brute-force and credential-stuffing attacks by monitoring login attempts and blocking automated tools. Implement account lockouts or challenge mechanisms after repeated failures.
• Use rate limiting, behavioral detection, and IP/device risk scoring to identify abnormal access patterns. Dynamically adjust authentication requirements based on the assessed risk.

3. Designing APIs for Predictable Resource Consumption

To ensure APIs scale reliably and resist abuse, it’s important to design for predictable resource usage. This involves enforcing limits and validating requests to prevent excessive load or misuse of expensive operations.

• Apply quotas, timeouts, and concurrency limits to restrict how often and how long clients can interact with the API. Tailor these limits based on user roles or subscription tiers.
• Include business logic validation to detect and block abuse of costly operations, such as repeated initiation of resource-heavy workflows or excessive use of nested queries.
• Restrict access to high-cost endpoints using role- and context-based rules. Only authorized users should trigger operations with significant processing or financial impact.

4. Hardening API Infrastructure Configurations

Misconfigured infrastructure can expose APIs to serious vulnerabilities. Securing the API environment requires consistent configurations, automated validation, and layered defenses across the stack.

• Standardize secure defaults, enforce schema validation, and apply strict input handling. Validate both request structure and content to reduce the risk of injection and deserialization attacks.
• Reduce misconfigurations through automated security policies and continuous environment scanning. Use infrastructure-as-code (IaC) tools to detect and fix insecure settings before deployment.
• Integrate multi-layered protection across layers 3 through 7, including network-level filtering, protocol enforcement, and application-layer controls. Each layer should enforce consistent security expectations.

5. Maintaining Accurate and Automated API Inventories

Keeping an up-to-date inventory of all APIs is essential for managing security risks and preventing exposure from forgotten or unmonitored endpoints. Automation aids in maintaining visibility.

• Continuously discover shadow, dormant, or orphaned APIs using automated runtime API discovery. Relying solely on documentation or source code is not sufficient to capture all active endpoints.
• Track API versions, schemas, and deprecation status to ensure outdated or unsupported interfaces are properly managed or retired. Maintain clear versioning policies across environments.
• Apply schema enforcement at runtime to validate incoming requests against expected structures. This helps detect unexpected usage and prevents exposure from undocumented inputs.

6. Securing Integrations and Outbound API Calls

APIs often depend on external services, making it essential to secure both integrations and outbound calls. Improperly handled interactions can lead to data exposure, logic abuse, or server-side request forgery (SSRF).

• Validate both upstream and downstream dependencies to ensure third-party services meet security standards. Monitor for changes that could introduce risks or break trust boundaries.
• Apply logic-level validation on chained workflows and service integrations. Confirm that each step in a multi-system process enforces proper authorization and input validation.
• Implement SSRF protections by using outbound allowlists and strict destination verification. Ensure the API can only communicate with approved external services and validate all request parameters.

7. Applying Schema Validation and Input Controls

Schema validation and input controls are essential for reducing attack surface and ensuring consistent request behavior. APIs should strictly enforce what input is allowed and reject anything unexpected.

• Enforce strict request and response schemas to define exactly what data is accepted and returned. Validate against these schemas at runtime to catch malformed or malicious requests early.
• Block unexpected fields, data types, or deeply nested queries. This is especially critical in GraphQL APIs to prevent introspection abuse, excessive query depth, or data leakage.
• Apply consistent input controls across all endpoints, including checks on parameter length, format, and allowed values. Use centralized validation logic to reduce gaps in enforcement.

8. Ensuring Visibility into API Workflows and Business Logic

Understanding and securing API workflows requires full visibility into how users interact with business logic across multiple steps. Security controls must account for the intended sequence and context of operations.

• Map complete API workflows, such as login → transaction → confirmation, to understand typical usage patterns. Use this mapping to detect deviations from expected sequences or abuse of intermediate steps.
• Deploy business logic abuse (BLA)-focused policies that define and enforce valid transitions between API functions. Block out-of-sequence or contextually invalid operations.
• Monitor contextual attributes like user roles, step order, and environment (e.g., production vs. test) to ensure that API calls are consistent with legitimate workflows. Use this data to flag or block anomalous behavior.

9. Business Logic and GraphQL-Specific Protection

GraphQL APIs introduce unique risks due to their flexible query structure and depth. Protecting them requires both general business logic controls and GraphQL-specific enforcement mechanisms.

• Apply resolvers, depth limits, and query complexity checks to prevent resource exhaustion and abuse. Restrict how deeply queries can nest and how much data they can request in a single call.
• Prevent business logic bypass by validating nested queries and blocking high-cost operations that could be triggered through complex query chaining.
• Enforce per-field and per-operation authorization to control access at a granular level. Ensure each field or mutation respects the caller's role, scope, and contextual permissions.

10. API Attack Lifecycle Visibility and Multi-Layered Protection

Protecting APIs requires visibility across the full attack lifecycle, from initial probing to exploitation and beyond. A unified, layered defense helps detect, prevent, and respond to threats in real time.

• Detect all phases of the API attack lifecycle, including reconnaissance, enumeration, exploitation, and post-exploitation activities. Monitor for unusual patterns in access, payloads, and response behaviors.
• Combine WAF, bot mitigation, behavioral analytics, and API-specific security controls into a single integrated model. Correlate signals across layers to improve detection accuracy.
• Support both preventive and responsive controls. Block known attack patterns in real time and enable fast incident response through alerting, logging, and automated remediation workflows.