OWASP API Security Top 10

Definition

API: stands for Application Programming Interface her the application refers to any script that has logic and the interface stands for the contract of communication between the applications

Vulnerabilities

1. Broken Object Level Authorization (BOLA)

   1. This vulnerability refers to IDOR vulnerability that the user uses the input field to access unauthorized data

   2. Mitigation:

      • An authorisation mechanism that relies on user policies and hierarchies should be adequately implemented. 
      • Strict access controls methods to check if the logged-in user is authorised to perform specific actions. 
      • Promote using completely random values (strong encryption and decryption mechanism) for nearly impossible-to-predict tokens.

2. Broken User Authentication (BUA)

   1. That the implemented authentication logic is broken or easily bypassed by the attacker

   2. Mitigation:

      • Ensure complex passwords with higher entropy for end users.
      • Do not expose sensitive credentials in GET or POST requests.
      • Enable strong JSON Web Tokens (JWT), authorisation headers etc.
      • Ensure the implementation of multifactor authentication (where possible), account lockout, or a captcha system to mitigate brute force against particular users. 
      • Ensure that passwords are not saved in plain text in the database to avoid further account takeover by the attacker.

3. Excessive Data Exposure

   1. The endpoint revels more data than than requested that could risk leaking sensitive data
   2. Mitigation:
      • Never leave sensitive data filtration tasks to the front-end developer. 
      • Ensure time-to-time review of the response from the API to guarantee it returns only legitimate data and checks if it poses any security issue. 
      • Avoid using generic methods such as to_string() and to_json(). 
      • Use API endpoint testing through various test cases and verify through automated and manual tests if the API leaks additional data.

4. Lack of Resources & Rate Limiting

   1. Lack of resources and rate limiting means that APIs do not enforce any restriction on the frequency of clients’ requested resources or the files’ size, which badly affects the API server performance and leads to the DoS (Denial of Service) or non-availability of service

   2. Mitigation:

      • Ensure using a captcha to avoid requests from automated scripts and bots.
      • Ensure implementation of a limit, i.e., how often a client can call an API within a specified time and notify instantly when the limit is exceeded. 
      • Ensure to define the maximum data size on all parameters and payloads, i.e., max string length and max number of array elements.

5. Broken Function Level Authorization

   1. Broken Function Level Authorization reflects a scenario where a low privileged user (e.g., sales) bypasses system checks and gets access to confidential data by impersonating a high privileged user (Admin).

   2. Mitigation:

      • Ensure proper design and testing of all authorisation systems and deny all access by default. 
      • Ensure that the operations are only allowed to the users belonging to the authorised group. 
      • Make sure to review API endpoints against flaws regarding functional level authorisation and keep in mind the apps and group hierarchy’s business logic.

6. Mass Assignment

   1. Mass assignment reflects a scenario where client-side data is automatically bound with server-side objects or class variables. However, hackers exploit the feature by first understanding the application’s business logic and sending specially crafted data to the server, acquiring administrative access or inserting tampered data. This functionality is widely exploited in the latest frameworks like Laravel, Code Ignitor etc.

   2. Mitigation:

      • Before using any framework, one must study how the backend insertions and updates are carried out. In the Laravel framework, fillable and guarded arrays mitigate the above-mentioned scenarios. 
      • Avoid using functions that bind an input from a client to code variables automatically.
      • Allowlist those properties only that need to get updated from the client side.

7. Security Misconfiguration

   1. Security misconfiguration depicts an implementation of incorrect and poorly configured security controls that put the security of the whole API at stake. Several factors can result in security misconfiguration, including improper/incomplete default configuration, publically accessible cloud storage, Cross-Origin Resource Sharing (CORS), and error messages displayed with sensitive data. Intruders can take advantage of these misconfigurations to perform detailed reconnaissance and get unauthorised access to the system. 

   2. Security misconfigurations are usually detected by vulnerability scanners or auditing tools and thus can be curtailed at the initial level. API documentation, a list of endpoints, error logs etc., must not be publically accessible to ensure safety against security misconfigurations. Typically, companies deploy security controls like web application firewalls, which are not configured to block undesired requests and attacks.

   3. Mitigation:

      • Limit access to the administrative interfaces for authorised users and disable them for other users. 
      • Disable default usernames and passwords for public-facing devices (routers, Web Application Firewall etc.).
      • Disable directory listing and set proper permissions for every file and folder. 
      • Remove unnecessary pieces of code snippets, error logs etc. and turn off debugging while the code is in production.

8. Injection

   1. Injection attacks are probably among the oldest API/web-based attacks and are still being carried out by hackers on real-world applications. Injection flaws occur when user input is not filtered and is directly processed by an API; thus enabling the attacker to perform unintended API actions without authorisation. An injection may come from Structure Query Language (SQL), operating system (OS) commands, Extensible Markup Language (XML) etc. Nowadays, frameworks offer functionality to protect against this attack through automatic sanitisation of data; however, applications built in custom frameworks like core PHP are still susceptible to such attacks.

   2. Mitigation:

      • Ensure to use a well-known library for client-side input validation.
      • If a framework is not used, all client-provided data must be validated first and then filtered and sanitized. 
      • Add necessary security rules to the Web Application Firewall (WAF). Most of the time, injection flaws can be mitigated at the network level.
      • Make use of built-in filters in frameworks like Laravel, Code Ignitor etc., to validate and filter data.

9. Improper Assets Management

   1. Inappropriate Asset Management refers to a scenario where we have two versions of an API available in our system; let’s name them APIv1 and APIv2. Everything is wholly switched to APIv2, but the previous version, APIv1, has not been deleted yet. Considering this, one might easily guess that the older version of the API, i.e., APIv1, doesn’t have the updated or the latest security features. Plenty of other obsolete features of APIv1 make it possible to find vulnerable scenarios, which may lead to data leakage and server takeover via a shared database amongst API versions.

   2. Mitigation:

      • Access to previously developed sensitive and deprecated API calls must be blocked at the network level.
      • APIs developed for R&D, QA, production etc., must be segregated and hosted on separate servers.
      • Ensure documentation of all API aspects, including authentication, redirects, errors, CORS policy, and rate limiting. 
      • Adopt open standards to generate documentation automatically.

10. Insufficient Logging & Monitoring

    1. Insufficient logging & monitoring reflects a scenario when an attacker conducts malicious activity on your server; however, when you try to track the hacker, there is not enough evidence available due to the absence of logging and monitoring mechanisms. Several organisations only focus on infrastructure logging like network events or server logging but lack API logging and monitoring. Information like the visitor’s IP address, endpoints accessed, input data etc., along with a timestamp, enables the identification of threat attack patterns. If logging mechanisms are not in place, it would be challenging to identify the attacker and their details. Nowadays, the latest web frameworks can automatically log requests at different levels like error, debug, info etc. These errors can be logged in a database or file or even passed to a SIEM solution for detailed analysis.

    2. Mitigation:

       • Ensure use of the Security Information and Event Management (SIEM) system for log management. 
       • Keep track of all denied accesses, failed authentication attempts, and input validation errors, using a format imported by SIEM and enough detail to identify the intruder.
       • Handle logs as sensitive data and ensure their integrity at rest and transit. Moreover, implement custom alerts to detect suspicious activities as well.