Repository navigation
test(supabase): check the sql security claims, then drop the header - #65
Merged
Merged
Conversation
PunGrumpy
added
the
refactor
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing: 2
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
commit: |
The install script declares security invoker on every function and enables row level security on the tables createIndex makes, but nothing failed if either stopped being true. A security definer function runs as its owner, and when that owner bypasses row level security, as a superuser or the table's owner does, anon reads every row through it. One test reads pg_proc and fails if any vecstore_ function is security definer, so a new function is covered without editing the test. A second test, run for anon and authenticated, calls query, fetch, upsert, and delete through the adapter against a secured table that has table grants and no policy. It expects empty reads, an unauthorized upsert, and a delete that removes nothing. The anon check before this read the table directly and never went through the vecstore_ functions. I saw both claims fail on purpose. Changing vecstore_fetch to security definer fails the catalog test and both role tests. Replacing the alter table statement that enables row level security fails both role tests and the two existing row level security tests.
The install command and the note that the script runs once per project are in the Supabase docs page and the README. The security model, that every function runs as the caller and that created tables have row level security with no policy, is in the "Which key to use" section of the same page. The previous commit made those two security sentences tests, so the comment no longer carries anything the docs and the suite do not.
PunGrumpy
force-pushed
the
test/supabase-sql-security-claims
branch
from
October 23, 2026 02:22
c788342 to
a909519
Compare
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
sql/supabase.sqlships in the npm package and opened with a seven-line comment. The repository keeps no comments in code, and every sentence of this one is already in the docs. The install command is on the Supabase page and in the README, and the security model is in that page's "Which key to use" section. Two of its sentences were security promises that no test checked:security invoker, but nothing failed if one becamesecurity definer. A definer function runs as its owner. When that owner bypasses row level security, as a superuser or the table's owner does,anonreads every row through it.select count(*)asanon. Writes, theauthenticatedrole, and the adapter's calls through thevecstore_*functions went unchecked.Summary
Two commits:
test(supabase): check that the sql functions honour row level security:vecstore_*function issecurity definer. A function added later is covered without editing the test.test.eachoveranonandauthenticatedrunsquery,fetch,upsert, anddeletethrough the adapter against a secured table that has table grants and no policy. It expects empty reads, anunauthorizedupsert, and a delete that removes nothing.asAnonhelper becomesasRole(role, fn).chore(sql): drop the header that repeats the supabase docsdeletes the comment and the blank line after it. No function body changes, so Supabase users do not need to re-run the file.No changeset. Users see no behavior change, and the gate counts only
src/andpackage.json.Verification
bun test --timeout 30000 test/postgres/supabase.test.ts: 26 pass (23 before).bun run testin the package: 636 pass, 0 fail.vecstore_fetchswitched tosecurity definerfails the catalog test and both role tests.enable row level securitystatement replaced withnullfails both role tests and the two existing row level security tests.bun run checkand the package typecheck pass.This runs on PGlite (Postgres 18 with pgvector), not on a hosted Supabase project.
Checklist
vecstore-sdk(tests and a SQL comment only)Summary by CodeRabbit