OWASP API 2023

Home
Application Security
OWASP API 2023

API1:2023 Broken Object Level Authorization

Broken Object Level Authorization occurs when an API exposes endpoints that handle object identifiers (like user IDs or resource IDs) but fails to properly verify whether the requester has access rights to the object. This allows attackers to manipulate object IDs in the URL or request body to gain unauthorized access to data. It's a common and critical issue in APIs, especially those exposing many endpoints and resources. The solution is to enforce authorization checks at the object level for every access attempt, regardless of whether the request is from a trusted user, device, or internal system.

API2:2023 Broken Authentication

Broken Authentication refers to weaknesses in an API’s authentication mechanisms that allow attackers to compromise authentication tokens or exploit implementation flaws to impersonate users. Common issues include poor password policies, predictable login endpoints, exposed authentication tokens, and failure to invalidate sessions after logout or password changes. These flaws can lead to unauthorized access and data breaches. To prevent this, use strong authentication methods like multi-factor authentication, securely store and transmit credentials, implement token expiration and rotation, and follow best practices for session management and error handling. Authentication should always be consistent, secure, and regularly tested for vulnerabilities.

API3:2023 Broken Object Property Level Authorization

Broken Object Property Level Authorization happens when an API correctly restricts access to an object but fails to control access to specific properties within that object. For example, a user might be allowed to view their profile but shouldn't be able to change roles or access admin-only fields. If the API doesn't enforce fine-grained authorization checks on each property, attackers can manipulate requests to read or modify sensitive data. This often occurs in PUT or PATCH requests. The fix is to apply authorization at both the object and property levels, ensuring only permitted fields are exposed or modifiable per user role.

API4:2023 Unrestricted Resource Consumption

Unrestricted Resource Consumption occurs when an API allows clients to consume excessive server resources without proper limits, leading to degraded performance or denial of service. Attackers can exploit this by sending large payloads, making too many requests, or requesting resource-heavy operations repeatedly. Without controls like rate limiting, payload size restrictions, or execution timeouts, APIs become vulnerable to abuse. This issue affects availability and scalability. To prevent it, implement safeguards such as throttling, quotas, pagination, and resource usage monitoring. Always validate input sizes and apply strict limits to protect backend systems from being overwhelmed by malicious or unintentional overuse.

API5:2023 Broken Function Level Authorization

Broken Function Level Authorization occurs when an API fails to enforce proper authorization checks before allowing access to sensitive functions or operations. While users might be authenticated, they can still perform actions beyond their privileges, like a regular user accessing admin functions—if the API does not validate roles or permissions properly. This often happens when frontend role controls are assumed to be enough. The solution is to enforce strict authorization on every function at the API level, ensuring that only users with the correct roles can execute specific actions, regardless of how the request was formed or who sent it.

API6:2023 Unrestricted Access To Sensitive Business Flows

Unrestricted Access to Sensitive Business Flows occurs when APIs expose critical operations—like checkout, account registration, or financial transactions—without protections against abuse. Attackers can automate these flows to perform fraud, spam, or resource exhaustion. Unlike typical vulnerabilities, this targets business logic, not just security flaws. APIs that lack safeguards like rate limiting, behavioral analysis, or step-by-step validation are especially vulnerable.

API7:2023 Server Side Request Forgery

Server Side Request Forgery (SSRF) occurs when an API allows a client to supply a URL or network location, and the server uses it to make a request without properly validating it. Attackers exploit this to make the server send requests to internal systems, cloud metadata endpoints, or other protected resources. This can lead to information disclosure, port scanning, or even remote code execution. APIs that fetch URLs, import data, or integrate with external systems are especially at risk. To prevent SSRF, validate and restrict destination URLs, avoid using user input directly in requests, and use allow-lists.

API8:2023 Security Misconfiguration

Security Misconfiguration refers to improperly configured security settings in APIs or their infrastructure. This includes overly verbose error messages, default credentials, unnecessary HTTP methods, misconfigured CORS policies, exposed admin panels, or lack of secure headers. Such misconfigurations can give attackers valuable information or unintended access. They often result from default settings, rushed deployments, or lack of security reviews. To prevent this, enforce a secure-by-default configuration, disable unnecessary features, regularly audit and harden settings, and automate security testing. APIs should be deployed with the minimum necessary access and regularly reviewed for gaps in configuration or exposure.

API9:2023 Improper Inventory Management

Improper Inventory Management occurs when organizations fail to properly track and manage all their API endpoints, including older versions, hidden endpoints, or undocumented APIs. Attackers can discover and target these forgotten or shadow APIs, which often lack proper security controls, logging, or monitoring. This creates a larger attack surface and increases the risk of breaches. Causes include poor versioning practices, lack of asset inventory, and inconsistent deployment processes. To prevent this, maintain an up-to-date API inventory, deprecate unused versions, and apply consistent security policies across all endpoints—public, private, and internal. Visibility and control are key to reducing risk.

API10:2023 Unsafe Consumption Of APIs

Unsafe Consumption of APIs refers to the risks that arise when an application integrates with third-party or external APIs without properly validating their behavior, responses, or trustworthiness. If the consuming application blindly trusts external APIs, it can become vulnerable to data leaks, injection attacks, or system compromise. Common issues include accepting unvalidated input, not handling unexpected responses securely, or trusting data from unauthenticated sources. To prevent this, always validate and sanitize external API responses, enforce strict data schemas, apply timeouts and error handling, and only consume APIs from trusted sources. Never assume external systems behave securely or consistently.