OWASP Top 10 API Security Risks for Real

Real examples of API security breaches • Mapping to OWASP API Security Top 10 – 2023 • Practical mitigation strategies


Here are real examples of API security breaches, how they map to the OWASP API Security Top 10 (2023), and practical mitigation strategies to prevent or minimise their impact.


Click on each heading to go to a detailed explanation.


API1:2023 (BOLA): Facebook “View As” 2019
  • What Happened in the Facebook "View As" Breach
  • How This Relates to BOLA
  • Why This is an Example of BOLA
  • Key Takeaways
  • Mitigation
API2:2023 Broken Authentication: Twitter 2020
  • What Happened in the Twitter 2020 Breach
  • How This Relates to Broken Authentication
  • Key Elements of the Breach Related to API2:2023 Broken Authentication
  • Why This is an Example of Broken Authentication
  • Mitigation Steps to Address API2:2023 Broken Authentication
API3:2023 (BOPLA): LinkedIn 2021
  • What Happened in the LinkedIn 2021 Incident
  • How This Relates to OWASP API3:2023 Broken Object Property Level Authorization
  • Key Elements of the LinkedIn Incident Related to API3:2023 BOPLA
  • Why This is an Example of Broken Object Property Level Authorization
  • Mitigation Steps to Address API3:2023 Broken Object Property Level Authorization
  • Conclusion
API4:2023 Unrestricted Resource Consumption: GitHub 2020
  • What Happened in the GitHub 2020 DDoS Attack
  • How This Relates to OWASP API4:2023 Unrestricted Resource Consumption
  • Key Elements of the GitHub DDoS Incident Related to API4:2023
  • Why This is an Example of Unrestricted Resource Consumption
  • Mitigation Steps to Address API4:2023 Unrestricted Resource Consumption
  • Conclusion
Multiple Vulnerabilities: Optus 2022
  • API1:2023 Broken Object Level Authorization (BOLA)
  • API3:2023 Broken Object Property Level Authorization (BOPLA)
  • API4:2023 Unrestricted Resource Consumption
  • API6:2023 Unrestricted Access to Sensitive Business Flows
  • API8:2023 Security Misconfiguration
  • API9:2023 Improper Inventory Management
  • Conclusion

API1:2023 (BOLA): Facebook “View As”

The 2019 Facebook "View As" vulnerability is a textbook example of OWASP API1:2023 Broken Object Level Authorization (BOLA) because it allowed attackers to access user data by exploiting weak authorization at the object level.

What Happened in the Facebook "View As" Breach:

  • The "View As" feature was designed to let users see their profile from the perspective of someone else. However, this feature interacted with an API that contained a flaw in how it handled access tokens.
  • Attackers discovered they could manipulate the "View As" function to trick Facebook into generating access tokens not for their own account but for the accounts of other users. These access tokens act as session keys, allowing access to personal data and actions within an account.
  • By obtaining the tokens, attackers could access and take control of those accounts, viewing personal information or performing actions as the victim.

How This Relates to BOLA:

Broken Object Level Authorization (BOLA) occurs when an API allows users to access or manipulate objects (such as data records or user accounts) that they should not be authorized to access. In this case, the "object" refers to user accounts and their associated access tokens.

  1. Lack of Proper Authorization Checks:
    • In a secure system, each API request should validate whether the requester has proper authorization to access or interact with a particular object (in this case, another user’s access token).
    • Facebook’s API failed to ensure that users could only obtain access tokens for their own account. The attackers could obtain tokens for any other account, bypassing the normal object-level access control.
  2. Object Manipulation:
    • By manipulating the "View As" feature, the attackers effectively bypassed object-level authorization, accessing and controlling data (other users’ profiles) that they should not have been able to.
    • Instead of properly verifying the authorization for each object (the access tokens corresponding to individual accounts), the API allowed attackers to retrieve other users' tokens.

