OWASP API Security TOP 10: API security checklist for 2023

Discover the latest insights into the 2023 OWASP API Security Top 10, as we delve into the most critical vulnerabilities and best practices to protect your APIs.

OWASP API Security TOP 10: API security checklist for 2023

Is your organization prepared to stay ahead of hackers in 2023 and beyond? Explore the OWASP Top 10 2023 API security checklist and make sure you're protected against devastating breaches like the one experienced by Hathway in December 2023.

Hathway, a prominent Indian ISP and cable service operator, fell victim to a significant data breach when a hacker exploited a vulnerability in Hathway's Laravel framework application. The breach compromised sensitive user data, initially claimed to include details of over 41 million customers. While the actual number of affected accounts was closer to 4 million after accounting for duplicates and dummy accounts, the breach underscores the critical importance of securing web applications, particularly those utilizing popular frameworks like Laravel.

This incident highlights the urgent need for robust security measures, regular vulnerability assessments, and prompt patching of known flaws. Additionally, the hacker's development of a dark web search engine to allow potential victims to assess their exposure represents an unusual level of engagement with the consequences of their actions.

This incident highlights the importance for organizations to prioritize application security and implement comprehensive measures to protect sensitive user data.

Good news! You can start straight away! By adhering to the OWASP Top 10 2023 API security checklist, you can protect your organization from hackers and mitigate the potential impact of breaches on your reputation and customer trust!

Dive right in!

Why API security is crucial in 2023

Welcome to 2023! API security is crucial as technology advances and APIs' usage expands.

Just visualize this - hackers, day in and day out, keenly seeking out weak spots in API implementations. Their goal? Some people may aim to cause chaos by disabling essential services, while others may attempt to make a quick fortune. As we increasingly rely on APIs for functions such as handling financial transactions like one of customers, Shine, one of the leading financial services groups in Europe, or exchanging healthcare data, it becomes even more important to implement robust security measures. Unauthorized access or sensitive data breaches can have severe consequences, making security a top priority.

What are the OWASP TOP 10 vulnerabilities?

The OWASP Top 10 vulnerabilities represent the most critical security risks facing web applications. The OWASP Top 10 API vulnerabilities for 2023 are as follows:

  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

These vulnerabilities encompass a range of security risks, including authentication flaws, authorization issues, resource consumption vulnerabilities, and misconfigurations. Addressing these vulnerabilities is crucial for ensuring the security and integrity of APIs in web applications.

The mission of OWASP is to make software security visible, raise awareness about common vulnerabilities, and provide resources to help organizations develop more secure applications. Their mission wouldn't be complete without nurturing a global community of professionals (which you can join on Slack) who prioritize security just as much as they do. Ready to be part of this journey?

A detailed look at the 2023 OWASP API Security Top 10

Now, let's dive into the 2023 OWASP API Security Top 10, breaking down each security risk and understanding its potential impact.

💡
Keep in mind, though, that theoretical information is never enough when you actually want to fix OWASP vulnerabilities. You need to implement solutions that go beyond generic descriptions and help you give actionable solutions to the developers! This is our advice from the top security engineers like Aleksandr Krasnov, a security engineer at Meta:

"Trying to identify how you can make actionable descriptions to developers that are not just generic enough because you know, you have a bunch of different vendors that will tell you, you know, here are all the issues with it and they'll give you like paragraphs over paragraphs and paragraphs of generic description of like, here's your SQL injection. Here's how it maps to OWASP Top 10, and developers will just skip it. They'll be like, I don't care about it. What do I need to fix? You know, so just make it more understandable, make it more actionable to developers, and make it short because nobody got time." - Aleksandr Krasnov, security engineer at Meta, the Elephant in AppSec podcast

API1:2023 - Broken Object Level Authorization

As we delve into the specifics of the OWASP API Security Top 10, first up is Broken Object Level Authorization (BOLA). It's necessary to understand that this vulnerability emerges when API endpoints fail to verify whether the user is authorized to access the targeted object. Given the agile nature of APIs, they often handle tons of requests for data objects. If these requests aren’t appropriately validated, an attacker can manipulate the references to these objects. Consequently, it opens a window for cybercriminals to bypass authorization and make unauthorized access to data.

For instance, if you're logged into an app that displays specific user details and you notice the URL contains a user ID parameter. An attacker could intercept this URL, change the ID, and potentially access the data of another user, all because the application didn't effectively validate the user's rights to access the presented data.

The implications of a BOLA breach can have far-reaching impacts on an organization - from massive data leaks to unauthorized data manipulations. The trickery of BOLA is in its concealing nature, which highlights the critical need for a robust security policy that ensures each and every API request is properly authenticated and authorized.

How to mitigate BOLA:

