OWASP Top 10 Cheat Sheet

The OWASP Top 10 is a powerful awareness document for web application security created by OWASP; an international nonprofit organization focused on improving the security of software.

It represents a broad consensus about the most critical security risks to web applications and serves as a handy reference guide for security professionals. More recently, OWASP created a new list of the Top 10 API security threats. These risks include:

API1: Broken Object Level Authorization

Broken object level authorizations (BOLA) refer to an insecure direct object reference (IDOR) which involves a user being able to directly access resources they should not be able to access.

The most common way involves altering an ID parameter which makes access possible due to a lack of adequate authorization checks. Attackers can replace the ID of their resources with the ID of another user’s resource in an API call, and because the API does not validate these permissions and allows the call to go through, that vulnerability exists.

To prevent BOLA attacks, organizations must turn to API security solutions to be able to detect when one authenticated user is attempting to get unauthorized access to another user’s data.

API2: Broken User Authentication

Attackers can assume the identity of other users due to inadequate API authentication, which can be carried out through brute-force attacks and credential stuffing.

Several technical causes contribute to API authentication failures, and they include:

Shared/default passwords that are weak and badly hashed.

Weak authentication that does not adhere to industry standards

This shows that all authentication options for APIs need to be examined carefully. An API security solution should be used to evaluate the normal authentication sequence for every API flow, and this is so that any unusual behavior can be easily detected.

API3: Excessive Data Exposure

This occurs when the API exposes far more data than the client actually requires, relying on the client to filter it. An attacker can sniff a client’s traffic to get access to sensitive data such as:

• Social security & credit card numbers
• Passwords and authentication credentials
• Medical record numbers or other health information

To prevent this, clients should never be relied upon to filter data, and response tests should be enforced to avoid data and exception leaks by accident.

API4: Lack of Resources & Rate Limiting

APIs do not necessarily include limits on the size or number of resources that a client or user can request. This not only has the potential to degrade API server performance and cause a Denial of Service (DoS), but it also opens the door to brute-force and enumeration attacks against APIs that provide authentication and data retrieval functions.

This simply means that the API is unprotected against a large number of calls, and this can happen when the attacker overloads the API, usually by an excessive rate of queries. Rate limiting is therefore called for because it controls the number of requests a user can make to a service, reduces the chances of getting overwhelmed by too many requests at once, and enables the mitigation of DoS attacks.

API5: Broken Function Level Authorization

Function level authorization is the level of protection for individual functions within your application, and it controls which user or group can perform a specific function and what operations that function can perform. Broken function level authorization (BFLA) is quite similar to BOLA, but in this case, applications fail to limit sensitive functions to authorized users.

API6: Mass Assignment

Mass Assignment occurs when client-provided data is bound to data models without sufficient properties filtering based on an allowlist.

Attackers can edit object properties they aren’t allowed to via guessing object properties, investigating other API endpoints, or giving new object properties in request payloads. Mass assignment can lead to SQL injection attacks because an attacker can manipulate objects with malicious intent.

API7: Security Misconfiguration

Security misconfiguration occurs when a web application is set up in such a way that it exposes data and functionality that could lead to an attack. Attackers can take advantage of poorly configured API servers, including systems that haven’t been patched or files and folders that have not been password-protected.

This can be tackled by limiting administrative access, turning off non-useful features, and undergoing automation. An API security solution can help detect misconfigurations and security gaps.

API8: Injection

Injection attacks are a type of attack that occurs when malicious data is inserted into a specific input field in an application. The most common example of an injection attack is SQL Injection, where attackers try to insert their own SQL commands into an application’s database queries in order to manipulate the data stored there.

Other types of injection can affect a variety of interpreters and parsers besides SQL, such as LDAP, NoSQL, operating system (OS) commands, Extensible Markup Language (XML), and Object-Relational Mapping (ORM).

Some useful tips for handling this include:

• Preventing data leaks by defining, limiting, and enforcing API outputs.
• Validating, filtering, and sanitizing any data that comes in.

A9: Improper Assets Management

Understanding potential exposure and risk requires keeping an up-to-date API inventory with accurate documentation. Unknown gaps in the API attack surface occur from an outdated or incomplete inventory, making it impossible to detect older API versions that should be decommissioned.

Similarly, incorrect documentation exposes sensitive data to unknown risks and makes it difficult to detect vulnerabilities that must be addressed. Attackers can discover non-production versions of the API that are under-protected, such as staging, testing, beta, or previous versions, and use them to launch the attack.

Preventing this requires one to keep track of all API hosts, restrict access to information that should not be made public, and control who has access to production data. Outdated versions should also be appropriately retired.

A10: Insufficient Logging & Monitoring

Insufficient logging and monitoring is a common problem for most organizations, and attackers can go undetected due to a lack of logging, monitoring, and alerting. Some logs (manual) are poorly designed and not safeguarded against tampering.

This vulnerability can be addressed by:

• Monitoring logs for anomalies and analyzing for trends and patterns
• Reviewing regularly and storing in a secure location.
• Monitoring, alerting and integrating with SIEMs and other dashboards.
• Keeping track of failed attempts, refused access, input validation errors, and any other errors.

Conclusion

As enterprises move more toward API deployment than monolithic software, they also shift the security implications of their infrastructure. The OWASP Top 10 Cheat Sheet can help point out some of the most relevant security threats to modern API-based systems deployed in a distributed computing environment.

Joanna can be reached at LinkedIn or at Bora Design.

If you need help with cybersecurity content, please contact Bora.