The Open Web Application Security Project (OWASP) provides security recommendations detailed in prioritized, actionable Top Ten lists. The OWASP API Security Top Ten is an invaluable resource. It’s an excellent starting point for mastering the unique vulnerabilities and security risks APIs present.

But security leaders should also remember that there are many more than ten critical vulnerabilities in API security. They should also keep in mind that each organization will have a unique application risk profile.

What are the OWASP API Top 10 Risks?

OWASP classifies each API security threat by four criteria – exploitability, weakness prevalence, weakness detectability and technical impact. Each factor is given a score with three being the most severe. A vulnerability that is easy to exploit, widespread, and easily detectable with severe technical impact is the most urgent to address.

These dimensions allow API security risks to be force-ranked in terms of severity. In this next section, we’ll introduce each vulnerability then indicate which OWASP cheat sheets best address them so that your organization can improve its security posture. For reference, the OWASP Cheat Sheet Series was created by application security experts to provide high value information on specific application security topics.

API1:2019 – Broken Object Level Authorization

Exploitability: 2 | Prevalence: 3 | Detectability: 2 | Technical Impact: 3

APIs often expose endpoints that handle object identifiers, resulting in a wide attack surface in access level control. As a result, attackers may be able to read, update, delete or create data objects without permission. This is by exploiting broken object-level authorization vulnerabilities. Individual authorization checks are necessary for every function that interacts with a data source.

• Authorization Cheat Sheet (API1, API5) 
  Authentication is different from authorization. Authentication focuses on verifying an entity’s identity. Authorization is verifying that a requested action or service is approved for a specific entity.
  
  This authorization cheat sheet aims to assist developers in creating robust, appropriate, maintainable, and scalable permission logic for apps. It is applicable to all phases of the development lifecycle and accounts for the diversity of development environments.

• Authorization Testing Automation Cheat Sheet (API1, API5) 
  This cheat sheet describes a proposition of implementation for automating tests for an authorization matrix.

API2:2019 – Broken User Authentication

Exploitability: 3 | Prevalence: 2 | Detectability: 2 | Technical Impact: 3

As stated, authentication is the process of verifying that an individual, entity, or website is who it claims to be. As part of the authentication process, users are usually required to submit credentials. Things like username, ID, and one or more items of private information that only they would know.

Authentication is more complex to implement for APIs because MFA and other human-driven authentication options aren’t possible. Then, authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws. This allows attackers to take over other users’ identities temporarily or even permanently. Compromising the ability to identify the user compromises overall API security and potentially exposes sensitive data.

• Authentication Cheat Sheet (API2)
  This cheat sheet delineates general guidelines around user IDs, authentication solution usage, password strength, and recovery controls. It also includes guidelines around protection from automated attacks, as well as MFA, CAPTCHA, and other authentication protocols.

API3:2019 – Excessive Data Exposure

Exploitability: 3 | Prevalence: 2 | Detectability: 2 | Technical Impact: 2

Sometimes, in an effort to be able to do a lot, APIs say too much. To promote utility, developers tend to expose all object properties without considering their individual sensitivity, depending on clients to filter the data before showing it to the user.

API4:2019 – Lack of Resource & Rate Limiting

Exploitability: 3 | Prevalence: 3 | Detectability: 3 | Technical Impact: 2

In many cases, APIs do not restrict the size or number of resources that can be requested by the client. This means users can make huge requests, inadvertently or maliciously. This can not only negatively impact API server performance, leading to Denial of Service attacks (DoS), but can also leave the door open to authentication flaws such as brute force attacks.

• Denial of Service Cheat Sheet (API4)
  This cheat sheet provides an overview of DoS attacks and guidance on how to approach different denial of service (DoS) scenarios, including both application and network attacks.

API5:2019 – Broken Function Level Authorization

Exploitability: 3 | Prevalence: 2 | Detectability: 1 | Technical Impact: 2

Managing who can access which functions can be tricky. Authorization flaws tend to occur in complex access control policies. Ones with hierarchies, roles, and groups, and an unclear distinction between administrative and regular functions. An attacker can gain access to other users’ resources or admin functions by exploiting these weaknesses.

• Authorization Cheat Sheet
• Authorization Testing Automation Cheat Sheet

API6:2019 – Mass Assignment

Exploitability: 2 | Prevalence: 2 | Detectability: 2 | Technical Impact: 2

Hackers can be good guessers. Attackers can modify object properties by guessing objects’ properties, exploring API endpoints, reading documentation, or including additional object properties in request payloads. Client-provided data (e.g., JSON) bound to data models without proper filtering based on an allowlist usually results in Mass Assignment.

