← Cloudflare RLSCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Cloudflare RLS
Snapshot Sep 30, 2026 · 23:17 UTC · version 0.1.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "cloudflare-security-boundaries",
"description": "Assess tenant isolation across Cloudflare identity, storage, caching, and asynchronous execution boundaries.",
"included_files": [],
"skill_md_contents": "---\nname: cloudflare-security-boundaries\ndescription: Assess tenant isolation across Cloudflare identity, storage, caching, and asynchronous execution boundaries.\n---\n# Cloudflare security boundaries\n\nApply when an application spans multiple Cloudflare products or when the data path is outside a direct D1/Hyperdrive review.\n\n## Inputs\n\nUse only relevant code/configuration and user-provided architecture: identity provider, Access/JWT validation, bindings, routes, storage keys, cache rules, object ownership, queues/jobs, and environment layout.\n\n## Review workflow\n\n1. Draw the path from request identity through authorization to each storage read/write and response.\n2. Verify Access/JWT validation at the Worker boundary where applicable, then separately verify object/row authorization. Access is not proof of ownership.\n3. R2: check object-key ownership, upload/download authorization, signed URL scope and expiry, overwrite behavior, and whether bearer URLs leak through logs/referrers.\n4. KV: check tenant-scoped key design, namespace/binding exposure, consistency assumptions, and authorization on reads/writes; do not treat an unguessable key as the only access control.\n5. Durable Objects: ensure caller authorization before forwarding requests or invoking storage operations; validate object identifiers and tenant ownership on every path.\n6. Vectorize/AI Search: derive namespaces and metadata filters from authenticated server-side identity; treat filtering as data selection, not as a complete authorization boundary.\n7. Cache/CDN: verify tenant/auth context cannot collide across cache keys; bypass or explicitly scope caching for personalized responses and test cache hit/miss sequences across users.\n8. Queues, Workflows, scheduled jobs, and retries: preserve and validate tenant context, authorize job creation, constrain payload-controlled resource IDs, and prevent one tenant's output from reaching another.\n9. Review bindings and secrets for least privilege and environment separation. Never ask the user to disclose secret contents.\n\n## Output contract\n\nMap each finding to the specific boundary, evidence, attacker-controlled input, possible cross-tenant consequence, recommended control, and reproducible negative test. Mark uninspected products as out of scope.\n\n## Boundaries\n\nDo not infer that a product provides row-level policy enforcement unless official documentation supports it. Keep recommendations product-specific and current; for uncertain or version-sensitive behavior, consult official Cloudflare documentation. No deployment or account mutation without explicit scope and authorization.\n"
}SHA-256: 7fa3f4c0baf7fb26163daf4ab440998fe179d690d11bc60c1397268e9e107dce