OWASP TOP 10 API SECURITY RISKS

Why OWASP API Top 10?

The Open Source Web Application Security Project has compiled a list of the 10 biggest OWASP API security threats faced by organizations. According to the Gartner API strategy maturity model report, 83% of all web traffic is not HTML now, it is API call traffic. By 2021, exposed APIs will form a larger surface area for attacks than the UI in 90% web-enabled applications. By 2022, APIs will become the No 1 attack vector.

API SECURITY

Fig: Traditional Applications vs Modern Applications

According to security researchers, Authorizations and Improper Asset Management are two areas of special concerns when dealing with OWASP API Security. Traditional vulnerabilities like SQLi, CSRF and XSS are becoming less common in APIs.

OWASP API Top 10

  1. Broken Object Level Authorization
  2. Broken Authentication
  3. Excessive Data Exposure
  4. Lack of Resources & Rate Limiting
  5. Broken Function Level Authorization
  6. Mass Assignment
  7. Security Misconfiguration
  8. Injection
  9. Improper Assets Management
  10. Insufficient Logging & Monitoring

1. Broken Object Level Authorization

Broken Object Level Authorization is also known as Insecure Direct Object Reference. It occurs when an application provides direct access to the objects based on the user-supplied input. It allows attackers to bypass authorization and access resources directly by modifying the value of a parameter used to direct an object.

Mitigation:  

  • Use random IDs that cannot be guessed (UUIDs).
  • Implement authorization checks with user policies and hierarchy.
  • Do not rely on IDs that the client sends.

2. Broken Authentication

Authentication is the process of verifying the user’s identity. Authentication is one of the five pillars of information assurance that resides along with Integrity, Availability, Confidentiality, and Non-repudiation. Poorly implemented API authentication allows attackers to assume other user’s identities. Lack of access token validation, Use of Weak, plain text, poorly hashed, default passwords are use cases of broken authentication.

Mitigation:

  • Check all possible ways to authenticate all APIs.
  • Use standard authentication, token generation, password storage, MFA.
  • Use short-lived access tokens.
  • Use rate-limiting for authentication.

3. Excessive Data Exposure

Excessive Data Exposure occurs when an application or program, like a smartphone app or a browser, does not adequately protect information such a password, payment info or personal data. For example, if you want to get some specific information about your profile you will make a call(/profile/{id}) to the server and the server pulls the data from database and respond back to you with all the details that are available in the database rather than giving the specific data that has been requested for.

Mitigation:

  • Never rely on the client to filter data.
  • Review all the API responses and see that the response does not have any other additional details apart from the details that it has been requested for.
  • Enforce response checks to prevent accidental leaks of data or exceptions.

4. Lack of Resources & Rate Limiting

Unlimited access to an OWASP API security can have severe consequences like Denial of Service (DoS) and authentication flaws like brute force attacks. Rate limiting prevents malicious code from abusing legitimate/illegitimate access to your API.

Mitigation:

  • Set a limit on how often a client can call the OWASP API security within a defined timeframe.
  • Limit payload sizes.

5. Broken Function Level Authorization

Authorization occurs after your identity is successfully authenticated by the system, which gives you full access to resources such as information, files, databases, etc. However, authorization verifies your rights to grant access to the resources. If an attacker accesses the unauthorized system, he/she can cause the Elevation of privileges, disclosure of confidential data, data tampering and compromising admin level accounts.

Mitigation:

  • The application mechanism should deny all access by default and provide access to specific roles for every function.
  • Do not rely on the client to enforce admin access.
  • Do not allow unauthorised users to perform any operations which they are not supposed to do. (avoid broken access vulnerabilities).

6. Mass Assignment

Mass assignment is a computer vulnerability where an active record pattern in a web application is exploited to modify data items that the user is not authorised for doing so. Review the API implementation, see the code and make sure that it is not just blindly converting incoming JSON payloads into objects and writing them to the database. Make sure that you strictly define schemas of API call payloads. Any calls with payloads that do not match the schema should get rejected.

Mitigation:

  • Precisely define the schemas, types, and patterns you will accept in requests at design time and enforce at runtime.
  • Do not automatically bind incoming data and internal objects into the JSON data.
  • Explicitly define all the parameters and payloads which the server is expecting.

7. Security Misconfiguration

Poorly configured components will reveal information about systems information like server versions, database names, and exceptions which contains sensitive data that are useful for attackers to exploit.

Mitigation:

  • Configure the webserver to remove the server information, prepare a custom error page that doesn’t disclose any sensitive information related to the webserver.
  • Establish repeatable hardening and patching processes.

8. Injection

Injection flaws, such as SQL, NoSQL, Command Injection, etc occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter in executing unintended commands or accessing data without proper authorizations.

Mitigation:

  • Strictly define all input data, such as schemas, types, and string patterns and enforce them at runtime.
  • Validate, filter and sanitize all incoming data.
  • Limit and enforce API outputs to prevent data leaks.

9. Improper Assets Management

If the application is running in multiple environments like Staging, Beta, Production, etc., and if using the same database then attackers will launch their attacks using non-production versions of the API and gain access to the production site. Old or non-production versions are not properly maintained, but these endpoints still have access to production data.

Mitigation:

  • Limit access to production data, and segregate access to production and non-production data.
  • Limit access to anything that should not be public.
  • Keep an up-to-date inventory of all API hosts.
  • Implement additional external controls, such as API firewalls.

10. Insufficient Logging & Monitoring

Insufficient logging and monitoring occur when the security-critical events aren’t logged properly, and if the system is not monitoring the current happenings. Lack of these functionalities can make malicious activities harder to detect and it affects effective incident handling when an attack happens.

Mitigation:

  • Log failed attempts, denied access, input validation failures, or any failures in security policy checks.
  • Ensure that logs are recorded.
  • Protect logs like highly sensitive information.
  • Avoid having sensitive data in logs.

Reference Links:

https://apisecurity.io/

https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Main