Published on
This post was written by Chris Romeo during his tenure at Security Journey.
Marc Andreessen famously stated in 2011 that “software is eating the world.” Now, in 2019, application programming interfaces (APIs) serve as the backbone of modern software, and they keep on devouring everything in their path, from microservices to single-page applications and mobile apps to the Internet of Things. APIs drive everything in the web world.
But if software is eating the world, then security—or the lack thereof—is eating the software. Hence, the need for OWASP’s API Security Top 10.
Erez Yalon, one of the project leaders for the OWASP API Security Top 10 and director of security research at Checkmarx, has this to say about the state and prevalence of APIs:
“APIs build today’s software-driven world. … APIs enable developers to write data-driven and flexible applications that all end users and organizations desire.”
But APIs are also creating a rapidly growing attack surface that isn’t widely understood and is often entirely overlooked by developers and architects. A recent report suggests that by 2022, API abuses will be responsible for most data breaches within enterprise web applications. Additional research found that while 70% of enterprises cite APIs as crucial to digital transformation, securing them is a top challenge.
APIs are attractive to attackers because they remove the complexity of the many different front-end frameworks. In other words, APIs provide a standard interface on which to focus an attack.
Here is a rundown on the new OWASP Top 10, with developer actions included for each item.
Broken object-level authorization
This is not an issue unique to APIs, but is common in applications that are built in any language and perform authorization. APIs exacerbate this issue because the server component does not adequately track the client’s state.
This allows an attacker to modify an object’s ID value and access other objects. The result is that attackers can access data that they are not authorized to access.
Developer actions:
- Examine/threat-model your implementation of authorization policies and determine if an attacker can access items purely through knowing or guessing the object’s ID value.
- Marry random and unpredictable object ID values with a robust access control policy implementation.
[ Partner resource: Take Security Journey’s first two white belt modules for free ]
Broken authentication
Broken authentication is another legacy top 10 issue (found in the OWASP Top 10 for web applications). APIs suffer from the same authentication attacks, such as credential stuffing (where attackers try typical username/password combos in many locations) and brute force (where no restrictions by the API endpoint allow attackers to try all possible combinations for a username/password).
One of the most significant issues with authentication in APIs is a total lack of it, or selective authentication, where it’s not uniform across a collection of API endpoints.
Developer actions:
- Confirm a standard approach to authentication that is uniform across all of your API endpoints.
- Review the authentication requirements within the Application Security Verification Standard (ASVS) and apply these requirements to your authentication implementation.
- Ensure that you have a strong business requirement before you expose an unauthenticated API endpoint to the public Internet.
Excessive data exposure
APIs are in the business of disclosing data to clients; that’s why they exist. When you design an API, you determine who your clients are, and what information you will serve up for them.
Excessive data exposure happens when you don’t implement filtering correctly and end up sending more information than you should to a client.
Developer actions:
- Trace through/threat-model the information flows of data from the endpoint to the client and consider whether you have proper filtering in place.
- Perform all filtering on the server-side, not on the client. If you filter on the client, it can turn off the filter and receive all of the information.
Lack of resources and rate limiting
A finite set of resources serves APIs, and attackers can abuse an API by consuming all available resources, making the information service unavailable for legitimate users. Attackers consume resources both through the correct usage of an API—uploading many images, which generates multiple thumbnails and uses lots of CPU and memory—and by adjusting the API parameters to bypass filtering on the back end.
Developer actions:
- Analyze/threat model your design to determine whether you have proper rate-limiting controls in place.
- Consider the OWASP Automated Threat Handbook as a knowledge source for the many bots that are using your precious computing resources.
Broken function-level authorizations
These are a terrible idea, but they happen. With function level authorizations, you’re creating an individual micro-authorization policy that applies to a single function.
What could go wrong with creating a unique strategy for every possible service? Complexity breeds vulnerability, and having separate policies for functions increases complexity tenfold. Disaster can ensue.
Developer actions:
- Use a standard approach to authorization that is uniform and set to deny by default; avoid function-level authorization.
- Keep authorization simple; technology is already complicated enough. Securing something simple is hard; securing something complex is impossible.
Mass assignment
Mass assignment occurs when an API inadvertently exposes internal variables or objects. An attacker can craft an API request that provides values for an internal variable or object. If the endpoint does not correctly filter out those internal-only data structures, an external call may update an internal-only value.
Developer actions:
- Avoid exposing the internal variable or object names as input.
- Whitelist the properties that the client can update.
Security misconfiguration
A security misconfiguration is a setting that could have been adjusted to lock down an API but wasn’t. Security misconfigurations include neglecting security patches on the underlying application server or host systems, allowing all HTTP verbs, missing Transport Layer Security (TLS), missing security headers or Cross-Origin Resource Sharing (CORS) policy, and enabling excessive information flow in stack traces or error messages.
Developer actions:
- Perform a repeatable hardening process against your API, as you would with any other host or infrastructure system.
- Test your entire stack for security misconfigurations using scanning tools and human reviews.
Injection attacks
Classic injection attacks such as SQL, LDAP, XML, and command injection are the most prevalent application security risks for web applications.
Developer actions:
- Perform input validation via whitelisting for all input.
- Use a parameterized interface for all inbound API requests.
- Review the filtering logic to limit the number of records returned.
Improper asset management
Improper asset management stems from a lack of version control for API hierarchies. APIs go through a lifecycle just like any other software, and versions of the API reach the end-of-life state. Older versions of APIs suffer from vulnerabilities eradicated from newer releases.
Proper asset management calls for tracking where API versions live and retiring versions to limit legacy security vulnerabilities.
Developer actions:
- Inventory all APIs, including environments such as production, staging, test, and development. You can’t secure what you cannot find.
- Perform a security review of all APIs, focusing on the standardization of function.
- Stack rank your APIs by risk level and improve the security functions of the riskiest items on the list.
Insufficient logging and monitoring
Logging and monitoring of data are crucial for deducing what happens when things go wrong. Logging and monitoring always fall to the end of any security list, because it’s reactive even though everyone knows it’s essential.
Developer actions:
- Use a standard format for logging across all APIs; this makes life easier for incident response in the future.
- Monitor your API endpoints across all phases (production, stage, test, dev). React to security issues identified within your API.
How the API Security Top 10 Project started
Yalon and Inon Shkedy, a security consultant at Tangent Logic, created this project to educate those involved in API development and maintenance: developers, designers, architects, managers, and organizations.
Many different roles within an organization must understand how to secure APIs, and API security is more than just a code-level activity. It requires design and development working in tandem.
Here is their perspective:
“One of the biggest challenges when it comes to API security—or any security, for that matter—is awareness. The different ways of protecting APIs require an understanding of the actual threats facing modern applications, which is where we recognized a bit of a gap.
“We launched the OWASP API Security Top 10 list to inform developers and security professionals about the top issues that are impacting API-based applications. Where APIs exist in nearly every form, prioritizing their security is of utmost importance, and the API Security Top 10 list looks to drive awareness and attention when it comes to their implementation.”
Don’t let APIs eat your software’s security
APIs, just like software, are eating the world. The OWASP API Security Top 10 is a must-have, must-understand awareness document for any developers working with APIs.
While the issues identified are not new and in many ways are not unique, APIs are the window to your organization and, ultimately, your data. If you ignore the security of APIs, it’s only a matter of time before your data will be breached.