Why This is an Example of BOLA:

  • The breach occurred because Facebook's API did not properly enforce access controls at the object level. The system should have validated whether the user making the request was authorized to retrieve an access token for any given account.
  • BOLA exploits occur when APIs allow attackers to access objects (such as data or resources) that they shouldn’t have access to by manipulating requests, which is exactly what happened here with access tokens and user accounts.

Key Takeaways:

  • BOLA risks arise when there is insufficient validation of ownership or permissions for objects.
  • In the Facebook case, attackers could access objects (other users' tokens and accounts) that they should not have had access to, which is the defining characteristic of this OWASP vulnerability.

Mitigation:

To prevent similar BOLA attacks, developers should:

  • Enforce strict object-level authorization for every request, ensuring that users can only access or manipulate objects they own or are authorized to access.
  • Regularly audit API endpoints for potential BOLA vulnerabilities, especially where object IDs or sensitive tokens are exposed.
  • Implement least privilege principles and restrict access tokens and session data tightly to authorized users.

This real-world case perfectly maps to OWASP API1:2023, underscoring the importance of object-level authorization checks in API security.


API2:2023 Broken Authentication: Twitter 2020

Twitter's 2020 breach, in which attackers abused privileged API access to impersonate users, is a prime example of OWASP API2:2023 Broken Authentication. This vulnerability arises when an API's authentication mechanisms are weak, allowing unauthorized users to impersonate legitimate users or gain unauthorized access to privileged resources.

What Happened in the Twitter 2020 Breach:

  • In July 2020, attackers successfully executed a social engineering attack on Twitter employees, gaining access to internal administrative tools that had privileged API access.
  • With this access, the attackers bypassed normal authentication controls and reset passwords of high-profile accounts, including those of celebrities, politicians, and corporate entities.
  • The attackers then used these accounts to post messages as the legitimate users, promoting a cryptocurrency scam.

How This Relates to Broken Authentication:

Broken Authentication occurs when an API or system fails to properly enforce the verification of a user's identity or allows unauthorized users to authenticate as others. In Twitter’s case, the attackers exploited both the weakness in privileged access control and a lack of strong authentication mechanisms to impersonate users.

Key Elements of the Breach Related to API2:2023 Broken Authentication:

  1. Privileged API Access Not Properly Secured:
    • Twitter's internal tools had APIs with privileged access to user accounts, including the ability to reset passwords and manage account settings.
    • The API should have had stricter controls to verify that any actions affecting high-profile or sensitive accounts were being performed by properly authenticated, authorized users.
    • Attackers abused this API without facing sufficient multi-factor authentication (MFA) or other security checks to ensure they were legitimate users.
  2. Insufficient Authentication Mechanisms:
    • Once the attackers gained access to Twitter’s internal system, they were able to use the privileged API to bypass the typical authentication flow and post tweets from other users' accounts.
    • The API did not implement adequate controls to prevent the abuse of privileged accounts (e.g., using stricter authentication measures for accounts performing sensitive actions like password resets).
  3. Weak Employee Authentication:
  • The attackers gained access via social engineering, tricking Twitter employees into granting them credentials to internal tools. This highlights the vulnerability in the authentication process for privileged employees.
  • Once the attackers had these credentials, they could directly access APIs used by Twitter employees, with minimal authentication checks preventing them from escalating their actions.
  1. Privilege Misuse:
    • Twitter's administrative API allowed a level of privileged actions (e.g., resetting user passwords) that should have been limited by additional verification steps.
    • There was no robust auditing or secondary authentication mechanism in place to restrict the use of administrative tools to prevent misuse or impersonation.

Why This is an Example of Broken Authentication:

Broken Authentication occurs when an API fails to securely identify and authenticate users or control the level of access they have based on their authentication status. The Twitter breach is a classic example of this vulnerability for several reasons:

  • Privileged API access was granted to attackers who were not properly authenticated to perform the sensitive actions they executed.
  • The authentication mechanisms were not strong enough to prevent impersonation of high-profile users, allowing attackers to post messages as if they were those users.
  • Lack of MFA or strict verification when accessing high-risk APIs (such as those dealing with account management and password resets) facilitated the attack.

Mitigation Steps to Address API2:2023 Broken Authentication:

To prevent similar incidents, organizations should implement stronger authentication controls:

  1. Enforce Multi-Factor Authentication (MFA): Use MFA for any administrative or privileged API access to ensure that even if credentials are compromised, unauthorized users cannot access the API.
  2. Limit API Privileges: Apply the principle of least privilege to API access, limiting administrative API actions to only those who need them, and closely monitoring their usage.
  3. Session Management and Timeouts: Implement strong session management to limit the duration of privileged access and ensure that sessions are logged out after inactivity.
  4. Audit and Monitoring: Continuously audit API requests, especially from privileged accounts, to detect unusual or unauthorized actions.
  5. Employee Security Training: Provide thorough security awareness training to employees, especially those with access to sensitive systems, to reduce the risk of social engineering attacks.

In summary, Twitter's 2020 breach is a clear example of API2:2023 Broken Authentication because attackers bypassed authentication controls and impersonated users via privileged API access, a scenario that could have been prevented with stronger authentication and access control mechanisms.


API3:2023 (BOPLA): LinkedIn 2021

LinkedIn's 2021 data scraping incident, where attackers exploited LinkedIn’s API to access sensitive user data, is a prime example of OWASP API3:2023 Broken Object Property Level Authorization (BOPLA). This vulnerability occurs when APIs fail to properly enforce authorization at the property level, allowing unauthorized users to access or manipulate certain properties of an object (e.g., fields of a user profile) that should be restricted.

What Happened in the LinkedIn 2021 Incident:

  • Attackers used automated bots to scrape data from 700 million LinkedIn profiles through LinkedIn’s public APIs.
  • Although some of the data (such as names and job titles) was meant to be publicly accessible, the API also allowed attackers to extract sensitive properties, such as email addresses, phone numbers, and other private details, which should not have been exposed without proper authorization.
  • The attackers could retrieve this data because the LinkedIn API did not properly enforce property-level authorization, exposing both public and private data through the same API.

How This Relates to OWASP API3:2023 Broken Object Property Level Authorization:

Broken Object Property Level Authorization (BOPLA) occurs when an API allows unauthorized access to sensitive properties of an object (e.g., user profiles) that are not meant to be exposed or manipulated by certain users. This vulnerability is more granular than Broken Object Level Authorization (BOLA) because it applies to specific fields or properties within an object, not just the object itself.

Key Elements of the LinkedIn Incident Related to API3:2023 BOPLA:

  1. Inadequate Property-Level Access Controls:
    • LinkedIn’s API exposed a range of data fields (properties) in user profiles, including both public and private details.
    • While public properties (e.g., name, job title) were meant to be accessible, sensitive properties (e.g., email, phone number) should have been restricted.
    • However, the API did not properly enforce property-level authorization checks. Attackers could access sensitive properties of user profiles even if they were not authorized to do so.
  2. Exposure of Sensitive Fields:
    • The API returned data that contained private details about users, including fields that users might have configured to be private or only visible to certain contacts.
    • This is an example of excessive data exposure, where the API returns more data than what should be authorized for the requesting party.
  3. Failure to Differentiate Between Public and Private Data:
  • The LinkedIn API did not differentiate between the sensitivity of properties, treating public and private fields in user profiles similarly in its API responses.
  • Even if users had set specific properties (like email or phone numbers) to be private or visible only to connections, the API still exposed this data to unauthorized parties, including attackers who were scraping the data.
  1. Lack of Granular Access Control:
    • Proper property-level authorization would have restricted access to sensitive fields based on the requester’s authorization (e.g., whether the requester was a connection or had sufficient privileges to access private data).
    • However, LinkedIn’s API failed to apply such granular checks, allowing attackers to extract information from properties they had no legitimate access to.

Why This is an Example of Broken Object Property Level Authorization:

API3:2023 BOPLA refers to situations where access control is inadequate at the field or property level within an object. In this case:

  • The object is the LinkedIn user profile, and each field in that profile (such as name, email, job title) represents a different property.
  • LinkedIn’s API should have ensured that only authorized users (such as connections or verified accounts) could access certain properties (like email addresses or phone numbers).
  • The failure to do so allowed attackers to scrape sensitive properties across millions of accounts, violating users' privacy and exposing private data to unauthorized parties.

Mitigation Steps to Address API3:2023 Broken Object Property Level Authorization:

To prevent similar issues, APIs need to implement stronger property-level authorization mechanisms:

  1. Granular Property-Level Authorization:
    • Ensure that each property of an object (e.g., user profile) is protected by proper authorization checks based on the user’s relationship to the object.
    • For example, an API should enforce that only connections or authorized users can see sensitive fields like email addresses or phone numbers.
  2. Least Privilege Access:
    • APIs should adopt the principle of least privilege, returning only the minimum data necessary for the requesting user’s role and permissions.
    • Sensitive fields should be omitted from responses unless the requester is explicitly authorized to view them.
  3. Data Filtering and Masking:
  • Implement data filtering and masking techniques to ensure sensitive properties are not included in API responses unless strictly necessary.
  • For example, private data like phone numbers should be masked or excluded entirely unless the requester has been properly authenticated and authorized.
  1. Strong API Access Controls:
    • Apply strong role-based access control (RBAC) or attribute-based access control (ABAC) to API endpoints to restrict access to sensitive fields.
    • Regularly audit API endpoints to ensure that sensitive data fields are not exposed unnecessarily.

Conclusion:

The LinkedIn 2021 data scraping incident is a clear example of OWASP API3:2023 Broken Object Property Level Authorization because the API failed to enforce proper property-level authorization checks. As a result, attackers were able to access and scrape sensitive properties of user profiles (like private emails and phone numbers), which should have been protected and accessible only to authorized users or connections. Implementing stronger authorization mechanisms for each property within an object is critical to preventing similar vulnerabilities in API design.


API4:2023 Unrestricted Resource Consumption: GitHub 2020

GitHub’s 2020 Distributed Denial of Service (DDoS) attack via API abuse is a classic example of OWASP API4:2023 Unrestricted Resource Consumption. This type of vulnerability occurs when an API allows excessive consumption of resources (such as CPU, memory, bandwidth, or database queries) without proper limitations, leading to performance degradation or service outages.

What Happened in the GitHub 2020 DDoS Attack:

  • In June 2020, GitHub experienced a massive DDoS attack where attackers leveraged the GitHub API to send an overwhelming number of requests.
  • The attackers took advantage of GitHub’s API by automating requests at an extremely high rate, consuming significant server resources (such as CPU and memory) and causing service disruptions.
  • The attack targeted GitHub’s infrastructure by sending a large volume of requests through open APIs, which lacked adequate resource consumption controls to limit the impact.

How This Relates to OWASP API4:2023 Unrestricted Resource Consumption:

OWASP API4:2023 Unrestricted Resource Consumption refers to API vulnerabilities that allow users or attackers to overwhelm a system’s resources through excessive API calls or requests, leading to performance issues or outages. The key issue here is that the API did not enforce limits on resource usage, allowing attackers to overload the system.

Key Elements of the GitHub DDoS Incident Related to API4:2023:

  1. No Rate Limiting on API Requests:
    • GitHub’s API allowed users to send a large volume of requests without sufficient rate limiting or controls in place.
    • The attackers were able to send thousands or even millions of requests per minute, consuming large amounts of system resources such as processing power, bandwidth, and database capacity.
    • Rate limiting should have been in place to cap the number of API requests per user or IP address, preventing attackers from overwhelming the system.
  2. Excessive Resource Consumption:
    • The GitHub API allowed attackers to consume excessive resources (CPU, memory, bandwidth) by sending an unbounded number of requests.
    • This led to resource exhaustion on the servers, causing service slowdowns and outages for legitimate users.
    • The attack is an example of resource exhaustion, a common outcome of unrestricted resource consumption vulnerabilities.
  3. API Vulnerable to Automation Abuse:
  • The GitHub API did not have sufficient protections against bot-based or automated abuse, where attackers could easily script automated requests to flood the system.
  • The lack of automation abuse prevention (e.g., CAPTCHA or requiring API keys for certain high-resource operations) made it easier for attackers to execute a large-scale DDoS attack using the API.
  1. No Throttling or Quotas:
    • GitHub’s API should have implemented throttling mechanisms to slow down excessive request rates or introduce quotas to limit the total number of requests a user could make within a specific timeframe.
    • Without these restrictions, attackers were able to consume resources indefinitely, leading to denial of service for legitimate users.

Why This is an Example of Unrestricted Resource Consumption:

Unrestricted Resource Consumption happens when an API allows users to consume resources (such as bandwidth, CPU, or memory) without setting limits or controls, leaving the system vulnerable to resource exhaustion. In the case of GitHub:

  • Attackers were able to flood the API with an unmanageable number of requests, consuming all available resources.
  • The lack of rate limits, throttling, or quotas allowed the attackers to continue abusing the API until the system became overwhelmed.
  • As a result, legitimate users experienced slow performance or complete service outages, typical symptoms of resource exhaustion attacks.

Mitigation Steps to Address API4:2023 Unrestricted Resource Consumption:

  1. Implement Rate Limiting:
    • APIs should have strict rate limits in place to cap the number of requests a single user or IP address can make in a specific timeframe. For example, GitHub could have limited each user to a maximum number of requests per minute.
    • Rate limits prevent attackers from overwhelming the system by sending an excessive volume of requests.
  2. Use Throttling and Quotas:
    • Throttling helps to slow down requests when a user approaches the rate limit, allowing the system to manage traffic more effectively.
    • Quotas limit the total number of API requests that a user can make within a given period (e.g., daily or monthly quotas), ensuring that resources are distributed evenly across all users.
  3. Enforce Authentication and API Keys:
  • APIs should require authentication and the use of API keys for access. This makes it easier to track usage per user and enforce rate limits or quotas based on each user's account.
  • Additionally, API keys can be revoked or limited if abusive behavior is detected.
  1. Implement Abuse Detection Mechanisms:
    • Detect patterns of abnormal API usage, such as high-frequency requests or sudden traffic spikes, which may indicate an ongoing attack.
    • Implement CAPTCHAs, bot detection, or progressive backoff mechanisms to detect and prevent automated abuse.
  2. Leverage CDN and Caching:
    • Offload traffic to content delivery networks (CDNs) and caching layers to reduce the direct load on API servers. This helps mitigate the impact of resource consumption attacks by distributing traffic across multiple servers.

Conclusion:

GitHub’s 2020 DDoS attack via API abuse exemplifies OWASP API4:2023 Unrestricted Resource Consumption because the API allowed attackers to send an unlimited number of requests without proper rate limiting, throttling, or quotas. This led to excessive resource consumption and service outages, highlighting the need for robust resource control mechanisms in API design to prevent such vulnerabilities.


Multiple Vulnerabilities: Optus 2022

The Optus API security breach that occurred in September 2022 exposed the personal data of millions of customers due to multiple API vulnerabilities. The breach serves as a real-world example of how several vulnerabilities from the OWASP API Security Top 10 for 2023 can be exploited. The breach exposed sensitive customer data such as names, addresses, email addresses, phone numbers, and even ID documents like driver's licenses and passports.

Here’s an analysis of which of the OWASP API Security Top 10 for 2023 vulnerabilities were violated during the Optus breach:

1. API1:2023 Broken Object Level Authorization (BOLA)

Violation in Optus breach:

  • Broken Object Level Authorization (BOLA) occurs when attackers are able to access sensitive data for other users due to insufficient authorization checks on object-level access.
  • In the Optus breach, the API endpoints allowed unauthorized access to customer data by improperly handling user authentication and authorization. Attackers could query the API for objects (e.g., customer records) they were not authorized to access, which is a clear example of BOLA.

How it was violated:

  • Attackers used a single API endpoint to access different customer records without any validation of whether they were authorized to retrieve that information.
  • The API did not enforce access control at the individual object level, which led to unauthorized exposure of personal customer data.

2. API3:2023 Broken Object Property Level Authorization (BOPLA)

Violation in Optus breach:

  • Broken Object Property Level Authorization happens when unauthorized users can access specific object properties (e.g., sensitive fields) that should have been restricted.
  • In the Optus breach, attackers were able to access sensitive properties of customer records, such as personal identification numbers, email addresses, and passport numbers, without proper authorization.

How it was violated:

  • The API did not apply property-level authorization checks to ensure that only authorized users could access specific fields within the customer profile. This allowed attackers to view and extract highly sensitive personal information beyond the standard user profile details.

3. API4:2023 Unrestricted Resource Consumption

Violation in Optus breach:

  • Unrestricted Resource Consumption occurs when an API fails to limit the amount of resources or data a client can consume, leading to potential denial of service or mass data leaks.
  • The Optus API allowed attackers to enumerate customer records without rate-limiting or restriction on the number of requests.

How it was violated:

  • Attackers were able to automate requests and retrieve large volumes of data in a short period of time without encountering any restrictions, such as rate limiting or request quotas.
  • The lack of such controls contributed to the scale of the breach, as attackers could easily exfiltrate data from millions of customers.

4. API6:2023 Unrestricted Access to Sensitive Business Flows

Violation in Optus breach:

  • Unrestricted Access to Sensitive Business Flows occurs when APIs expose sensitive business processes or flows without enforcing proper restrictions.
  • Optus' API exposed highly sensitive customer data (e.g., ID numbers, passport details) to the public-facing API without securing these flows.

How it was violated:

  • Sensitive business functions, like retrieving or updating personal data, were left exposed and accessible to the public API without adequate authentication or authorization. This unrestricted access allowed attackers to exploit the API to extract sensitive data at scale.

5. API8:2023 Security Misconfiguration

Violation in Optus breach:

  • Security Misconfiguration refers to improper configuration of API security settings, leading to vulnerabilities such as exposed endpoints or insufficient authentication controls.
  • The Optus breach occurred, in part, due to improper security configurations of the API, such as leaving an exposed and unauthenticated endpoint that allowed attackers to access sensitive customer data.

How it was violated:

  • One of the major failures in this breach was the lack of authentication on certain API endpoints, leaving customer data exposed to anyone who knew how to access the API.
  • There was also likely a lack of proper security headers or security best practices (e.g., insufficient logging, encryption issues) that would have prevented the exposure of data.

6. API9:2023 Improper Inventory Management

Violation in Optus breach:

  • Improper Inventory Management refers to the failure to properly track and manage APIs, leading to outdated, unsecured, or undocumented APIs being exposed to attackers.
  • Optus may have been using a legacy or improperly secured API that was not properly inventoried or monitored, allowing attackers to exploit it without detection.

How it was violated:

  • Outdated or legacy APIs that were not decommissioned or properly secured may have been exposed to attackers. The API that was exploited may not have been properly inventoried or subjected to the same rigorous security protocols as other, more current APIs.

Conclusion:

The Optus API security breach violated several key elements of the OWASP API Security Top 10 for 2023, including Broken Object Level Authorization (BOLA), Broken Object Property Level Authorization (BOPLA), Unrestricted Resource Consumption, Security Misconfiguration, and Improper Inventory Management. These vulnerabilities allowed attackers to gain unauthorized access to sensitive customer data, causing a large-scale data breach. Strengthening API security, especially around authorization, rate limiting, and inventory management, would have significantly reduced the risk of such an attack.

Understanding the OWASP 10 for API Security
Why API security is special