A Quick Look at The OWASP API Security Top 10

A Quick Look at The OWASP API Security Top 10

Modern applications across all industries rely heavily on APIs, or Application Programming Interfaces. As a result, APIs are a critical element of those applications that might leak sensitive data and expose organizations to a variety of attacks. API security deals with the risk related to the creation, implementation, and use of APIs.

In a previous article, I talked about the common risks and attacks associated with APIs. Here is a quick recap of the top flaws that might cause APIs to expose application logic and sensitive information:

• Use of hard-coded credentials
• Credential Stuffing Attacks
• Accidental key exposure
• Insecure key generation
• Misconfigurations
• Distributed Denial-of-Service (DDOS) Attacks
• Man in the Middle (MITM) Attacks

In this post, I will walk you through the top API Security Risks and the best practices that will help you enhance your security posture and reduce your API attack surface.

OWASP API Security Top 10

To enhance web application security, a non-profit group called OWASP® (the Open Web Application Security Project®) was founded to empower anyone looking to create a safe web application with a wealth of free materials and frameworks.

The OWASP Top 10, an awareness document for developers and web application security, is probably the most well-known project that OWASP has ever undertaken because it focuses on the most significant, evolving threats posed on the web. However, the API Security Top 10 is necessary because it addresses a different need connected to the nature of APIs and the risks to which they are susceptible.

In order to identify the API Security Top 10, a risk analysis was done using the OWASP Risk Rating Methodology. Then the results were reviewed by a group of security professionals. The first draft of the OWASP API Security Top 10 2019 came from a consensus between the statistical results from phase one and the lists from security practitioners.

In the next section, we are going to discuss the API Security Top 10 in order to have an understanding of the threats and the preventative measures.

API Attack Scenario

To give an idea of a real-life scenario, let’s review a scenario where a Food Delivery application allows users to edit their basic profile information. For that, an API call needs to be made to PUT /api/v1/users/me with the following JSON object:

The request might include an additional credit_balance property:

A malicious actor could replay the request with a custom payload:

In this scenario, the attacker replayed the API call to increase their credit card balance without paying the corresponding amount. This was achievable due to the lack of controls around property assignments where end users were given permissions to edit properties they were not supposed to change.

API Security Top 10 Risks and Mitigations

Here is an overview of the OWASP API Security Top 10:

#1 Broken Object Level Authorization

Overview: APIs frequently provide endpoints that deal with object IDs, leading to a problem with Level Access Control. Every method that uses a user input to access a data source should take object level authorization checks into account.

Mitigation: Put in place an appropriate authorization system that depends on user policies and hierarchy, use arbitrary and unpredictable GUIDs for record IDs, and create tests to assess your authorization methods.

#2 Broken User Authentication

Overview: Because authentication techniques can be complex, they are frequently designed poorly, attackers can compromise authentication tokens or take advantage of implementation vulnerabilities to temporarily or permanently assume other users' identities. A system's capacity to recognize the client or user threatens API security as a whole.

Mitigation: Identify all the authentication flows and follow the authentication standards for token generation, password policies, and storage. Also, consider brute force protection – account lockout policies can defend from the most common attacks.

#3 Excessive Data Exposure

Overview: Developers frequently publish all object attributes without taking into account each one's unique sensitivity in anticipation of generic implementations, depending on clients to handle the data filtering prior to the user seeing it.

Mitigation: Have clear visibility on the sensitive data you are storing or returning to clients to make sure it’s done securely when allowed by laws and regulations that apply to you and your customers.

#4 Lack of Resources & Rate Limiting

Overview: The size or quantity of resources the client or user may request is frequently not capped by APIs. This opens the door to authentication issues (like brute force), in addition to having an adverse effect on the performance of the API server and resulting in Denial of Service (DoS).

Mitigation: Prioritize the use of containers to efficiently manage your resources, limit the frequency of calls a client can make, and have restrictions around the size of incoming parameters and payloads.  

