# Draconian Rls Audit

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

- Skill: `majiayu000/draconian-rls-audit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/draconian-rls-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/draconian-rls-audit/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/majiayu000/draconian-rls-audit

---


# 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?