OWASP classification (API3:2023)

OWASP classifications per the page (header table): API Specific. Exploitability = Easy; Prevalence = Common; Detectability = Easy; Technical Impact = Moderate; Business Specific = application-specific. All five values verified against the original page.

How the attack works

APIs tend to return all properties of an object (especially with REST) or accept entire object payloads without performing an authorization check per property.

There are two variants:

  1. Reading, the API includes sensitive properties in the response that the user shouldn't be able to see (formerly "Excessive Data Exposure").
  2. Writing, the API automatically binds client input to internal object properties (e.g. via mass assignment/auto-binding), letting an attacker set, change, or add sensitive fields they shouldn't have access to (formerly "Mass Assignment").

Per OWASP, inspecting API responses is enough to identify sensitive information in the returned object representations; fuzzing is typically used to find additional (hidden) properties.

Whether these can be modified is a matter of crafting a manipulated request and analyzing the response. If the target property isn't included in the response, a side-effect analysis may be needed.

1. Starting pointAccess to your own object is allowed
→
2. AttackSend or read a hidden field, e.g. role or balance
→
3. ResultA property is changed or read that shouldn't have been allowed

Object access is correct, but individual fields are unprotected.

Example

Write attack (OWASP scenario #3, short-video platform with censorship): a user is legitimately allowed to change the description of their video, even while the video is already blocked.

  1. Legitimate request: PUT /api/video/update_video with { "description": "a funny video about cats" }
  2. The frustrated user repeats the request and adds an extra, internal property: PUT /api/video/update_video with { "description": "a funny video about cats", "blocked": false }
  3. Because the API doesn't check whether the user is allowed to modify the internal blocked property, the value is set from true to false, the user thereby lifts the block on their own, actually blocked content.

Wording and payloads exactly as on the OWASP page.

Impact

Unauthorized access to private/sensitive object properties can lead to data disclosure, data loss, or data corruption.

Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or to partial or full account takeover.

Concretely, in business terms, per the OWASP scenarios:

  • Scenario #1, other users' sensitive data such as fullName and recentLocation is disclosed.
  • Scenario #2, a guest is overcharged via the internal field total_stay_price, because the attacking host manipulates this price.
  • Scenario #3, blocked content is re-enabled via the blocked field.

How to protect against it

  • Whenever exposing an object via an API endpoint, always ensure that the user is actually allowed to access the returned properties.
  • Avoid generic methods like to_json() and to_string(); instead, deliberately select ('cherry-pick') only the properties that should actually be returned.
  • Where possible, avoid functions that automatically bind client input to code variables, internal objects, or object properties ('mass assignment').
  • Only allow changes to exactly the object properties the client is actually permitted to update.
  • As an additional layer of security, implement schema-based validation of responses: define and enforce the data returned by all API methods.
  • Limit returned data structures to the functional minimum actually needed.

Sources

Keep reading
OverviewOWASP API Security Top 10 API4Unrestricted Resource Consumption