We already covered how to mitigate BOLA, but here is a quick recap:

  • Use role-based access control (RBAC) or attribute-based access control (ABAC) to manage permissions effectively. Prefer Attribute-Based Access Control (ABAC) over role-based (RBAC). This adds an additional layer of security, ensuring that users can only access the data they’re authorized to see.
  • Using random and unpredictable GUIDs can deter fraudulent activity, as opposed to sequential IDs that make it easier for an attacker to guess and manipulate.
  • Always test: Implement penetration testing to simulate attacks and identify potential vulnerabilities in your API. This will provide opportunities to address weaknesses before they can be exploited. Don't hesitate to try out Escape!
💡
Interested in hands-on knowledge about BOLA? Visit our API Security Academy and learn how to find and fix this vulnerability in GraphQL.

API2:2023 - Broken Authentication

As we move further into the 2023 OWASP Top 10, we come to the second major vulnerability, commonly termed Broken Authentication. This issue looms large in the sphere of API security and continues to pave the way for significant cyber-attacks, causing detrimental effects on a global scale.

As you're well aware, authentication in an API is the process through which a user's identity is verified before they're granted access to an application or a service. Rightly called the gateway to systems, if this process is compromised or 'broken', it can lead to unauthorized access and unauthorized actions.

Here, 'broken' refers to a flaw or vulnerability that can be triggered or exploited. A hacker can, through this, gain illegal access to the system and carry out malicious activities. In 2023, 'broken' also signifies situations where the authentication mechanism has been poorly implemented or handled, leading to security gaps.

"Broken authentication typically occurs when the session management process or the user authentication process is inadequately deployed or improperly handled."

Examples of broken authentication could range from the system's failure to validate the user's credentials correctly, to the insecure management of session IDs or other access credentials.

How to mitigate Broken Authentification?

Let's take a look at some ways you can mitigate this risk (and apply your learnings here):

  • Implement Multi-Factor Authentication (MFA): MFA adds an additional layer of security by requiring users to provide two or more pieces of evidence (or factors) to authenticate their identity. This can significantly reduce the risk of successful attacks.
  • Utilize modern authentication protocols: Employ Open ID Connect or OAuth 2.0 for standard authentication protocols to minimize the risk. Using these standard protocols means that you're using tested and verified authentication methods.
  • Token Management: Token management includes ensuring that tokens have a short lifespan and are adequately secured. The tokens should be regenerated post successful authentication. Principal tokens should not be sent in the URL.
  • Encrypt sensitive data: Encryption can be a strong defense against eavesdropping attacks where authentication data can be captured by an attacker.
  • Use secure cookies: Cookies should be securely transmitted and, if possible, the HttpOnly attribute should be used to prevent client-side scripts from accessing them.

In conclusion, there's no one-size-fits-all solution to mitigate the risk of Broken Authentication. The best approach usually involves a combination of robust practices, and investing in security testing to uncover and fix vulnerabilities.

API3:2023 - Broken Object Property Level Authorization

There's a new threat that you need to be aware of - Broken Object Property Level Authorization. This vulnerability occurs when an API permits users to update or view properties or fields of a data object they shouldn't have access to, thereby violating access controls. BOPLA is a new addition that combines the 2019 list’s Excess Data Exposure and Mass Assignment.

For instance, imagine an API that permits a user to update their own profile. However, if the API is not properly secured, this user might be able to change the isAdmin property from false to true, thereby gaining administrative access. The effects of such breaches could be catastrophic, with attackers potentially obtaining the capacity to alter object properties to their advantage, leading to unauthorized system changes and sensitive information exposure.

💡
Here is an example of GraphQL where an attacker could exploit BOPLA.

To counteract the Broken Object Property Level Authorization, you should implement testing strategies that validate field-level permissions. Additionally, you should enforce tight access controls that adhere to the principle of least privilege (PoLP). This suggests that a user should only have access to the features and data necessary for them to perform their role and no more.

And don't forget to implement rigorous testing for your API, checking for insufficient property-level authorizations.

Want to check if your API is vulnerable? Book a demo with us and we'll run a test for your endpoints👇

API4:2023 - Unrestricted Resource Consumption

API4:2023 - Unrestricted Resource Consumption, is a vulnerability you cannot afford to ignore. In the 2023 edition, the title has changed from Lack of Resources & Rate Limiting. This vulnerability describes a situation where an API aggressively consumes system resources, potentially leading to system failure or slowdowns and an increase in operational costs.

Imagine you are running a high-traffic e-commerce site. Now, consider what would happen if an attacker could exploit an API to consume resources unrestrictedly. It could result in slowed responses, frustrated customers, and lost sales.

