+91 9116117170

OWASP API Top 10 | Cyberops


By Aditya Chauhan 0 Comment May 28, 2022

Mitigating OWASP API Security Top 10 Risks with Ping Identity

API1:2019 — Broken object-level authorization

Attackers replace their resource ID in an API call with another user’s resource ID. The lack of proper authorization checks allows attackers to gain access to the resource. This attack is also known as IDOR.

Use case

  • The sequence of API calls uses the ID of the resource available to the API /api/user1/profile_info.
  • Attackers replace the IDs of their resources with a different one which they guessed through /api/user2/profile_info.
  • The API does not check permissions and lets the call through.
  • Problems are exacerbated when IDs can be named /api/123/profile_info.

How to Mitigate

  • Create a policy monitor with user policy and history.
  • The customer ID is now sent. In this case, use the saved ID in any session.
  • Verify that each client requests permission to access the database.
  • Use neglected random IDs (UUIDs).

API2:2019 — Broken Authentication

API authentication is a complex and confusing process. Programmers and security engineers may have a misunderstanding about authentication boundaries and how to properly use them. In addition, surveillance is an easy task for intruders, because everyone reveals it. Here are two things that help make this process a reality.

Use case

  • Unprotected APIs that are considered “internal”
  • Weak authentication that does not follow industry best practices
  • Weak API keys that are not rotated
  • Passwords that are weak, plain text, encrypted, poorly hashed, shared, or default passwords
  • Authentication susceptible to brute force attacks and credential stuffing
  • Credentials and keys included in URLs
  • Lack of access token validation (including JWT validation)
  • Unsigned or weakly signed non-expiring JWTs

How to Mitigate

  • Test all possible validation methods for all APIs.
  • Password reset APIs and one-time links also provide user authentication and should be equally secure.
  • Implement standard authentication, token generation, password storage, and multi-factor authentication.
  • Use temporary tokens.
  • Authenticate your applications
  • Use a strict rate limit for authentication, as well as flexible settings for blocking and checking passwords.

API3:2019 — Excessive data exposure

The API would show much more information than the client legitimately needs, relying on the client to do the filtering. If attackers go directly to the API, they have all the information.

Use case

  • API provides all data objects when stored in the backend database.
  • The client program filters the answers and displays only the information that the user needs to see.
  • Attackers call APIs directly and get confidential information that can be UI filtered.

How to Mitigate

  • Never trust a customer to filter information!
  • Review all API responses and compare them to what API customers really need.
  • Define schemes for all API profits.
  • Do not forget the wrong answers and explain the correct diagrams.
  • Identify and evaluate sensitive information or Personal Identifiable Information (PII).
  • Perform recovery checks to prevent accidental leaks or abnormalities.

API4:2019 — Lack of resources and rate-limiting

The API is not protected from large calls or payload sizes. Attackers can use it for authentication errors such as Denial of Service (DoS) and Brute Force Attacks.

Use case

  • Attackers overload the API by making more requests than they can handle.
  • Attackers send requests at speeds that exceed the processing speed of the API and are intercepted.
  • The request size or some fields are larger than the API can handle.
  • “Zip bombs” are archives with intensive resources for unpacking and overuse of the API.

How to Mitigate

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

API5:2019 — Broken function-level authorization

The API depends on the client to use the API at the user or administrator level. as appropriate The attacker found a way to “hide” the API admin and run it directly. There are no permissions for management methods that anyone can authorize.

Use case

  • Some administrative functions are exposed as APIs.
  • Non-privileged users can access these functions without authorization if they have the know-how.
  • Can be a matter of knowing the URL, or using a different verb or a parameter:
  • /api/users/v1/user/myinfo
  • /api/admins/v1/users/all

How to Mitigate

  • 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.

API6:2019 — Mass assignment

The API takes data that the client provides and stores it without proper filtering for whitelisted properties. Attackers can try to guess object properties or provide additional object properties in their requests, read the documentation, or check out API endpoints for clues where to find the openings to modify properties they are not supposed to on the data objects stored in the backend.

Use case

  • The API works with the data structures without proper filtering.
  • Received payload is blindly transformed into an object and stored.


              var user = new User(req.body);



              @user =[:user])

  • Attackers can guess the fields by looking at the GET request data.

How to Mitigate

  • Do not automatically bind incoming data and internal objects.
  • Explicitly define all the parameters and payloads you are expecting.
  • Use the read Only 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.

API7:2019 — Security misconfiguration

Poor configuration of the API servers allows attackers to exploit them.

Use case

  • Unpatched systems
  • Unprotected files and directories
  • Unhardened images
  • Missing, outdated, or misconfigured TLS
  • Exposed storage or server management panels
  • Missing CORS policy or security headers
  • Error messages with stack traces
  • Unnecessary features enabled

How to Mitigate

  • Establish repeatable hardening and patching processes.
  • Automate locating configuration flaws.
  • Disable unnecessary features.
  • Restrict administrative access.
  • Define and enforce all outputs, including errors.

API8:2019 — Injection

Attackers construct API calls that include SQL, NoSQL, LDAP, OS, or other commands that the API or the backend behind it blindly executes.

Use cases

Attackers send malicious input to be forwarded to an internal interpreter:

  • SQL
  • NoSQL
  • LDAP
  • OS commands
  • XML parsers
  • Object-Relational Mapping (ORM)

How to Mitigate

  • 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.

API9:2019 — Improper assets management

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.

Use case

  • DevOps, the cloud, containers, and Kubernetes make having multiple deployments easy (for example, dev, test, branches, staging, old versions).
  • Desire to maintain backward compatibility forces to leave old APIs running.
  • Old or non-production versions are not properly maintained, but these endpoints still have access to production data.
  • Once authenticated with one endpoint, attackers may switch to the other, the production one.

How to Mitigate

  • Keep an up-to-date inventory of 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.

API10:2019 — Insufficient logging and monitoring

Lack of proper logging, monitoring, and alerting allows attacks and attackers to go unnoticed.

Use case

  • Logs are not protected for integrity.
  • Logs are not integrated into Security Information and Event Management (SIEM) systems.
  • Logs and alerts are poorly designed.
  • Companies rely on manual rather than automated systems.

How to prevent

  • 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.