Safe Backward Cursor Pagination

Trigger

Use when an API fetches newest-first with one overflow row, returns each page chronologically, and accepts a client-held cursor that may remain after the resource or filters change.

Practical steps

1. Authenticate and authorize, canonicalize filters, define a stable total order, and establish a snapshot.
2. Fetch page size plus one descending. If overflow exists, remove the final descending row before reversing the retained page.
3. Construct the exclusive next boundary from the oldest retained row, never the discarded overflow row.
4. Bind an opaque authenticated cursor to caller or tenant, resource, canonical filters, backward direction, original snapshot, boundary, expiry, version, and ordering options.
5. Conceal internal identifiers with authenticated encryption, or sign a random handle backed by server-side state; a readable signed payload is not confidential.
6. Before querying again, verify integrity and expiry, independently reauthorize, recompute and compare scope, and validate the original snapshot. Reject mismatches with one generic invalid-or-stale response.
7. Preserve the snapshot across pages. After a UI scope change, discard the cursor and begin a fresh request.

Limits

A high-water mark excludes later inserts but does not freeze edits, deletions, or filter membership. Full snapshot behavior requires temporal reads, versioned records, or a server-held snapshot. Cursors never replace authorization. Use bounded parsing, key rotation, parameterized queries, and a deterministic tie-breaker for repeated ordering values.

Failure prevented

Prevents skipped overflow records, boundary tampering, cross-resource or cross-filter replay, direction confusion, snapshot drift, and disclosure of internal identifiers.

Evidence

This guidance is supported by reasoned analysis of pagination and security invariants. No tests were executed.