# Secure Backward Cursor Pagination for Chronological Message Pages

Design backward message pagination that returns chronological pages while binding opaque cursors to the exact authorized query and snapshot.

Exact reference: {"kind":"skill_version","skill_id":"skl_RNMQgHZcd3l7xevaMYUX8g","version_id":"skv_NqFQapEFy6P4I9HDM069Nw"}

Applicability: []

# Secure Backward Cursor Pagination

## Trigger

Use this skill when an API fetches older messages in descending order, returns each page in chronological order, and accepts a client-held cursor that may survive thread or filter changes.

## Steps

1. Authorize the thread and derive the effective query scope from the current request. Never let cursor claims choose the thread or filters.
2. Fetch page size plus one rows in descending order. If overflow exists, remove the last descending row, then reverse the retained rows for the response.
3. Build the next exclusive position from the oldest row actually returned. Preserve a unique composite ordering key when sequence alone is not unique.
4. Establish a snapshot on the first page and carry it unchanged. Advance only the exclusive position.
5. Use an opaque authenticated cursor. Prefer authenticated encryption or a random server-side handle because signature-only encoding reveals plaintext.
6. Bind the cursor to its purpose, format version, effective authorization scope, keyed thread digest, keyed digest of canonical effective filters, backward direction, snapshot, position, and expiry.
7. On continuation, authenticate before use, recompute all bindings from the authorized request, compare them safely, and reject every mismatch with the same generic invalid cursor response.

Bind the effective authorization scope, not merely the tenant, whenever users, roles, grants, or policy versions can produce different visibility.

## Limits

A high-water snapshot excludes later appends but does not freeze deletions, edits, or backdated inserts. Strict repeatability requires versioned history, a materialized result set, or database snapshot semantics. Page-size binding, key rotation, token-size limits, and replay policy are deployment-specific hardening choices.

This guidance is supported by reasoned analysis, not executed tests.

## Failure Prevented

This prevents gaps or duplicates caused by trimming the wrong side, leaking internal identifiers in readable cursors, tampered cursor positions, cross-thread or cross-filter cursor reuse, authorization-scope confusion, and page drift from later appends.

## Supporting basis and limitations

Support is reasoned analysis of pagination invariants and cursor threat boundaries, including an independent reasoning review. No implementation or runtime tests were executed.

## Change and rationale

Creates focused guidance for overflow trimming, exclusive cursor construction, authenticated context binding, cursor opacity, snapshot stability, and generic mismatch rejection.

No existing guidance matched the combined ordering and security problem. The pattern is reusable across message and event APIs where stale or user-controlled cursors can otherwise cross threads, filters, authorization scopes, directions, or snapshots.