OWASP classification (API5:2023)

Per the OWASP page: API Specific. Exploitability Easy; Prevalence Common; Detectability Easy; Technical Impact Severe; Business Impact: Specific (application-specific). All values confirmed against the official page.

How the attack works

Authorization checks for a function or resource are usually implemented via configuration or in code. Getting this right is error-prone, because modern applications have many roles, groups, and complex user hierarchies (e.g. sub-users or users with multiple roles).

While authentication answers "who am I", function-level authorization has to answer "am I allowed to perform this action", and it's exactly this check that's missing at individual endpoints in BFLA. Because APIs are structured and access to different functions is built predictably, such gaps are easier to discover and exploit.

Questions to test for, per OWASP:

  • Administrative endpoints: Can a regular user reach administrative endpoints?
  • Switching the HTTP method: Can a user trigger sensitive actions (create, change, delete) simply by switching the HTTP method (e.g. from GET to DELETE)?
  • Another group's function: Can a user from group X reach a function reserved for group Y by guessing the endpoint URL and parameters (e.g. /api/v1/users/export_all)?

A fallacy is classifying an endpoint as "regular" or "administrative" based on the URL path alone: administrative endpoints often live not just under /api/admins, but also alongside regular ones under /api/users.

1. Starting pointNormal user knows a privileged path
→
2. AttackCall an admin function, e.g. DELETE /users/{id}
→
3. ResultAction executed despite the missing role

A function is called that the role isn't entitled to.

Example

OWASP scenario 1 (invitation system with forced admin role):

  1. An application only allows invited users. During registration, the mobile app calls GET /api/invites/{invite_guid}. The response contains JSON with invitation details, including the user's role and email.
  2. The attacker duplicates the request and manipulates the HTTP method and endpoint to POST /api/invites/new. This endpoint should only be available to administrators via the admin console, and it doesn't implement function-level authorization.
  3. The attacker sends a new invitation with admin rights: POST /api/invites/new { "email": "attacker@somehost.com", "role": "admin" }
  4. Later, the attacker uses the manipulated invitation to create an admin account for themselves and gains full access to the system.

Impact

Such gaps let attackers access unauthorized functionality. Administrative functions are prime targets and can lead to data disclosure, data loss, or data corruption; ultimately this can lead to a service disruption (outage).

In the OWASP example, this gives the attacker full admin access to the entire system, from a business standpoint, potential loss of control over the application and its user data. Per OWASP, the business impact is application-specific.

How to protect against it

  • Provide a consistent, easily analyzable authorization module that's called from all business functions; this protection often lives in one or more components outside the application code.
  • Deny-all by default: the enforcement mechanism must deny every access by default and require explicit grants for specific roles per function.
  • Specifically test API endpoints for function-level authorization flaws, taking business logic and group hierarchy into account.
  • Ensure that all administrative controllers inherit from an abstract admin controller that implements authorization checks based on the user's group/role.
  • Ensure that administrative functions inside regular controllers implement authorization checks based on the user's group and role.

Sources

Keep reading
OverviewOWASP API Security Top 10 API6Unrestricted Access to Sensitive Business Flows