But how does Unrestricted Resource Consumption occur? Think about situations where the API allows batch processing, such as uploading multiple files at once or bulk changes to database records. If these APIs don't have limitations or restrictions on the amount of data to be processed at a single time, an attacker can overwhelm the server resources by sending excessive requests or enormous data sizes.

Now, how can you mitigate this risk? Here are some tips:

  • Limit query complexity and depth using tools like GraphQL Armor.
  • Throttle your API: Implement usage quotas and rate-limiting to prevent users from consuming resources beyond a certain level.
  • Use a load balancer: A load balancer can divide the heavy traffic across multiple servers, making sure no single server is overwhelmed with requests.
  • Apply Timeouts and Deadlines: Introduce timeouts and deadlines on processing and requests to ensure they don't run indefinitely and consume resources unnecessarily.
  • Test your system regularity: Regular stress and load testing can uncover potential bottlenecks and enable you to rectify any issues before they become problems.

API5:2023 - Broken Function Level Authorization

Breathe in, hold it, and then let it out. Feel your heartbeat for a second. Now, imagine for a moment that your API is your body and each function, an organ vital for your survival. What would happen if an unauthorized person gained control of these functions? Unsettling, right? This is exactly what API5:2023 - Broken Function Level Authorization precisely means. It's the fifth villain among our API vulnerabilities, and it's certainly a force to reckon with.

