← Lessons

quiz vs the machine

Gold1400

Security

API Authorization Checks

Why authenticating a caller is not enough and how to verify they may act.

5 min read · core · beat Gold to climb

The Risk

Authentication proves who is calling. Authorization decides what that caller may do. A common and severe API bug is to authenticate a user but then trust an identifier in the request to pick the data, without checking ownership. An attacker simply changes the id to read or modify another user record. This is often called a broken object level authorization flaw.

The danger is assuming a logged in user only sends ids that belong to them.

The Defense

  • Check ownership and permission on every object access, comparing the resource owner to the authenticated caller on the server.
  • Do not rely on hidden fields, guessable ids, or the client to scope data.
  • Apply checks at the data access layer so no endpoint can forget them.
  • Enforce function level authorization so only allowed roles reach sensitive actions.
  • Test by trying another users identifiers with a valid session.

Key idea

Verify on the server that the authenticated caller owns or may access each object, since authentication alone never confirms authorization.

Check yourself

Answer to earn rating on the learn ladder.

1. What does broken object level authorization allow?

2. Where should authorization be enforced?

3. Why is authentication alone insufficient?