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).
The Open Worldwide Application Security Project (OWASP) Foundation, known for its web application security initiatives, released its first OWASP API Security Top 10 list in 2019. The project created awareness on and mitigation for prominent attack vectors API developers faced at a time when APIs were rapidly being adopted and security was an afterthought.
The threat landscape has changed since the list’s 2019 inaugural release, and the 2023 OWASP API Security Top 10 reflects this.
Research shows that API threats are prevalent, with Akamai reporting a 32% uptick in API attacks exploiting the OWASP API Security Top 10 risks. Unfortunately, traditional perimeter defenses fall severely short at protecting businesses against API risks.
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.
What changed? OWASP API Security Top 10 Risks 2019 vs. 2023
The first major update to the OWASP API Security Top 10 list came in June 2023, when some previous categories were either merged or renamed, and three new categories were added.
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 to form API3:2023 – Broken Object Property Level Authorization (BOPLA).
API4 was updated from Lack of Resources & Rate Limiting to Unrestricted Resource Consumption, stressing the root cause of both risks mentioned in the 2019 API4 category.
API2 and API9 were also renamed with no other changes.
A new risk, Unrestricted Access to Sensitive Business Flows, took the place of the now merged Mass Assignment.
Also new, Server-Side Request Forgery (SSRF) appears as API7:2023. “Security Misconfiguration” moved to API8. The 2023 list removed “Injection” and “Insufficient
Logging & Monitoring,” and added “Unsafe API Consumption,” “Unrestricted Access to Sensitive Business Flows,” and “SSRF.
Lastly, Unsafe API Consumption, also newly added, pushed Insufficient Logging & Monitoring out of the Top 10 entirely.
Watch 5-minute demo
Watch the demo to learn how Wiz Code scans infrastructure as code, container images, and CI/CD pipelines to catch risks early—before they reach the cloud.
Watch now
The OWASP API Top 10 Security Risks 2023: Critical risks explained
Below are the top risks, discussed in order.
API1:2023 - Broken Object Level Authorization (BOLA)
The BOLA vulnerability makes an API trust object IDs (e.g., user IDs, invoice numbers, or UUIDs) in user requests, failing to properly validate whether the user is authorized to access or modify the target object.
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.
Selectively allow access to objects for storage and databases by implementing row-level security, 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 often exploited through SSRF, e.g., the Capital One SSRF-to-metadata incident.
Mitigation:
Defend against credential theft or abuse, e.g., 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.
API Governance: Best Practices & Solutions
API governance refers to the policies, standards, and processes that guide how APIs are built, managed, and secured.
En savoir plusAPI3: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 are able to 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 need various resources, e.g., memory, network bandwidth, storage, and CPU. Attackers can exhaust these resources by overloading the API with requests to deny 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.
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.
Top 9 OSS API Security Tools
A guide on the 9 best OSS API security tools that protect sensitive data, infrastructure, and business logic from unauthorized access, data theft, and other attacks.
En savoir plus
API6:2023 - Unrestricted Access to Sensitive Business Flows
APIs expose certain business flows like ticket purchase, discount claims, or reservation workflows by default.
When these legitimate functions are exposed without safeguards in place, attackers can exploit them to harm the target business.
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.
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 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.
API Security Checklist 2025: OWASP-Aligned, Code-to-Cloud Best Practices
An API checklist serves as a framework to help your security team systematically detect and tackle threats and vulnerabilities throughout the API lifecycle. Its end goal? To strengthen your overall security posture by standardizing API security efforts.
En savoir plusAPI10: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
Securing APIs is a lot of work — continuous monitoring, countless mitigation strategies to implement; so, manual processes simply won’t do. Instead, Wiz automates API security at scale via:
Automatic API discovery throughout the code-to-cloud pipeline via Wiz Code and Wiz Runtime Sensor.
Exposure validation with Dynamic Scanner, correlating vulnerabilities, exposed endpoints, and cloud context with attacker TTPs.
Wiz maps OWASP API Top 10 risk categories to actionable security controls across the code-to-cloud lifecycle.
Graph-prioritized remediation maps attack paths providing context on how API risks connect across data, identities, workloads, etc., and ranking risks based on live exploit data and business impact.
Ready to see unified API visibility from code to cloud and risk-prioritized remediation in action? Get a demo to see how risks across APIs, identities, data, and workloads map to real attack paths.
Catch code risks before you deploy
Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.
