Skip to content

API security

OAuth scope enforcement: verify permissions on API operations

Use narrowly scoped test tokens to verify API operations enforce granted permissions and distinguish scopes from object-level authorization.

By BugSnaps · Updated

Add BugSnaps as a preferred source on Google(opens in a new tab)

Want more of our security guides? Select BugSnaps and confirm your choice on Google.

Direct answer

A token's scopes describe granted permissions, but the resource server must enforce the relevant permission on each operation. Scope checks must also be combined with authorization for the specific object and caller.

Write an operation-to-permission matrix

For each owned test endpoint, record the caller type, required scope, resource owner and expected response. Include read, update, export and administrative operations separately. Verify whether scopes represent user consent, application permission or another provider-defined concept.

Reference: OWASP OAuth 2.0 Cheat Sheet.

Use distinct test grants

Issue an authorized token with the required scope and a second token without it, both otherwise valid for the same API. Call a harmless operation with each and compare the observed response and state. Avoid changing signed claims locally; that would mostly test signature validation.

  • Record the permission represented by each test grant.
  • Use controlled accounts and objects with known ownership.
  • Inspect bulk and alternate-version operations within scope.

Test the object boundary

With the required scope present, verify that account A cannot read or modify account B's private test object unless policy allows it. A broad read scope may permit a class of operation without granting access to every customer's records.

Review corrections and clients

When an endpoint fails the matrix, place enforcement at the trusted resource boundary and review related routes. Retest the permitted case and the missing-scope case, then validate legitimate client workflows so a fix does not accidentally remove expected access.

Assessment limits

Scope semantics differ across providers. A tested token and route do not establish enforcement for all grants, service accounts or object-sharing policies.

Frequently asked questions

Can a token have the right scope and still lack access?

Yes. Object ownership, tenant membership, role and current policy may independently deny an operation.

Why not simply remove a scope from a signed JWT?

Editing a signed token invalidates its signature. Obtain a separately issued test token with the desired scope to isolate authorization behavior.

Primary sources and further reading

These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.

This guide was prepared with AI assistance using the linked sources and illustrative examples. Check current vendor guidance and your environment before making changes.

Apply the guide to your own assessment.

Start with an authorized target, known test data, and a clear scope. Use the report's evidence and coverage limits to decide which checks need further review.

Open MyPentest