Secure backward cursor pagination

Trigger

Use when an API queries older messages in descending keyset order, presents each page chronologically, and accepts a user-controlled cursor that may survive a conversation or filter change.

Practical steps

1. Choose an immutable total order; add a unique tie-breaker when sequence alone is not unique. Authenticate the caller, authorize the conversation selected by the current request, and canonicalize every effective filter and authorization scope. The cursor must never select that scope.
2. On the first page, fix a high-water snapshot. Query within it in descending order for page size plus one rows, applying any exclusive older-than position. If an extra row exists, discard the last descending row before reversing the retained rows.
3. Return the retained rows chronologically. When overflow exists, set the next exclusive position to the oldest retained row, not the discarded lookahead row. Preserve the original snapshot on later pages.
4. Issue a MAC-protected random handle that resolves to server-side cursor state bound to purpose, version, caller or authorization scope, conversation, canonical filters, direction, sort definition, snapshot, position, page size if fixed, and expiry. A readable signed payload provides integrity but not secrecy; use an opaque handle or authenticated encryption to avoid exposing internal identifiers.
5. On continuation, verify authenticity and expiry, independently authorize the currently requested conversation, and compare its effective bindings with the saved state before querying. Enforce authorization in the row fetch or an equivalent atomic boundary so revocation between a preliminary check and the fetch cannot expose rows.
6. Reject tampering, expiry, or any binding mismatch with the same generic invalid-cursor response. Do not echo decoded state, identifiers, or mismatch details. A client may clear a stale cursor when scope changes, but server validation remains required.

Limits

A high-water mark excludes later appends but does not freeze edits, deletions, backdated inserts, or changing filter membership. Strict repeatability needs immutable or versioned records, a materialized result set, or durable database-snapshot semantics. Token retention, key rotation, replay policy, and expiry are deployment choices. This guidance is reasoned analysis, including an independent reasoning check, not executed tests.

Failure prevented

Avoids skipped overflow rows, duplicate or missing pages, cross-conversation or cross-filter reuse, direction or snapshot confusion, tampered positions, internal-identifier disclosure, and authorization-revocation races.