GitHub - greyrow/rls-guard · GitHub
/" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
/;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
greyrow
rls-guard
Public
Uh oh!
There was an error while loading. Please reload this page.
Notifications<br>You must be signed in to change notification settings
Fork
Star
main
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>2 Commits<br>2 Commits
.github
.github
spec
spec
src
src
.env.example
.env.example
.gitignore
.gitignore
LICENSE
LICENSE
PLAN.md
PLAN.md
README.md
README.md
package-lock.json
package-lock.json
package.json
package.json
tsconfig.json
tsconfig.json
View all files
Repository files navigation
rls-guard
Design-time and audit agent for Postgres/Supabase row-level security, CRUD permissions,<br>and cascade-delete rules . Write down who can select/insert/update/delete what, in plain<br>YAML — rls-guard turns it into real SQL, and checks your live database against it.
Why
Misconfigured Row Level Security is currently one of the most common real-world data<br>exposure bugs in Postgres/Supabase-backed apps. In one 2025 disclosure (CVE-2025-48757),<br>303 endpoints across 170 apps were found fully readable by anyone holding the public<br>anon key, because RLS was off or misconfigured. This happens because RLS policies are<br>easy to get subtly wrong and easy to forget entirely as a schema grows — especially in<br>fast-moving, AI-assisted app builds.
rls-guard exists so that:
You describe your permission model once, in a format a non-DBA can read and review.
rls-guard generate turns that into an actual SQL migration (policies + cascade rules).
rls-guard audit checks a live database against the spec and flags drift — RLS<br>disabled, overly permissive policies, cascade behavior that doesn't match intent.
Status
v0.1 — early scaffold. The core loop (spec → generate SQL, live DB → audit) works.<br>Not yet battle-tested; review generated SQL before applying it to anything real. See<br>PLAN.md for what's next.
Install (local dev, not yet published)
npm install<br>cp .env.example .env # fill in ANTHROPIC_API_KEY and DATABASE_URL<br>npm run build
Usage
Generate a migration from a spec (works with or without a live DB connection):
npx tsx src/index.ts generate --spec spec/example.spec.yaml --out rls-guard.generated.sql<br>npx tsx src/index.ts generate --spec spec/example.spec.yaml --db $DATABASE_URL --out rls-guard.generated.sql
Audit a live database — fast deterministic checks always run; add --spec to also get a<br>Claude-written comparison against your intended permission model:
npx tsx src/index.ts audit --db $DATABASE_URL<br>npx tsx src/index.ts audit --db $DATABASE_URL --spec spec/example.spec.yaml
See spec/example.spec.yaml for the spec format: roles, per-table CRUD rules, and<br>cascade-delete behavior (cascade / restrict / set_null).
How it's different
Most existing tools here are either general-purpose policy engines you write yourself<br>(Open Policy Agent), heavyweight enterprise DB-access platforms, or external scanners<br>that probe a live app from outside without knowing what access was actually supposed<br>to look like. rls-guard starts from your intended design (the spec) and both generates<br>the implementation and checks reality against that intent — closer to a linter + codegen<br>tool than a black-box scanner.
Roadmap / where this is going
CI mode: fail a PR/build when a new table has no RLS policy or a cascade rule drifts<br>from spec (this is the planned paid tier — see below).
Prisma/Drizzle schema readers, not just live Postgres introspection.
Generated test suite (not just SQL) that proves unauthorized access actually fails.
Policy diffing between spec versions for change review.
License / monetization model
Core CLI is MIT-licensed and will stay free. The plan is an open-core model: a hosted<br>CI gate + PR bot + compliance report generation as a paid tier on top of this free,<br>inspectable core. GitHub Sponsors is on from day one regardless.
Contributing
Early days — open an issue before a large PR. See PLAN.md for the current build plan.
About<br>No description, website, or topics...