Unlike Broken Object Level Authorization (which we've previously discussed), where the concern lies at the object or item level, Broken Function Level Authorization is a devious vulnerability that targets permissions assigned to execute tasks or functions within the API.

But here's the good news: like its predecessors in the OWASP top 10, API5:2023 is preventable. An effective approach involves implementing a robust policy of least privilege:

This strictly allows each user only the permissions necessary to perform their work, nothing less, but importantly, nothing more.

Using server-side control for function-level access, complemented by thorough scenario-based testing, can also help keep this vulnerability at bay.

💡
Learn in our Academy how to exploit and then fix Broken Function Level Authorization

API6:2023 - Unrestricted Access to Sensitive Business Flows

Let me set a scene for you. Picture this: a seemingly harmless customer interacting with your business API. They're navigating your platform, and before you know it, they've chanced upon sensitive business flows that should have been securely barricaded. Scary?

Detecting business logic vulnerabilities will be an even bigger challenge in the future:

I suspect that we're going to have a lot more like us, as security folks, we'll probably stop focusing on the foundational issues. And we'd be looking at much more difficult issues that our tooling has a hard time to find. Like business logic issues in itself very difficult or even AI-related issues securing AI and LLM  in itself.  - Jeevan Singh, Director of Security, Rippling

But you might be wondering, what does 'Unrestricted Access to Sensitive Business Flows' genuinely mean?

Essentially, it refers to a situation where an attacker gains unauthorized access to critical business operations or sensitive data due to inadequate access control measures. A common example might be the impact on a financial application where an attacker can manipulate transaction processes and disrupt normal business operations. Seem far-fetched? Trust me, it's not. In fact, the real-world implications are even more significant.

Imagine you need to do mitigation planning. Where should you start? It begins with envisioning defense in two thorough layers: the Business and the Engineering.

💡
The Business layer - Have you laid bare the business workflows that could wreak havoc within the business, should they be abused or overly employed? This identification is essential.

Other strategies include:

  • Device fingerprinting: A novel concept, isn't it? Denying service to unanticipated client devices, such as the infamous headless browsers, forces our unwelcome threat actors to level up their game. The upside? This adds a significant financial burden to them.
  • Use the power of captchas or even biometric solutions like typing patterns
  • Analyze the user's journey to detect non-human patterns
  • Contemplate the unprecedented step of blocking IP addresses from Tor exit nodes and known proxies. A drastic move, perhaps, but one that could pay off handsomely.

API7:2023 - Server Side Request Forgery

💣
At Escape, this is the OWASP TOP 10 vulnerability that occurs the most in the GraphQL applications of our customers.

Here's an illustration for you: Consider an API as a trusted courier, expected to deliver specific messages to specific locations. Server Side Request Forgery occurs when an attacker tricks the API-courier into delivering a malicious message to an unintended location; perhaps within the internal network’s safe boundaries. Sounds alarming, doesn't it?

A typical SSRF attack sequence might proceed as follows:

  1. An attacker crafts a specific request which feeds the vulnerable API endpoint with a deceptive internal URL.
  2. The unsuspecting API conveys this request to the internal system believing it to be a legitimate internal request.
  3. The once-secure internal system processes the forged request exposing sensitive information back to the invader or worse performing harmful operations.

So now you're probably thinking, "Alright, that sounds terrifying. But how do I protect my API from SSRF exploits?"

Start by ensuring you have robust validation & sanitization techniques in place, which only accept URLs that are intended to be processed. Implementing technologies like Web Application Firewalls (WAFs) can help detect and block SSRF attempts, particularly in cloud environments. Also, consider applying least privilege principles to your server operations, minimizing the potential harm an SSRF exploit can inflict.

API8:2023 - Security Misconfiguration

Can you fathom the calamity when your system's front door is left wide open, forcing you into an unforeseen pit of disaster? This, in essence, is what a security misconfiguration can inflict on your system. What exactly constitutes a security misconfiguration? Why is it so essential in 2023?

A security misconfiguration occurs when appropriate security settings are not defined, implemented, updated, or maintained. Some examples: the use of default system configurations, lack of secure network configurations, verbose error messages containing sensitive information. This laxity allows malicious insiders or unauthorized users to access, modify or extract data, injecting your seemingly secure app with malicious codes.

💡
Check out the GraphQL example here.

In 2023, the rise of sophisticated cyber-attacks accentuates the urgency of eliminating security misconfigurations. The accelerated digital transformation, fueled by the pandemic's inadvertent push, has made systems more complex and often hurriedly established — prime targets for exploitation.

Your vigilant eyes and meticulous actions can help avert the disaster promising to transpire due to security misconfigurations. Here is a list of valuable tools at your disposal for mitigating such debilitating risks:

  • implement a proper Cross-Origin Resource Sharing (CORS) policy
  • Make sure to include the appropriate security headers
  • Keep up to date with your server configurations
  • Automate the detection process with Escape to continuously assess the effectiveness of the configuration and settings in all environments

API9:2023 - Improper Inventory Management


Yes, you heard it right – Improper Inventory Management has made its way to OWASP's roster of lethal vulnerabilities in 2023. API Sprawl is the growing 2024 challenge, and developers must maintain thorough documentation and understand their API inventory, as the change from "Assets" to "Inventory" emphasizes the importance of versioned endpoints. You can't secure what you cant see, right?

💡
Discover how Escape's automated API inventory can help you build your inventory in minutes and prevent this vulnerability. No agent or changes in infrastructure are required. You can prioritize your most critical API by business use, data sensitivity, and exposure.

The absence of centralized, coherent tracking can result in zombie and shadow APIs – the ones that exist, but none of your team is aware of them. These zombie APIs are created by expeditious teams and developers forgetting to document them or leaving them behind as legacy code during agile sprints – ticking time bombs for your organization.

💡
Want to learn from the experts on how to mitigate API sprawl? Sign up for our upcoming fireside chat with Erik Wilde.

Resorting to manual tracking may quickly get out of hand given the enormity of the task. Fortunately, various automated API inventory tools can help you manage and secure these haunting APIs.

What you can also automate is documentation generation by adopting open standards. Include the documentation built into your CI/CD pipeline.

And last but not least, make API documentation available only to those authorized to use the API.

API10:2023 - Unsafe Consumption of APIs

How you consume an API for its intended purpose is every bit as important as how you manage and secure those API assets themselves. API10:2023, or 'Unsafe Consumption of APIs', is a term that may sound non-threatening to the untrained ear, but it undoubtedly sends chills down the spine of any seasoned cybersecurity professional. Why? Let's dissect this.

💡
This new category replaces “Insufficient Logging & Monitoring” and focuses on the risks of trusting third-party APIs.

Imagine you're walking through an unfamiliar city, would you blindly trust every direction? Unlikely, isn't it? The same vigilance should be exercised when dealing with data from external APIs.

So to ensure you protect yourself properly against this vulnerability, follow our guidelines below:

  • Brace yourselves against trusting any data that hasn't undergone the rigors of proper input validation and sanitization.
  • Implement error handling to prevent security issues when consuming external APIs.
💡
You can easily check the reputation of third-party APIs on APIRank.

Tools for mitigating risks

In addition to the techniques listed above, various tools are also available to help organizations mitigate the risks associated with API security. These tools may include vulnerability scanners and security testing frameworks.

This is why we created Escape, the first automated API Inventory & API Security scanner that allows developers to catalog all their APIs, find and fix bugs in applications in CI/CD before they even reach production!

How to stay ahead of API Security threats

To stay ahead of rapidly evolving API security threats, organizations must remain vigilant and adaptive. It is crucial to stay updated with the latest security standards, follow industry best practices, and regularly assess and enhance the security posture of your APIs.

In conclusion, understanding and addressing the most critical API security vulnerabilities identified in the OWASP Top Ten 2023 is crucial for organizations aiming to enhance their cybersecurity posture. By implementing robust access control measures, enforcing secure coding practices, and adopting the latest security technologies, your business can significantly reduce your risk exposure and protect your valuable assets from potential threats.



Want to learn more about API security?
Check out the following articles: