Stay up to date
Stay up to date with the latest threat reports, articles & mistakes to avoid.
Simple, yet important content.
No salesy pitches and all that, promise!
What is OWASP Security API Top 10?
The OWASP stands for The Open Web Application Security Project. It is a non-profit foundation that improves application security by listing guidance such as top OWASP API security vulnerabilities and prevention. OWASP API security top 10 is an API security project that focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs). Through community-led projects globally, it is a great source for tools, resources, education & training for developers and technologists to secure the web and mobile applications. This community has also produced some of the best testing guides, OWASP Top 10 cheat sheet for apps, mobile and APIs, methodologies and a lot of community work for which all of us are grateful.
In this app-driven world, APIs are used for communication by microservices and containers, pretty much what traditional applications were to the internet during the early days. Microservices security architecture has API security as one of the biggest components. This API pentesting checklist would help developers adopt security best practices in their development, whether an API gateway made for scale or a simple API.
Feel free to watch this video containing a condensed version of the article.
OWASP API (Application Programming Interface) security is a project to help organisations deploy secure APIs. APIs are fundamental components of today’s app-driven internet life. APIs are a critical part of modern SaaS, mobile and cloud technologies infrastructure, whether banks, online retailers, transportation or consumer services. APIs are the most common ways today defining how microservices and containers communicate like systems, applications and other entities.
If new software (mobile computing, cloud computing) affects the world, API security affects this software.
Let’s look at the Top 10 OWASP API security vulnerabilities:
- Broken Object Level Authorization
- Broken User Authentication
- Excessive data exposure
- Lack of resources and rate-limiting
- Broken Function Level Authorization
- Mass assignment
- Security misconfiguration
- Improper assets management
- Insufficient logging and monitoring
This article presents each of these API vulnerabilities with API attack examples and measures to prevent these attacks. This can also be used as an API security checklist or OWAPI security top 10 cheat sheet within application teams to help produce secure code. OWASP testing guide provides a comprehensive testing framework (stable v 4.2 currently) about considering various aspects of secure development during SDLC.
Web applications and API penetration testing services often include OWASP top 10 as part of the testing methodology.
Broken object-level authorization
This attack, also known as Insecure Direct Object Reference (IDOR) vulnerability, is amongst the topmost API security risks. Improper access controls for assets accessible from the internet make it an easy target for threat actors. This is largely due to the lack of strict authorisation controls implementation or no authorisation controls. This issue impacts in varied ways, from data disclosure to full account takeover.
Use case for broken object-level authorization
For example, an API call with parameters using value (ID) associated with the resource i.e.
A threat actor attempts different usernames guessing through correct accounts
and so on. If the API does not check current user permissions and allows the current call, the current user shall access Lisa and Peter user profiles. Based on the user permissions, the resulting access would relate to horizontal or vertical privilege escalation vulnerability.
Another example is sending POST requests to update data on the backend. In this case, the following JSON payload is sent to update user account details:
"user": "[email protected]",
If we can change the userID to another userID and update other user details, this is another example of a broken object-level authorization vulnerability.
How to prevent broken object-level authorization?
The following mitigations should act as a defensive measure against broken object-level authorization vulnerability.
- A stricter access control policy coupled with random and unpredictable user ID values is hard to guess.
- Check authorization for each client request access to the backend.
Broken user authentication
Insecure or missing protection mechanisms for API endpoints causes broken user authentication flaws. The authentication endpoint being exposed makes it an attractive target for cybercriminals due to how authentication mechanisms work. Threat actors can exploit this vulnerability to steal sensitive data, take over accounts, or impersonate users.
How to prevent broken user authentication?
Implement stricter protection, including but not limited to factors such as strong credential encryption, failed login attempts limit, authentication token validation. OAuth has been the de facto standard for securing APIs for both authentication and authorization mechanisms. For Java, using encrypted JWT tokens ensures identity and user characteristics are not easily susceptible to attacks.
Excessive data exposure
APIs disclose varied types of data based on who is requesting. The purpose of what information will be served and to whom this will be served are the core concepts while designing an API. Insecure implementation or lack of implementation of data filtering leads to disclosing more than required information. Data exposure issues are a common sight, ranging from technology or version information disclosure to high-risk issues related to user preferences or account information.
How to prevent API excessive data exposures?
Threat model the information based on how data flows from the endpoints to the client and vice versa and review the data filtering. Never process user input on the server-side without any validation.
Lack of resources and rate-limiting
Threat actors can easily abuse an API leading it to consume available resources and making the service unavailable to legitimate users. This could lead to Denial of Service (DoS) attacks.
Public APIs are often the target as the common misconception that no authentication removes risks to the application applies commonly. This issue could be exploited using multiple attack vectors such as brute force attacks, credential stuffing attacks, user enumeration, or other fuzzing techniques. Bots and other automated techniques could end up using the victim’s precious computing resources.
How to prevent it?
Implement size and resources rate-limiting, such as several items required in a single API request or a maximum number of records that can be retrieved.
Broken function-level authorization
Deploying unique strategies for different services yields complexity that leads to vulnerabilities or increased attack surface. Every API function call should require authorization to verify that the user requesting the data is authorized to send the request on those objects. Threat actors use this flaw to find administrative functions hidden otherwise and allow access to higher privilege functions.
How to prevent it?
Could you keep it simple? Deploy a standard approach to authorize client requests and avoid function-level authorization. Deny all access by default, and allow explicitly.
Mass assignment issue occurs where the lack of properties filtering allows exposure of internal variables or objects. Due to a lack of restrictions, an endpoint may provide access to other properties outside the authorized scope allowing a threat actor to modify objects related to those parameters. This also illustrates the API security risk of how unauthorised users can exploit direct mapping client inputs to internal variables.
How to prevent it?
Define properties that a client can access and avoid direct mapping of client inputs to internal variables or object names.
Discuss your concerns today
Security misconfiguration vulnerabilities arise due to the use of insecure configuration or misconfiguration in the web application components. This could be either application framework, web server hosting the application or third party libraries in use.
Exploiting configuration weakness in an application leads to security misconfiguration attacks.
What causes security misconfiguration attacks?
Enterprise web applications are built by multiple parties (database admins, system developers, middleware teams), internally or within companies (outsourced vendors, hosting providers, etc.). Security issues often arise due to a lack of security-oriented cohesion between these teams. These all fall into a misconfiguration checklist, whether it is down to insecure coding practices, lack of secure hardening of databases, or other issues. Security misconfiguration impact has far-reaching consequences, including but not limited to high-risk vulnerabilities such as data leakage (AWS S3 or Azure blob leakages), default accounts leading to compromises up to database compromise.
Some of the examples of security misconfiguration vulnerabilities are:
- Lack of patch deployment
- Insecure encryption (TLS) configuration
- Default accounts or passwords
- Insecure coding practices
- Default configurations allowing access to unwanted/unused features
- Unnecessary HTTP methods
- Missing security headers
- Verbose error messages
How to prevent security misconfiguration?
Perform regular penetration testing of your web application and API. Perform regular secure hardening reviews against the hosting server. These measures would act as inherent API attack prevention measures built into internal SDLC (software development life cycle).
Like web application injection attacks, all injections, i.e., OS Command injection, SQL, NoSQL, and LDAP injections, fall under one of the notable API security risks. Due to the lack of strict input validation on the server-side, malicious input can make way as a query or command to enumerate backend information.
How to prevent Injection attacks?
The core concept behind injection flaws is the lack of input validation and sanitisation of the application’s data. Any input request that contains parameters as input can be vulnerable to a code injection flaw. This could be an OS code injection, SQL injection or simple script injection based on the underlying code of vulnerable function in use.
API attack prevention measures against SQL injection attacks are effective by separating data from commands and queries. The use of prepared statements (with parameterised queries) is how developers should write database queries. This allows defining all the SQL code and then passing each parameter to the query, distinguishing between code and data irrespective of user input (malicious or legit).
Improper assets management
Like other business assets, APIs go through a lifecycle, and the lack of asset management is related to legacy security vulnerabilities. By not retiring older versions, APIs expose more endpoints, exposing endpoints that are no more needed, not known or forgotten by the teams. This increases the attack surface due to older and newer API versions running alongside.
How to prevent it?
Documentation is an important step towards maintaining assets information. There should be clear segregation at the user, network and functional level between production and non-production environments. Review and retire older versions that are no more required.
Insufficient logging and monitoring
Logging and monitoring of data is a vital step for audit trials and incident response teams. Due to the lack of logging and monitoring controls, a threat actor finding it difficult to attack the victim API has more time by his side, leading to a bigger and high impact attack. This can be easily avoided by logging and analysing the suspicious events early in the attack chain due to stricter monitoring processes. Unfortunately, this is one of the reasons data breaches go unnoticed early in the attack stage.
How to prevent it?
Review and ensure all necessary log levels are in place for all API endpoints. Deploy a monitoring solution to monitor logs for APIs and infrastructure continuously. Ensure that the incident response process is defined and shared with teams to be prepared for any eventuality.
As can be seen above, while a few issues are common to the OWASP Top 10 application security risks, APIs are an opportunity for threat actors leading to sensitive data. This API pentesting cheat sheet is a popular resource for development teams. API security testing is one of our offerings under web application penetration testing services. Our team of skilled security experts with proven industry experience ensure comprehensive coverage for web application risks, especially issues such as business logic flaws, business contexts that automated scanners or less experienced consultants often miss. Get in touch if we can help with your security concerns.