OWASP API Security Top 10 (With examples & fixes)

OWASP API TOP 10 Banner 768x292 1

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. 

Why is OWASP API Penetration testing important?

Organisations have their in-house, external or hybrid development teams working round the clock delivering API development projects. This includes developers going through secure coding standards to ensure its delivered to the expected standard. Validation is then sought externally to assess the secure coding levels and maturity of the API utilising third party API security testing company. This is why identification of API security vulnerabilities and their remediation must be checked with API penetration testing provider. Get in touch to schedule a call if this is in your security roadmap. 

Hot off the press – OWASP API Top 10  2023 edition

OWASP have recently updated (July 2023) the old OWASP Top 10 API risks list from 2019.  Here are the new trends introduced in 2023 edition:

1. The Authorization Challenge in API Security

API security is facing a mammoth challenge – authorisation. This issue takes the center stage with three out of the top five concerns in the OWASP Top 10 API 2023 list. With modern applications heavily relying on APIs, their complexity has skyrocketed, boasting thousands of endpoints and an overwhelming number of parameters. Add user hierarchies to the equation, and you have a perfect storm for unpredictable behaviors threatening not just system integrity, but also corporate reputation.

2. Tackling Unrestricted Access to Sensitive Business Flows

The OWASP list welcomes a newcomer – “Unrestricted Access to Sensitive Business Flows”. This addition underscores new risks like Scalping and Fake Account Creation. It serves as a potent reminder that secure coding alone doesn’t cut it. Secure planning and design are equally crucial when building a new application. In a world where APIs provide bots with easy access, identifying sensitive business flows and applying suitable protection measures is paramount.

3. The Rising Threat of Server Side Request Forgery (SSRF)

Server Side Request Forgery (SSRF) may not be new, but its heightened prevalence and severity in API-based applications have earned it a spot on the OWASP list. Factors like the rising popularity of webhooks have opened the floodgates for hackers to exploit SSRF vulnerabilities. Additionally, the management/control REST APIs of platforms like Cloud, K8S, and Docker have lowered the bar for potential exploitation.

Therefore, the OWASP Top 10 API security risks (2023) list looks like:
  1. Broken Object Level Authorization
  2. Broken Authentication
  3. Broken Object Property Level Authorization
  4. Unrestricted Resource Consumption
  5. Broken Function Level Authorization
  6. Unrestricted Access to Sensitive Business Flows
  7. Server Side Request Forgery
  8. Security Misconfiguration
  9. Improper Inventory Management
  10. Unsafe Consumption of APIs

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:

  1. Broken Object Level Authorization
  2. Broken User Authentication
  3. Excessive data exposure
  4. Lack of resources and rate-limiting
  5. Broken Function Level Authorization
  6. Mass assignment
  7. Security misconfiguration
  8. Injection
  9. Improper assets management
  10. 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 mobile apps and api security

Secure code is an essential element for business growth

Show your customers and supply chain you can manage application risks with secure coding practices.

OWASP 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. 

owasp broken object level authorization

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]",
"userID": "9837",
"password": "TheBestPa$20"

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. 

OWASP API Security Top 10 Vulnerabilities

Mass assignment

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.

Security misconfiguration

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. 

owasp security misconfiguration attacks 1024x726 1

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.

risk equation

Cyber attacks are not a matter of if, but when. Be prepared.

Box-ticking approach to penetration tests is long gone. We help you identify, analyse and remediate vulnerabilities so you don’t see the same pentest report next time.

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.

Article Contents

Related Posts

CREST penetration testing maturity model
Compliance and Regulations

Understanding the CREST Penetration Testing Maturity Model

Penetration testing, or pen testing, is a critical component of any organisation’s cyber security strategy, as it helps to determine vulnerabilities that attackers could exploit. However, simply conducting a pen testing exercise is not enough. Organisations need to ensure that their pentesting strategies, methodologies and programs are mature and effective to ensure that they are

Read More
crest defensible penetration test
Compliance and Regulations

Learn about the CREST Defensible Penetration Test (CDPT) and business benefits

CREST, a non-profit membership organisation that represents the global cybersecurity industry, has developed a specification called Crest Defensible Penetration Test (CDPT). This specification is designed to guide organisations in conducting penetration tests and utilising the test results to enhance their overall security posture and establish security programs during significant growth phases. By adhering to the

Read More
Scroll to Top