What is OWASP API security?
The OWASP API Security Project offers software developers and cloud security practitioners guidance on preventing, identifying, and remediating the most critical security risks facing application programming interfaces (APIs).
Unlike traditional web applications, APIs expose application logic and sensitive data directly, including PII, credentials, session tokens, and business rules. This makes them high-value targets for attackers who can bypass traditional perimeter defenses and interact directly with backend services.
Advanced API Security Best Practices [Cheat Sheet]
Download the Wiz API Security Best Practices Cheat Sheet and fortify your API infrastructure with proven, advanced techniques tailored for secure, high-performance API management.
Why OWASP API security matters for DevSecOps and SRE teams
The OWASP API Top 10 framework was established to help engineering and security teams prioritize endpoint hardening across rapid deployment pipelines. As cloud-native architectures grow to rely on heavy automation and interconnected services, ignoring these API-specific design flaws introduces massive systemic risk to production environments.
According to the Wiz 2026 Cloud Threat Retrospective, roughly 80% of documented cloud intrusions stem from long-standing, classic weaknesses rather than novel or exotic techniques. For DevOps and SRE teams, the primary risk is the cascade potential of the attack.
Threat actors are aggressively weaponizing automation to compress exploit cycles, meaning a single authorization flaw or insecure third-party integration can rapidly compromise an entire cloud footprint. Because traditional WAFs and legacy perimeters fail to validate internal application workflows, mastering OWASP API controls is the only way for teams to prevent widespread data exposure without halting pipeline velocity.
What changed? OWASP API Security Top 10 2019 vs. 2023
The first major update to the OWASP API Security Top 10 list came in June 2023. The changes reflect how API threats have shifted from purely technical misconfigurations toward business logic abuse and third-party integration risks.
The 2023 release also reflects how modern cloud-native architectures rely heavily on APIs for automation, integrations, and AI-driven services. As a result, attackers increasingly target API workflows, trust relationships, and exposed backend services instead of only infrastructure weaknesses.
In brief:
API1 (BOLA) and API5 (BFLA) persist conceptually; API8 is now "Security Misconfiguration" (moved from API7:2019).
API3:2019 (Excessive Data Exposure) and API6:2019 (Mass Assignment) merged into API3:2023, Broken Object Property Level Authorization (BOPLA), consolidating risks tied to excessive object field exposure and unauthorized property manipulation.
API4 was updated from Lack of Resources & Rate Limiting to Unrestricted Resource Consumption, stressing the root cause rather than symptoms.
API2 and API9 were renamed with no other changes.
Three new risks were added: Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery (SSRF), and Unsafe API Consumption, reflecting the growing impact of automation abuse, cloud metadata exploitation, and insecure third-party integrations.
Two risks were removed: Injection and Insufficient Logging & Monitoring.
Watch 12-minute demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Watch now
OWASP API Security Top 10 2023: Critical risks explained
Each risk below includes a description of how the vulnerability manifests in real environments, along with cloud-specific mitigation guidance you can implement immediately. The risks are ordered by their OWASP ranking, with authorization failures (BOLA, BFLA) at the top because authentication and authorization flaws remain the most commonly exploited API weaknesses that expose sensitive data.
API1:2023 - Broken Object Level Authorization (BOLA)
BOLA happens when an API accepts object IDs in requests (e.g., user IDs, invoice numbers, or UUIDs) but fails to verify that the authenticated caller is authorized to access or modify that specific object. In multi-tenant cloud environments, this flaw is especially dangerous because a single missing authorization check can let one tenant access another's storage buckets, database records, or configuration data.
When a CSP API lets a tenant access another's storage bucket by tampering with the storage ID value in a GraphQL request, the API has been compromised by a BOLA. Real-world examples of BOLA abound, including the Uber (2016), Facebook (2018), and Trello (2024) breaches, all of which led to the leakage of millions of users' PII.
Mitigation:
Validate JWT tokens at the API gateway and re-validate authorization on backend services (defense-in-depth).
Add trusted claims (e.g., user-id, tenant-id) into headers for internal services to block manipulation.
Implement row-level security for storage and databases, restricting users to rows stipulated in their user IDs.
API2:2023 - Broken Authentication
Broken authentication is a misconfiguration or code vulnerability that lets attackers compromise authentication tokens, API keys, and OAuth implementations to impersonate legitimate users. It involves hijacking tokens exposed to both external clients and internal systems, allowing lateral movement to sensitive resources.
Broken authentication is also frequently exploited through SSRF. In the Capital One breach, an attacker used SSRF to reach the AWS metadata service (IMDSv1), steal IAM role credentials, and exfiltrate over 100 million customer records from S3 buckets. This attack path, documented by Wiz Threat Research, shows why metadata endpoint protection and short-lived credentials are critical authentication controls.
Mitigation:
Defend against credential theft or abuse: In AWS, enforce IMDSv2 and block link-local metadata IP (169.254.169.254) egress from containers/functions.
Use egress-allowlists and VPC egress controls to control outbound traffic to external services, preventing data exfiltration from compromised apps/functions.
Use provider solutions like private endpoints/PrivateLink (AWS) or Private Service Connect (GCP) to keep authentication traffic within the private network.
Mitigate DNS rebinding with strict Host header validation, origin checks, and DNS pinning; avoid relying on DNS for sensitive trust decisions.
What are API attacks?
API attacks are attempts to exploit weaknesses in application programming interfaces – the connectors that let software systems communicate and exchange data.
Read more
API3:2023 - Broken Object Property Level Authorization
This vulnerability entails the failure to properly restrict access to an object's properties or fields. This means that a user may have valid access (authorization) to certain properties or fields but not all, and yet, they can manipulate other sensitive fields within the object. (API6:2019 - Mass Assignment).
Mitigation:
Enforce field-level policies in the backend (not the client).
Prevent mass assignment attacks by deploying explicit field allowlists that stop attackers from injecting unexpected data into payloads.
Implement JSON schema validation, defining schemas (including required and optional fields) and validating all inbound request payloads against the schema before queries are processed.
Configure APIs to ignore or strip unknown fields and enforce readOnly/writeOnly constraints, preventing manipulation of unauthorized properties.
API4:2023 - Unrestricted Resource Consumption
When processing requests, APIs consume resources like memory, network bandwidth, storage, and CPU. Attackers can exhaust these resources by overloading the API with requests, denying legitimate users access to the same services.
This flaw often leads to resource-exhaustion conditions, including Denial of Service, especially when limits, quotas, or timeouts are missing. In cloud environments, successful attacks can also trigger major operational cost increases as autoscaling systems respond to malicious traffic and excessive compute consumption.
Mitigation:
Implement strict rate limiting, throttling, and concurrency limiting for API gateways, serverless functions, and other cloud resources (e.g., AWS Lambda timeout/memory).
Use page size caps to limit data retrieval.
Track baseline traffic behavior and resource usage to spot abnormal consumption patterns early.
API5:2023 - Broken Function Level Authorization (BFLA)
BFLA occurs when APIs are unable to enforce strict validations between certain roles because they're improperly defined.
Take an API that grants a regular user admin access because they sent requests through an endpoint meant for admins. This is easy for attackers to exploit because API endpoints are predictable.
Mitigation:
Separate authorization from application logic using centralized policy as code (PaC), ensuring consistent and automated authorization.
Apply least-privilege through RBAC and ABAC for granular access control.
Define access to API routes and methods (e.g., /admin/ or DeleteUser method) via JWT claims (e.g., scope, groups) and method-level permissions, ensuring only validated requests reach backend services.
API6:2023 - Unrestricted Access to Sensitive Business Flows
APIs commonly expose business flows like ticket purchases, discount claims, and reservation workflows.
Without safeguards, attackers can abuse these legitimate functions to disrupt operations, automate fraud, or exploit revenue-generating processes at scale.
Mitigation:
Use unique per-client fingerprinting to deny access to suspicious clients (e.g., headless requests).
Deploy captcha, biometric detection monitors, and baseline monitoring to spot human and non-human suspicious activity (e.g., erratic navigation).
Stop business logic exploits with stateful rules that ensure APIs are never exposed without validating all contextual requirements.
The Best Open-Source API Security Tools and When to Use Them
Discover top OSS API security testing tools. See how Wiz’s Dynamic Scanner delivers complete visibility, runtime protection, and contextual risk analysis.
Read more
API7:2023 - Server Side Request Forgery (SSRF)
When a client (malicious actor) can induce an API to access a URL without proper validation, this is a case of SSRF. Attackers can then leverage this API security risk to move laterally to internal APIs and services, conduct privilege escalation, and interact with malicious external systems.
Mitigation:
Validate user input against an allowlist of permitted input (e.g., domains, IP ranges, media types, URL schemes).
Use provider metadata protections (e.g., AWS IMDSv2 with hop limits, Azure Managed Identities, and GCP's Metadata-Flavor: Google header requirement) to reduce the risk of credential theft from metadata endpoints.
Implement network segmentation, especially on APIs interacting with external resources, to cut off traffic to internal IPs.
API8:2023 - Security Misconfiguration
Security misconfigurations expose APIs to a wide range of risks, from attackers exploiting default settings that expose credentials to overly permissive CORS policies that grant cross-site access across untrusted domains.
Yet another example is unencrypted channels that let attackers exploit vulnerable administrative endpoints.
Mitigation:
Enforce secure defaults (e.g., TLS by default, automated secret rotation, private-only access to storage buckets, and least-privilege identity permissions).
Automated, version-controlled configuration management via infrastructure as code (IaC) for consistent, scalable API security.
Implement configuration hardening by deactivating unneeded features to shrink the attack surface, e.g., HTTP methods like TRACE on the API gateway.
API9:2023 - Improper Inventory Management
Improper inventory management is a flaw that leaves shadow, outdated, or deprecated endpoints running and exposed. This allows attackers to find them via basic searches like Google dorking or DNS enumeration. Because these APIs are unmonitored and have weak controls, they are easy targets for attackers.
Mitigation:
Ensure continuous API discovery, documentation, and lifecycle management.
Code-to-cloud correlation: Tie discovered APIs to their backing services, identities, and data stores to identify shadow endpoints and owners quickly.
API10:2023 - Unsafe API Consumption
Some applications are designed to implicitly trust API integrations, including third-party APIs. But if this is done without adequate security controls like authentication and input validation, you will be exposed to this API risk.
When these controls are missing in external APIs you consume, it allows threat actors to inject malicious payloads that alter queries and data flows via injection attacks like SQLi or SSRF.
Mitigation:
Enforce outbound allowlisting/egress filtering at the API gateway (or service mesh) for centralized, consistent security control enforcement.
Use TLS certificate pinning, mTLS, and signed requests to verify client/server identity and prevent communications from being intercepted.
Scan all third-party dependencies for vulnerabilities via SCA and SBOM.
How Wiz strengthens OWASP API security across cloud environments
Wiz API Security Posture Management (API-SPM) maps OWASP API Top 10 risks to your actual cloud environment, not a generic checklist. Wiz discovers every API across your code-to-cloud topology, including unmanaged, shadow, and zombie endpoints, without deploying agents.
Once discovered, Wiz actively tests APIs against OWASP API Top 10 risks using Red Agent, an AI-powered crawler that reads API specifications, reasons about application logic, and executes multi-step attack sequences to validate whether a BOLA, BFLA, or SSRF flaw is actually exploitable. This goes beyond passive traffic monitoring: Red Agent uncovers "shadow" APIs embedded in client-side JavaScript that traditional scanners miss entirely.
Wiz then projects these findings onto the unified Security Graph, correlating API vulnerabilities with misconfigured IAM permissions, network exposure paths, and sensitive data stores. This reveals Toxic Combinations: the specific scenarios where an exposed API with a broken authorization flaw connects to a database containing PII. Instead of triaging hundreds of low-context alerts, security teams see the five attack paths that actually put the business at risk.
For organizations building with AI, Wiz AI-APP extends this visibility to AI-integrated API endpoints and frameworks like LangChain, ensuring that new AI-driven data pipelines do not become unmonitored entry points.
Get a demo to see how Wiz transforms your API security strategy from isolated alert tracking into risk-prioritized threat management.
Secure APIs from code to cloud
See how Wiz gives security teams instant visibility into API exposure, misconfigurations, and attack paths.
