OWASP API TOP 10

The The OWASP API Security Top 10 Lists 10 unique vulnerabilities and security risks of APIs (Application Programming Interface) with strategies and solutions to mitigate that risks. These top 10 risks are as follows :  

Broken Object Level Authorization

  • Object level authorization is an access control mechanism which makes sure that one user can only access objects that they should have access to. The lack of proper authorization checks leads to unauthorized information disclosure, modification, or destruction of all data.
  • This class of vulnerability occurs when access control is not properly implemented on endpoints.
  • This class of vulnerability gives the access to attackers to the resources which they should not have to. For example IDOR vulnerability. For example IDOR vulnerability.  
https://api.example.com/vapi/user/1234
https://api.example.com/vapi/user/1235
https://api.example.com/vapi/user/1236

A user can access his details by above api endpoint, but if an attacker can change 1234 to 1235, and proper access control check is not implemented then he can access another user details.

Remediation

  • Implement authorization checks with user policies and hierarchy.  
  • Do not rely on IDs that the client sends. Use IDs stored in the session object instead.  
  • Check authorization for each client request to access database.  
  • Use random IDs that cannot be guessed (UUIDs).  
  • The checks should validate that the logged-in user does have access to perform the requested action on the requested object.

Broken Authentication  

Poorly implemented API authentication allows attacker to assume other user’s identities. For example:

  • Poor implementation of JWT
  • Sending authentications details on URLs (password, tokens),
  • Weak password implementation
  • Doesn’t validate authenticity of tokens
  • authentication susceptible to bruteforce attack

Remediation

  • Check all possible ways to authenticate to all APIs.    
  • APIs for password reset and one-time links also allow users to authenticate, and should be protected just as rigorously.   
  • Use standard authentication, token generation, password storage, and multi-factor authentication (MFA).    
  • Use short-lived access tokens.    
  • Authenticate your apps (so you know who is talking to you).    
  • Use stricter rate-limiting for authentication, and implement lockout policies and weak password checks.

Excessive Data Exposure

API exposes a lot more data then what the client legitimately needs, relying on the client to do the filtering.

Remediation

  • Never rely on the client to filter data!.  
  • Review all API responses and adapt them to match what the API consumers really need.
  • Carefully define schemas for all the API responses.  
  • Do not forget about error responses, define proper schemas as well.  
  • Identify all the sensitive data or Personally Identifiable Information (PII), and justify its use.  
  • Enforce response checks to prevent accidental leaks of data or exceptions.  
  • Avoid using generic methods such as to_json() and to_string(). Instead, cherry-pick specific properties you really want to return.
  • Be extra careful with sensitive data or PII.

Lack of resources and rate limiting

The api is not protected against an excessive amount of calls or payload sizes. Attacker can use this for dos attack or authentication flaws like bruteforce attacks.

Remediation

  • Define proper rate limiting.    
  • Limit payload sizes.  
  • Tailor the rate limiting to be match what API methods, clients, or addresses need or should be allowed to get.  
  • Add checks on compression ratios.  
  • Define limits for container resources.

Also look rate limiting on login forms.

Broken Function Level Authorization

  • Complex access with different hierarchies, groups and roles and an unclear separation between administrative and regular functions, tends to lead to authorization flaws.
  • By exploiting these issues, attackers gain access to other users resources and/or administrative functions.
  • For example by changing api/users to api/admin an attacker can access admin data.  

Remediation

  • Do not rely on the client to enforce admin access.  
  • Deny all access by default.  
  • Only allow operations to users belonging to the appropriate group or role.  
  • Properly design and test authorization.  

Mass Assignment

  • Binding client provided data to data models, without proper properties filtering, which usually leads to mass assignment.
  • The api takes data that client provides and store it without proper filtering for whitelisted properties.
var user = new User(req.body);
user.save();
  • The attacker can do this by guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, which allows attackers to modify object properties they are not supposed to.
  • For example in some cases the backend can just take all user provided data and write it to the database.
  • To avoid this vulnerability, precisely define the schemas, types, and patterns you will accept in requests at design time and enforce them at runtime.

Remediation

  • Do not automatically bind incoming data and internal objects.  
  • Explicitly define all the parameters and payloads you are expecting.  
  • Use the readOnly property set to true in object schemas for all properties that can be retrieved through APIs but should never be modified.  
  • Precisely define the schemas, types, and patterns you will accept in requests at design time and enforce them at runtime.    
  • Use built-in features to blacklist properties that should not be accessed by clients.  

