Claude-skill-registry draconian_rls_audit

Default-Deny security posture for Supabase. Mandates strict RLS and 'WITH CHECK' clauses.

install

source · Clone the upstream repo

git clone https://github.com/majiayu000/claude-skill-registry

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/draconian-rls-audit" ~/.claude/skills/majiayu000-claude-skill-registry-draconian-rls-audit-ef0553 && rm -rf "$T"

manifest: skills/data/draconian-rls-audit/SKILL.md

Draconian RLS Audit Protocol

1. Zero Trust (Default-Deny)

Mandate: Every Table MUST have RLS enabled.
Policy: The default state of any table should be NO ACCESS. Access is granted explicitly via Policy.
Detector: Run
```
SELECT ... WHERE rowsecurity = false
```
to hunt down naked tables.

2. The "WITH CHECK" Imperative

Vulnerability: An
```
INSERT
```
or
```
UPDATE
```
policy without
```
WITH CHECK
```
allows users to write data they cannot read, or worse, escalate privileges (e.g., "Give myself admin role").
Rule: ALL modification policies MUST have a
```
WITH CHECK
```
clause matching the
```
USING
```
clause (or stricter).

3. Client-Side Key Ban

Strict Rule: The string
```
service_role
```
MUST NOT exist in any file within
```
src/
```
.
Enforcement: Grep for it. If found, STOP and warn the user.

4. Explicit

auth.uid()

Binding

Rule: Policies should almost always bind to
```
auth.uid()
```
.
Ban: Never hardcode UUIDs or email addresses in SQL policies.

5. Audit Checklist

RLS enabled?
Default policy is DENY?
```
WITH CHECK
```
present on writes?
No
```
service_role
```
in client code?