Use when auditing database access policies, implementing RLS in Supabase or Postgres, configuring Convex auth guards, setting up audit logging, reviewing database security, or validating database-level compliance requirements.
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Files included with this skill beyond the listing page.
skill mdSKILL.md8,950 B
docsSUMMARY.md549 B
History
First seen on skills.sh
First recorded snapshot · 159 installs
SKILL.md
Security Audit
Database security auditor specialized in Row Level Security (RLS) enforcement, Zero-Trust database architecture, and forensic audit trails. Focuses on Supabase, Postgres, and Convex data layer security. For general application security (OWASP Top 10, auth patterns, security headers, input validation), use the security skill instead.
Quick Reference
Need
Approach
RLS enforcement
Enable on every public table; separate policies per operation
RLS performance
Index RLS columns; wrap auth.uid() in (select ...) subselect
Follow this sequence when performing a database security audit:
Attack Surface Mapping: Identify all entry points to the data layer (public APIs, internal dashboards, AI agents, cron jobs)
RLS Coverage Check: Query pg_tables to verify every public schema table has RLS enabled and appropriate policies
Policy Review: Check for logical bypasses, missing WITH CHECK clauses, overly permissive FOR ALL policies
Service Role Audit: Search client code for service_role key exposure; verify it only appears in server-side code
Function Audit: Check for security definer functions in exposed schemas and Convex functions missing auth guards
Access Simulation: Execute queries as anon and authenticated roles to verify enforcement
View Audit: Verify views use security_invoker = true or are not in exposed schemas
Audit Trail Verification: Confirm triggers or PGAudit capture all security-relevant operations
Compliance Validation: Map database controls against applicable regulatory frameworks
Security Principles
Principle
Database Application
Defense in Depth
RLS + application checks + schema segmentation
Least Privilege
Minimal GRANT per role; anon gets near-zero access
Zero Trust
Verify identity at DB level even for internal requests
Secure by Default
RLS enabled on creation; default-deny when no policy
Fail Securely
Postgres default-deny on RLS; generic error responses
Assume Breach
Design assuming attacker has a valid JWT
Anti-Patterns
Anti-Pattern
Risk
Security by obscurity (UUIDs only)
Attackers enumerate IDs via IDOR
Anon role with SELECT on sensitive tables
Public data exposure via Supabase API
RLS columns without indexes
Production performance degradation (100x+)
Frontend-only permission checks
Attackers bypass via direct API calls
Standing admin privileges
Excessive blast radius if compromised
service_role key in client-side code
Bypasses all RLS policies completely
FOR ALL policies instead of per-operation
Unintended write access through broad rule
Security definer functions in public schema
Functions callable from API, bypass RLS
Views without security_invoker
Views bypass RLS silently
Common Mistakes
Mistake
Correct Pattern
Using auth.uid() = user_id without wrapping in (select ...)
Use (select auth.uid()) = user_id so Postgres caches the result via initPlan
Using FOR ALL instead of separate per-operation policies
Create separate SELECT, INSERT, UPDATE, DELETE policies for clarity and safety
Leaving anon role with SELECT on sensitive tables
Restrict anon access; require authenticated role for sensitive data
Relying on UUIDs as the only access control
Enforce RLS policies and explicit auth checks alongside unique identifiers
No index on columns used in RLS USING clauses
Add B-tree indexes on all columns referenced in RLS policy expressions
Convex function missing ctx.auth.getUserIdentity() call
Every public query and mutation must validate identity before accessing data
Using service_role key in client-side code
Use anon key client-side; service_role only in server-side functions
Views bypassing RLS without security_invoker
Set security_invoker = true on views in Postgres 15+
Security definer functions in exposed schemas
Place security definer functions in non-exposed schemas with search_path = ''
No audit logging for security-relevant database events
Use triggers and PGAudit to capture all data access and modifications
Relationship to Security Skill
The application-security skill covers general application security: OWASP Top 10, authentication patterns, input validation, security headers, and compliance overviews. This database-security skill complements it by focusing on database-layer concerns: RLS policy design and performance, Supabase/Postgres-specific patterns, Convex auth guards, PGAudit configuration, and database-specific compliance implementations (SQL functions for GDPR erasure, HIPAA PHI audit triggers, etc.).
Delegation
Verify RLS enforcement with access simulations: Use Task agent to run anonymous and authenticated queries against every public table
Audit Convex functions for missing auth guards: Use Explore agent to scan all query and mutation handlers for getUserIdentity calls
Design zero-trust database architecture: Use Plan agent to map schemas, access policies, JIT grants, and audit log design
Generate database compliance evidence: Use Task agent to run audit queries and produce compliance reports
