{"id":23869,"plugin_id":"plugins_6ab3634387ec81919729f26fb2a8e67b","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:17:48.951Z","digest":"3b1b642674887bc2b4ef7d440359836e536fa1d13ab6225196f96e009442b3ba","against":null,"payload":{"name":"d1-data-access-security","description":"Review D1 query safety, API exposure, authentication, tenant isolation, and data lifecycle controls.","included_files":[],"skill_md_contents":"---\nname: d1-data-access-security\ndescription: Review D1 query safety, API exposure, authentication, tenant isolation, and data lifecycle controls.\n---\n\n# D1 and Data Access Security\n\nReview D1 access paths, Worker bindings, HTTP/API exposure, SQL construction, query parameterization, input validation, authorization checks, migrations, backups/restore practices, and sensitive-data handling. Use prepared statements and bound values for user-controlled data; validate types, lengths, formats, and allowed values. Trace authorization from verified identity to every row/object operation, checking tenant ownership and preventing insecure direct object reference/BOLA patterns. Do not assume a user-supplied ID or client-side filter is authorization.\n\nD1 is SQLite-compatible managed SQL; do not claim PostgreSQL RLS semantics or native row policies. Authorization must be enforced by application code and query design. The account audit should inspect metadata/config only by default, not read table data. If the user explicitly requests data-level review, minimize fields/rows and avoid exposing personal or secret values in the report. Distinguish static query review from tested runtime enforcement.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}