#5 Broken Function Level Authorization

Overview: Authorization issues frequently result from complex access control rules with several hierarchies, groups, and roles as well as a blurred line between administrative and normal operations. Attackers can access other users' resources or administrative features by taking advantage of these flaws.

Mitigation: Specify each function's roles explicitly and continuously review your API’s function-level authorizations.

#6 Mass Assignment

Overview: Mass Assignment frequently results from binding client-provided data to data models without sufficient attribute filtering based on an allowlist (for example, JSON). Attackers can change object properties without permission by guessing the properties of the objects, investigating other API endpoints, reading the documentation, or including extra object attributes in request payloads.

Mitigation: Use functions that don't immediately convert client input into internal objects or variables, only include the allowed attributes that the client should update, and specify the schemas to enforce the input data payloads.

#7 Security Misconfiguration

Overview: Insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, incorrectly configured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information are common causes of security misconfiguration.

Mitigation: Hardening is an ongoing process where you will have to make sure you deploy hardened assets and configurations and make sure your configuration stays secure by controlling changes and alerting using automated policies and processes.

#8 Injection

Overview: When untrusted data is provided to an interpreter as part of a command or query, injection issues in SQL or NoSQL, Command Injection, and other injection attacks happen. The attacker's malicious data may trick the interpreter into carrying out unwanted commands or granting unauthorized access to data.

Mitigation: In addition to validating the data provided by the clients and limiting the number of returned records, make sure you clearly define the data types for the string parameters.

#9 Improper Assets Management

Overview: Since APIs typically expose more endpoints than conventional web apps, accurate documentation is crucial. Deprecated API versions and exposed debug endpoints are two problems that may be mitigated by properly inventorying deployed API versions and hosts.

Mitigation: You can’t protect the unknown, so make sure that all your assets – including APIs – are inventoried and have an owner assigned. Then categorize your assets based on their sensitivity and criticality to the business in order to protect them accordingly.

#10 Insufficient Logging & Monitoring

Overview: Inadequate logging, monitoring, and integration with incident response enables attackers to carry out more attacks, retain persistence, and pivot to additional systems in order to alter, extract, or delete data. According to the majority of breach studies, it normally takes more than 200 days for a breach to be discovered, and external parties more often than internal processes or monitoring do so.

Mitigation: Log activities and continuously monitor the infrastructure, network, and APIs, and make sure the logs are stored securely in a centralized location where access is controlled following least privilege and need to know principles. In addition to that, make sure alerts are configured and logs are reviewed regularly.

Conclusion

Security is a continuous process. Besides the proactive work of secure design, threat modeling, hardening, and implementing controls, it requires constant monitoring, assessment, mitigation, and alerting. But since you can’t protect the unknown, you must have clear visibility of your assets and their value to focus on what’s important and effectively manage your risks. Here below is a quick recap of some golden rules for securing your APIs:

• Inventory all your assets
• Stay aware of vulnerabilities and mitigate them in a timely manner
• Harden your configurations
• Follow the least privilege principle when conjuring authorizations
• Validate the clients inputs
• Limit the rate and size of the incoming API calls
• Have visibility into your sensitive data
• Only provide the necessary information to clients
• Follow the best practices when setting up authentication mechanisms

Now that you have an idea about where to start, go and explore the resources below to start building securely.

Other API Security Related Resources

You can learn more about the OWASP project for both Web Applications and APIs, where you can find more information on Application Security Tools and Standards. Also, don’t forget to check out my Basic API Security Guide.

Seif Hateb is a Security Professional working as a Principal Security Engineer at Twilio. With more than a decade of Security experience with success in guiding the design, testing, and implementation of leading-edge technologies and solutions while balancing security initiatives to risks, business operations, and innovations.

His specialties include Security Architecture, Cryptography, Data Protection, System Hardening and Security Assessment with extensive experience in the Telecommunications and Healthcare industries. Find him on LinkedIn and Twitter.