{"id":23837,"plugin_id":"plugins_6ab3635840688191834661e7fb05e07b","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:17:48.433Z","digest":"8aaa69e549519b605ada78c01c8ef15888b35c1c2ce0c98b6a23210a66fbebdc","against":null,"payload":{"description":"Review tenant and row authorization in Cloudflare Workers and D1 applications.","included_files":[],"name":"d1-workers-isolation","skill_md_contents":"---\nname: d1-workers-isolation\ndescription: Review tenant and row authorization in Cloudflare Workers and D1 applications.\n---\n# D1 and Workers isolation\n\nApply when a Cloudflare Worker or Pages Function reads or writes D1 data, particularly for multi-tenant applications.\n\n## Inputs\n\nPrefer the relevant handlers, middleware/authentication code, schema and migrations, query helpers, Wrangler bindings/environments, and tests. If these are absent, give a general checklist and identify the evidence gap.\n\n## Process\n\n1. State that D1 is SQLite-based and does not provide PostgreSQL-style native RLS policies; do not suggest a D1 `CREATE POLICY` switch.\n2. Trace the authenticated principal from verification to a server-derived tenant/user identity. Never trust a client-supplied tenant/user ID as authorization evidence.\n3. Inspect every read and write path: direct lookup, update/delete, nested resources, joins, lists, pagination, search, aggregates, exports, bulk operations, and alternate endpoints.\n4. Verify tenant predicates are applied in the data operation and that updates/deletes constrain both object identity and authorized owner/tenant. Use prepared/bound SQL values for injection resistance, while explaining that parameterization does not provide authorization.\n5. Review schema constraints and indexes that support ownership invariants; verify creation and ownership transfer paths cannot assign arbitrary tenants.\n6. Review environment separation and bindings; prefer preview/local D1 for development and ensure production data is not accidentally selected.\n7. Produce attack-focused negative tests and positive controls.\n\n## Output\n\nReport each finding with file/route/query evidence, severity, cross-tenant impact, confidence, minimal remediation, and a test that should fail before the fix and pass after it.\n\n## Boundaries\n\nDo not call a D1 app secure based only on prepared statements, authentication middleware, or a binding. Do not assume complete route coverage from a partial sample. Do not run queries or migrations against live data unless separately and explicitly authorized.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}