Since 2003, the non-profit Open Web Application Security Project (OWASP) has maintained its Top 10 list of the most severe and pervasive web-application security risks — otherwise known as the OWASP Top 10. Web developers and security practitioners use the OWASP Top 10 as a reference to avoid common and dangerous mistakes when building and maintaining web applications.
From that main Top 10 list, OWASP has since spun off nearly a dozen "daughter" lists of Top 10 risks for other aspects of information security, such as desktop-application security, privacy, machine-learning security and mobile-device security.
One of the most important daughter lists is the OWASP API Security Top 10 list, which first appeared in 2019 and was given a full refresh in early June 2023. This list concerns itself with application-programming interfaces (APIs), the bits of software that let two or more separate computer programs communicate and exchange information with each other.
APIs are crucial to the development of software functions, and APIs for web applications, which communicate across the internet rather than through a closed network, are frequently sources of security vulnerabilities.
"APIs are a critical part of modern mobile, SaaS, and web applications and can be found in customer-facing, partner-facing, and internal applications," states the foreword to the 2023 OWASP API Security Top 10 list. "By nature, APIs expose application logic and sensitive data such as personally identifiable information (PII) and because of this, APIs have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible."
The OWASP API Security Top 10 list doesn't list specific vulnerabilities but rather categories of common weaknesses in APIs, especially web-based APIs, that often result in vulnerabilities. Like the main OWASP Top 10 list, developers and DevSecOps personnel use the OWASP API Security Top 10 list to guide their work and steer away from pitfalls.
What's on the OWASP API Security Top 10 list
The final version of the OWASP API Security Top 10 list, released June 7, 2023, is as follows. We'll briefly go through each item.
1. Broken Object Level Authorization
OWASP says that "APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues."
It gives the example of an automaker using vehicle identification numbers (VINs) to control cars via a mobile app without verifying vehicles' authorized users. Because of that mistake, an attacker could use a VIN — visible through every vehicle's windshield — to unlock and start someone else's car.
2. Broken Authentication
"This category encompasses all sorts of weaknesses that could allow an attacker to act as a valid user," explains Invicti's Zbigniew Banach in a recent blog post, "whether by permitting credential stuffing for brute-force access, failing to verify token signatures, or simply allowing unauthenticated access in some circumstances."
3. Broken Object Property Level Authorization
"This is closely related to object-level authorization failures but applies at a more granular level, where defining and enforcing access control is much harder," writes Banach. "Even with proper access control to, say, customer data records, you still need to define who can perform which operations on which data fields, and whether they can import, export, or modify data in bulk."
4. Unrestricted Resource Consumption
This one involves failing to guard against running out of bandwidth, memory, processing power or other basic resources so that systems aren't overwhelmed by too many requests. This most commonly leads to a denial of service for authorized users, but OWASP's examples show how a malicious third-party vendor could abuse such a weakness to rack up fraudulent charges.
5. Broken Function Level Authorization
"This category covers weaknesses that expose application functionality rather than data," writes Banach. "For example, if an attacker can access the export operation for customer records, they could extract sensitive information in bulk even if they cannot access each customer record object separately."
6. Unrestricted Access to Sensitive Business Flows
This weakness comes from a failure to detect and limit rapid-fire automated requests that might not create a security issue but could nonetheless harm the business. For example, bots exploit this to quickly buy up popular concert tickets, limited-edition sneakers or scarce gaming consoles, earning a profit for resellers while creating bad publicity for the retailers.
7. Server-Side Request Forgery
"In the context of APIs," writes Banach, "server-side request forgery vulnerabilities allow attackers to smuggle URLs through an API and trick a back-end server into sending a request to that URL."
OWASP gives an example of an attacker inputting a specially crafted URL to a social-media network's image-upload function, resulting in a port scan (often part of pre-attack reconnaissance) from inside the social-media company's internal network.
8. Security Misconfiguration
One of the most severe weaknesses on the list, this type of flaw lets attackers probe for "unpatched flaws, common endpoints, services running with insecure default configurations, or unprotected files and directories" to break into systems, steal data or completely hijack servers, OWASP writes.
9. Improper Inventory Management
"As interfaces and their underlying applications both undergo changes," writes Banach, "any gaps in version control and documentation can expose additional attack surfaces in the form of deprecated APIs that are still accessible or undocumented API endpoints that go unnoticed during testing."
10. Unsafe Consumption of APIs
"In this case, 'unsafe consumption' refers to using data retrieved from an API without sanitizing and validating it to the same standard as user-supplied data," explains Invicti's Banach.
Banach adds that injection attacks fall into this category, and OWASP indeed supplies an example of a malicious third-party vendor using SQL injection to steal data from a company through a vulnerable API.
How to use the OWASP API Security Top 10 list
With every entry on the list, OWASP provides several suggestions for how to prevent that particular sort of weakness, as well as links to further references on the OWASP website and externally.
For example, with item No. 3, Broken Object Property Level Authorization, the suggestions are:
— When exposing an object using an API endpoint, always make sure that the user should have access to the object's properties you expose.
— Avoid using generic methods such asto_json()andto_string(). Instead, cherry-pick specific object properties you specifically want to return.
— If possible, avoid using functions that automatically bind a client's input into code variables, internal objects, or object properties ("Mass Assignment").
— Allow changes only to the object's properties that should be updated by the client.
— Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism, define and enforce data returned by all API methods.
— Keep returned data structures to the bare minimum, according to the business/functional requirements for the endpoint.
Among all 10 entries, there are dozens of such suggestions. There are also two pages detailing and linking to further OWASP resources specifically for developers and DevSecOps personnel.
"Building secure APIs is crucial," states the latter page. "Security cannot be neglected, and it should be part of the whole development life cycle. Scanning and penetration testing yearly are no longer enough."
