Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Yes. Every request for a page of protected data needs an authorization check before the server returns results. A page number is only a pagination parameter; it does not grant access to the records on that page. OWASP recommends checking permissions on every request and for the specific object or functionality being accessed (OWASP Authorization Cheat Sheet).

Why page 2 needs authorization too

Authentication identifies a user; it does not establish that the user may see every item in a list. Authorization depends on the authenticated subject, the requested action, the resource and relevant context. Because a paginated request retrieves protected data just like the first-page request, the server must apply the applicable policy on page 2 and every subsequent request.

This is an application of OWASP’s general every-request guidance, not a pagination-specific rule prescribing one universal filter implementation. The right mechanism depends on the authorization service and its integration with the data store.

Ways to restrict a collection to authorized records

OWASP describes several approaches to collection access. Choose one that preserves the policy’s semantics and ensures that unauthorized candidate records do not reach the caller.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Pattern How it works Key consideration
Per-candidate checks Retrieve a bounded candidate set, then check access for each item individually or in a batch before returning any results. Keep candidate data inside trusted services until checks finish; account for the cost of checking items.
Authorized identifiers Ask the policy decision point which identifiers the subject may access, then restrict data retrieval to those IDs. Keep tenant and business predicates in the query. The returned ID set may be incomplete if the service imposes a deadline or result limit.
Authorization query filter Apply an authorization predicate or query plan through a maintained adapter for the relevant policy decision point and data store. Confirm that the adapter supports the exact integration and that the restriction is applied consistently to every relevant output path.

These patterns are not interchangeable in every system. In particular, an authorized-ID response may be truncated. An API can return an explicitly partial subset if it guarantees that every returned item is allowed, but it must not describe that subset as the complete authorized set. An empty or incomplete policy result is not a reason to drop the filter.

Combine authorization with tenant and application restrictions

Apply authorization restrictions together with the application’s business rules and tenant boundaries. In a query, these restrictions should be intersected—logically ANDed—so that a permissive authorization result cannot override the tenant or business scope. Bind values as parameters, and allow-list structural filter choices such as fields and operators rather than accepting arbitrary query structure.

If the policy denies access, return no protected data. If it allows access, retain the other application and tenant restrictions. If a policy result is incomplete, preserve the restriction and handle the result as partial or fail closed according to the API’s documented behavior; never treat missing decisions as permission to return unfiltered records.

Apply the same protection to every output path

Visible page rows are not the only way a list can disclose protected information. Counts, search results, exports and aggregates can reveal records or facts about them, so apply relevant authorization and tenant restrictions to those paths as well. Ensure the pagination query, count query and any export or aggregate query have consistent access constraints.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

A successful list response also does not automatically authorize a later operation on an item. Recheck access for a direct object read, update or delete when that operation is requested, and account for changes in authorization or resource state. OWASP API1:2019 specifically addresses object-level authorization for endpoints that receive an object ID and act on it; that reference is edition-specific guidance, not the current OWASP API Top 10 edition (OWASP API1:2019 Broken Object Level Authorization).

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Implementation checks

  • Authorize every paginated request, not just the initial list request.
  • Ensure all returned candidates have passed the applicable object or collection policy before leaving trusted services.
  • Keep tenant and business predicates active regardless of whether the policy decision allows or denies access.
  • Define whether policy results can be truncated and whether the API can report a partial result without implying completeness.
  • Apply the relevant restrictions to rows, counts, search, exports and aggregates.
  • Perform a fresh authorization check for later direct reads or mutations as appropriate to the operation and current state.

For broader guidance on collection filtering and output handling, see OWASP’s Authorization Decisions and Output Handling Cheat Sheet.

Quick Recap

Rank #4
API Security in Action
  • API Security in Action
  • Manning Publications
  • ABIS BOOK

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.