You may have heard of the OWASP before. It is the Open Web Application Security Project.

In 2019, the OWASP group determined that with the adoption of APIs, there was a need for an API-specific Top 10 – and that’s what you see on the right. The API Security Top 10 was first issued in 2019. There’s some overlap with the Web App Top 10, but a whole lot of new unique requirements for the API Top 10.

In 2023, a new edition of the OWASP API Top 10 was released. Let’s talk through the OWASP API Security Top 10 based on 2023.

API1: Broken Object Level Authorization (BOLA)

  • Most common and damaging API vulnerability.
  • Involves manipulating IDs to impersonate other users and access data.
  • This is a common issue because servers usually do not track the client’s state – rely on object IDs to determine authorization.
Risk Exposure This can lead to data loss, disclosure, data manipulation
  • Attacker authenticates as User A and then retrieves data on B, C, D …
  • The attacker modifies accounts to perform transactions as another User
  • Define data access policies and implement associated controls.
  • Ensure the authenticated user is authorized to request data.
  • Implement automated testing to identify BOLA vulnerabilities.

API2: Broken Authentication

Description Weak or poor authentication creates vulnerability:
  • Missing security controls
  • Poorly implemented controls
Risk Exposure Attackers can gain control of users’ accounts. Theft of data. Unauthorized transactions.
  • Weak password requirements
  • Credential stuffing: brute force ID/PW
  • No captcha/rate limiting/lockout
  • Auth info in URLs (tokens, passwords)
  • Changing passwords w/o verification
  • Non-validation of token authenticity
  • Non-validation of JWT expiration Insecure password storage
Prevention Define authentication policies and standards; follow best practices

API3: Broken Object Property Level Authorization

  • Exploit endpoints by reading and/or modifying the values of objects.
  • Mass Assignment: ability to update object elements (e.g., account type)
  • Excessive Data Exposure: revealing sensitive data that aren’t necessary
Risk Exposure Revealing protected user data.
  • The user is able to set “account- type=premium”
  • User search endpoint returns excessive, unnecessary details (name, email, address, ID, …)
  • Ensure the user can only access legitimate, permitted fields.
  • Return only the minimum amount of data required for the use case.

API4: Unrestricted Resource Consumption

Description Formerly Lack of Resources and Rate Limiting. Inadequate traffic control can allow:
  • Mass data retrieval
  • Risk of operation interruption
Risk Exposure Denial of service, data harvesting
  • Missing or inadequate volume controls (set too high)
  • Execution timeouts
  • Max allocable memory
  • Max number of file descriptors
  • Max file upload size
  • Excessive operations in a single request
  • Excessive records returned in a single request
  • Implement traffic controls.
  • Test effectiveness of controls.

API5: Broken Function Level Authorization

  • Using API functionality to modify (create, update, delete) resources of another user.
  • Often involves replacing passive methods (GET) with active ones (PUT, DELETE).
  • Can be used to escalate privilege.
Risk Exposure
  • Provide attacker access to unauthorized endpoints and functionality.
  • Can be exploited to modify account details and access administrative functions.
  • Replacing GET with PUT.
  • Modify URL parameters (“role = admin”, “account-type = premium”).
  • Deleting an invoice
  • Setting account balance = $0 (or negative)
  • Identify functions that expose high sensitivity capability and develop controls to limit access.
  • Implement continuous release testing to ensure proper behavior.

API6: Unrestricted Access to Sensitive Business Flows

  • Abuse of a legitimate business workflow through excessive, automated use
  • Rate-limiting, captchas are not always effective against fraudulent traffic
  • Rapid IP rotation makes detection difficult
  • Typically, a result of an application logic flaw
Risk Exposure Loss of critical business activity
  • Mass, automated ticket purchasing
  • High-volume referral bonuses
  • Identify critical business workflows.
  • Implement fraudulent traffic detection and control.
  • Setup and automate testing of control mechanisms.

API7: Server-Side Request Forgery

Description Exploiting URL inputs to request a malicious, 3rd party server
Risk Exposure
  • SSRF creates a channel for malicious requests, data access, or other fraudulent activity
  • Potential for data leaks
Examples Local file injection (LFI) User submits: http://localhost/api/user-data Malware downloaded from a malicious site
  • Validate and sanitize ALL user-supplied information, including URL parameters.
  • Ensure communication is only permitted with trusted resources.
  • Test URL validation effectiveness.

API8: Security Misconfiguration

  • The broad category encompasses a lack of hardening to unnecessary services
  • Use of bots to scan, detect, and exploit misconfigurations
Risk Exposure
  • Misconfigurations can expose sensitive user data
  • Potential for full server compromise
  • Lack of security hardening
  • Improperly configured permissions
  • Missing security patches
  • Unnecessary features enabled
  • Missing TLS
  • CORS policy missing/improperly set
  • Implement hardening procedures
  • Routinely review configurations
  • Implement automated, continuous security testing

API9: Improper Inventory Management

Description Unauthorized API access via old, unused API versions, or through trusted 3rd parties.
Risk Exposure
  • Data/account theft via unretired APIs.
  • Exposure of sensitive data via improperly secured 3rd party APIs.
  • Old versions of APIs
  • Unpatched endpoints
  • Endpoints with weaker security requirements
  • API access through 3rd party
  • Outdated documentation
  • Unnecessarily exposed endpoints
  • Enforce a strict policy for deploying all APIs (in a gateway).
  • Implement rules and processes for API versioning and retirement.
  • Periodically audit 3rd party API access and ensure satisfactory protection.

API10: Unsafe Consumption of APIs

Description Exposures can occur via the use of 3rd party APIs, which are generally trusted. However, 3rd parties can be exploited, which can be used to attack APIs that rely on them.
Risk Exposure Data theft, breach, account takeover
Examples The attacker inserts malicious data to address the validation site used by the Client. The attacker submits a request to the Client to specifically pull exploited data from 3rd party. The client fails to validate data and gets exploited. The attacker compromises 3rd party API causing it to respond with a redirect to the malicious site. The client blindly follows redirects without validation.
  • Evaluate security controls of 3rd party API. Validate data returned by 3rd party APIs. Encrypt all API communication.
  • Maintain an approved list of known locations where integrated APIs may be redirected.


Content owner: APIsec University

Instructor: Dan Barahona, APIsec University Founder and Instructor

Dan brings over 20 years of cybersecurity experience with executive roles at APIsec, Qualys, Anomali, ArcSight, and others. Dan co-founded APIsec University with Corey Ball in 2022 to help develop a new army of API security defenders.

OWASP API Security Top 10

Leave a Comment