• Mass Assignment Cheat Sheet (API 6)
  This cheat sheet explains how to create Data Transfer Objects and avoid binding input directly to domain objects. This involves allow-listing the bindable, non-sensitive fields and block-listing the non-bindable, sensitive fields.

API7:2019 – Security Misconfiguration

Exploitability: 3 | Prevalence: 3 | Detectability: 3 | Technical Impact: 2

Sometimes people just make small errors setting things up. Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, misconfigured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS), and/or verbose error messages containing sensitive information.

• Transport Layer Protection Cheat Sheet (API 7) 
  This cheat sheet explains how to implement transport layer protection for an application using Transport Layer Security (TLS). It is mostly focused on how to use TLS to protect clients connecting to a web application over HTTPS. But most of the guidance can be applied to other uses of TLS.
  
• HTTP Strict Transport Security Cheat Sheet (API 7) 
  HTTP Strict Transport Security (HSTS) is an opt-in security enhancement specified by a web application via a special response header. Once this header is received by a supported browser, it will stop any communications from being sent over HTTP to the specified domain. It will instead send all communications over HTTPS. It also prevents HTTPS click-through prompts on browsers. Here is the cheat sheet.
  
• TLC Cipher String Cheat Sheet (configuration generator) (API 7) 
  These online tools allow site administrators to select the software they are using and receive a configuration file that is safe. They also are able to confirm compatiblilty with a wide variety of browser versions and server software.
  • Mozilla SSL Configuration
  • Cheat sheet
    
• HTTP Security Response Headers Cheat Sheet (API 7) 
  This cheat sheet helps ensure proper HTTP response headers to stave off cross-site scripting, clickjacking, information disclosure, and other vulnerabilities. It provides an overview of all security-related HTTP headers, recommends configurations, and references other sources for complex headers.

API8:2019 – Injection

Exploitability: 3 | Prevalence: 2 | Detectability: 3 | Technical Impact: 3

If data and code aren’t carefully separated, problems arise. When untrusted data is sent to an interpreter as part of a query or command, injection flaws can occur. Such as SQL, NoSQL, and Command Injection. An attacker can manipulate malicious data to trick the interpreter into performing unintended commands or accessing information without authorization.

• Injection Prevention Cheat Sheet (API 8)
  This cheat sheet provides concise guidance for preventing injection flaws from getting into applications.

API9:2019 – Improper Assets Management

Exploitability: 3 | Prevalence: 3 | Detectability: 2 | Technical Impact: 2

You can’t protect what you don’t know about. As discussed prior, a good API inventory and documentation is essential because APIs expose more endpoints than traditional web applications.

API10:2019 – Insufficient Logging and Monitoring

Exploitability: 2 | Prevalence: 3 | Detectability: 1 | Technical Impact: 2

Most APIs weren’t inherently designed to be good at reporting into top-level security tools. When insufficient logging and monitoring is coupled with ineffective integration to incident response, it can spell disaster.

Hackers can further attack systems, maintain persistence and pivot to other systems to extract, tamper with or destroy data. It often takes more than 200 days for a breach to be detected. And truth is, most breaches are detected by external parties rather than by internal processes or monitoring.

• Logging Cheat Sheet
  This cheat sheet guides developers on building application logging mechanisms, especially those related to security logging.

Why Use the OWASP API Top 10?

The OWASP Top Ten is not a complete list of security attacks. However, it is a reference guide that describes the most common API vulnerabilities. At its heart, the OWASP Top 10 is concerned with the promotion of API security best practices. It assists both security professionals and developers prioritize security from the beginning of API development through deployment. 

Security teams find the list indispensable because it allows them to correlate their own security policies with real security events. Developers can also take concrete action to secure APIs and protect users against malicious attacks.

Ultimately, the Top 10 helps create more secure APIs. It empowers teams to bake OWASP security into how they code, configure, and deliver their products. This API security checklist is great place to start to ensure you have the right security controls in place.

Does Noname Security offer OWASP API Top 10 Risk Solutions?

Yes. Noname Security can help you achieve the many goals that OWASP sets forth without changing your network or sacrificing choice. With Noname Security, you can discover APIs before attackers do, analyze API behavior and remediate any source of API risk. The Noname API Security Platform is an out-of-band solution that doesn’t require agents or network changes. O offers deeper visibility and security than API gateways, load balancers, and WAFs.

Our approach helps you address API Discovery, API Posture Management, API Runtime Security, and API Security Testing. Now you can protect APIs in real-time and detects vulnerabilities and misconfigurations before they are exploited.

Learn more about Noname’s approach to API security and how it dovetails with the OWASP recommendations here.