Authorization on a list endpoint is easy to get half-right.
You scope page 1 with a tenant or ownership filter — then page 2, a cursor, or "load more" runs a query that drops that filter. Attackers love opaque cursors that encode only created_at and id.
Bind the same authorization predicate into every page request. If you put filters in the cursor, sign them. Re-evaluate who the caller is allowed to see on each page — do not trust the client to keep sending the right scope.
Top comments (1)
The cursor-based pagination in this auth example feels risky because attackers could manipulate the cursor to skip authorization checks. I noticed the article mentions using the same authorization predicate across pages but doesn't clarify how the server validates the cursor's origin. For a real app, I'd want to ensure the cursor itself includes a signed token that the server can verify against the user's session - otherwise, the 'load more' button might expose data from other users.