Security Misconfiguration

Poor configurations or unsecure default configurations of API servers. For example:

  • Misconfigured HTTP headers
  • Unnecessary http methods enabled
  • Permissive or missing Cross-Origin resource sharing (CORS)
  • Missing, outdated, or misconfigured TLS
  • Pen cloud storage
  • Verbose error messages containing sensitive information
  • Exposed storage or server management panels
  • Unnecessary features enabled etc.

Remediation

  • Establish repeatable hardening and patching processes.  
  • Automate locating configuration flaws.  
  • Disable unnecessary features.  
  • Restrict administrative access.  
  • Define and enforce all outputs, including errors.  
  • A task to review and update configurations across the entire API stack. The review should include: orchestration files, API components, and cloud services (e.g., S3 bucket permissions).

Injection

  • Injection flaws occurs when untrusted data is send to an interpreter as a part of a command or query.
  • Attackers construct api calls that includes sql, no-sql, ldap, os commands, xml parsers, Object-Oriented mapping (ORM) that the API or the backend behind it blindly executes.

Some of the reasons these vulnerabilities occurs are :

  • Client-supplied data is not validated, filtered, or sanitized by the API.  
  • Client-supplied data is directly used or concatenated to SQL/NoSQL/LDAP queries, OS commands, XML parsers, and Object Relational Mapping (ORM)/Object Document Mapper (ODM).  
  • Data coming from external systems (e.g., integrated systems) is not validated, filtered, or sanitized by the API.

Remediation

  • Never trust your API consumers, even if they are internal.  
  • Strictly define all input data, such as schemas, types, and string patterns, and enforce them at runtime.  
  • Validate, filter, and sanitize all incoming data.
  • Define, limit, and enforce API outputs to prevent data leaks.  

Improper Assets Management

API tends to expose more endpoints then traditional web applications. Attackers find non-production versions of the API for example staging, testing, beta or earlier versions that are not as well protected as the production api and use those to launch their attacks.  

The API might be vulnerable if

  • The purpose of an API host is unclear, and there are no explicit answers to the following questions:  
    • Which environment is the API running in (e.g., production, staging, test, development)? 
    • Who should have network access to the API (e.g., public, internal, partners)? 
    • Which API version is running? 
    • What data is gathered and processed by the API (e.g., PII)? 
    • What’s the data flow?
  • There is no documentation, or the existing documentation is not updated.
  • There is no retirement plan for each API version.
  • Hosts inventory is missing or outdated.
  • Integrated services inventory, either first- or third-party, is missing or  outdated.
  • Old or previous API versions are running unpatched.

Remediation

  • Keep an up-to-date inventory all API hosts.  
  • Limit access to anything that should not be public.  
  • Limit access to production data, and segregate access to production and non-production data.  
  • Implement additional external controls, such as API firewalls.  
  • Properly retire old versions of APIs or backport security fixes to them.  
  • Implement strict authentication, redirects, CORS, and so forth.  

Insufficient Logging an Monitoring

Lack of proper Logging, monitoring and alerting allows attacks and attackers go un-noticed. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response allows attackers to further attack systems, maintain persistence, pivot to more system to temper with, extract or destroy data.  

Some examples are servers does not produce any logs, the logging level is not set correctly, or log messages do not include enough detail, Log integrity is not guaranteed (e.g., Log Injection), Logs are not continuously monitored, API infrastructure is not continuously monitored.

Remediation

  • Log failed attempts, denied access, input validation failures, or any failures in security policy checks.  
  • Ensure that logs are formatted so that other tools can consume them as well.  
  • Protect logs like highly sensitive information.  
  • Include enough detail to identify attackers.  
  • Avoid having sensitive data in logs — if you need the information for debugging purposes, redact it partially.  
  • Integrate with SIEMs and other dashboards, monitoring, and alerting tools.

References

  • https://apisecurity.io/encyclopedia/content/owasp/owasp-api-security-top-10    
  • https://owasp.org/www-project-api-security/  
  • https://www.youtube.com/watch?v=rPsmmNxo9W0    
  • https://www.slideshare.net/RajniHatti/practical-application-of-the-api-security-top-ten-a-testers-perspective