Pagination abuse

What it means

Pagination splits a long list into pages, so a client asks for the next fifty records rather than all of them at once. Pagination abuse is using that mechanism to take far more than intended, either by asking for a huge page or by looping through every page.

A page size, an offset or a cursor is only a request parameter. If the server accepts limit=1000000, or lets a single account step through the whole table, the paging has not limited anything. What counts is whether the server enforces the limit on its side.

Why it matters

Bulk reads are how a small flaw becomes a data breach. One missing check on a single record is a problem. The same check missing on a list that can be walked end to end is your entire customer table in one afternoon. The cost is also server load, which can slow everyone else down.

It combines badly with weak access rules. A list endpoint that skips the ownership check returns other people's records, and paging hands them over neatly in order. See also resource consumption. Weak list endpoints are among the quickest ways to move a lot of data.

How it shows up

You meet it in list and search endpoints, exports, admin tables and any infinite scroll. Typical mistakes are no maximum page size, sequential offsets that make it easy to count and walk everything, a total count that reveals how much there is, and no limit on how fast pages can be fetched.

Fix it on the server. Set a hard upper limit on page size, prefer opaque cursors to raw offsets, filter every page by what the caller may see, and apply rate limits per account. Test by asking for oversized pages and by walking a list from a low-privilege account.