OWASP Top 10 API Security
OWASP Top 10 API Security
Take a look at the top 10 OWASP security risks, learn what each of them means, and how you can mitigate them.
Join the DZone community and get the full member experience.Join For Free
I am sure that almost all of you would be aware about OWASP. But, just for the context let me just brief about the same.
OWASP is an international non-profit organization that is dedicated to web application security. It is a completely opensource and community driven effort to share articles, methodologies, documentation, tools, and technologies in the field of web application security.
When we talk about API, we are almost every time talking about REST and OWASP has a dedicated project to API security. As this series of articles are focused towards the API security, we shall not be going in details of web application security. You can use the provided links to find more about these. Let us spend some time on the background, before we dive deep in to API security project.
OWASP's most widely acknowledged project is OWASP top 10. This is the list of security risks compiled by the security experts from across the world. This report is continuously updated, outlining the concerns of web application security, and specially focuses on the Top 10 of the most critical risks. According to OWASP, this report is an "The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications." They recommend that all companies incorporate the report into their processes in order to minimize and/or mitigate security risks. The latest version was published in 2017 and below is the list.
- Broken Authentication
- Sensitive Data Exposure
- XML Eternal Entities (or XXE)
- Broken Access Control
- Security Misconfiguration
- Cross-Site Scripting (or XSS)
- Insecure Deserialization
- Using Components With known vulenerabilities
- Insufficient Logging And Monitoring
How API Security Is Different from Web Application Security
Although API's have many similarities with web applications, but both are fundamentally different in nature.
In web applications, all the processing is done on the servers and the resulting web page is sent back to web-browser for rendering. Because of this nature, they have limited entry point and attack surface which are resulting web pages. This can easily be protected by putting up and web-application firewall (WAF) in front of the application server.
In most of the modern application UI itself uses API's to send and receive data from backend servers and provide the functionality of the application. It is the responsibility of the clients to do the rendering and convert the responses to a web page.
Also, with the rise of microservices architecture individual components become APIs, and it becomes a different world altogether, where UI clients could interact with hundreds of services via API calls. This significantly increases the attack surface. Now all those API's become the entry point and attack surface.
These entry points can't be guarded using the WAF solutions as they cannot differentiate between the legitimate and malicious API calls.
Why A Separate Project on API security?
Since its first release in 2003 OWASP top 10 projects has been the most useful resource in terms of web application security risks and to suggest the ways to mitigate these issues.
These days almost all the application development like banking, retail, transportation, smart devices, are done with the APIs.
APIs are critical to modern mobile and SaaS application. By nature, the API's expose business logic and data, often these data are sensitive in nature, for example Personally Identifiable Information (PII). Because of this API's are increasingly being targeted by attackers.
As API's are changing how we design and develop our application, this is also changing the way we think about our security. A new approach in needed in terms of security risks. To cater to this need, OWASP decided to come up with another version of Top 10 dedicated to API security which is named "OWASP API Security Project". The first report was released on 26 December 2019.
Below is the OWASP Top 10 API security risks and their brief description as provided by the official report.
API1:2019 Broken Object Level Authorization
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
API2:2019 Broken User Authentication
Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising system’s ability to identify the client/user, compromises API security overall.
API3:2019 Excessive Data Exposure
Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
API4:2019 Lack of Resources & Rate Limiting
Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
API5:2019 Broken Function Level Authorization
Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
API6:2019 Mass Assignment
Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
API7:2019 Security Misconfiguration
Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
API9:2019 Improper Assets Management
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
API10:2019 Insufficient Logging & Monitoring
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
Opinions expressed by DZone contributors are their own.