RLS Attack Lab tester

Part of Vibe Coding 101, week 7. Instructions: the week 7 lab. SQL for the practice table: setup.sql and fix.sql.

Only test a project you own.

This page connects to a Supabase project with its publishable key and tries ordinary reads and writes, so you can see what any stranger with that key could do. Use it only on a project you created: the practice table from setup.sql, or your own capstone's tables. Pointing it at a database you don't own is not part of this course and may be illegal.

Your URL and key stay in this tab's memory only. Nothing is saved, and nothing is sent anywhere except to the Supabase project you name. Close the tab and they're gone.

1. Connect to your project

In the Supabase dashboard, click Connect at the top, or go to Settings → API Keys. Copy the Project URL and the publishable key (it starts with sb_publishable_). Never paste a secret key (sb_secret_…, or the old service_role key) into any web page: this page refuses them.

Project URL Publishable key Table name

Tables in the public schema only, for example guestbook or your capstone's table.

Not connected.

2. Try what a stranger would try

Each button sends one request with the publishable key and tells you what happened. Before fix.sql, all four work. After it, reading shows only public rows and changes are blocked.

Insert: name

Insert: is_public

Try false to attempt a hidden row.

Insert: message Update: new message for the row

Testing your own table instead?

The fields above match the practice guestbook table. For another table, describe the row in JSON (the same format as {"name": "Ada"}). Leave a box empty to use the fields above.

Row to insert (JSON) Changes for the update (JSON)

ID column

Row ID to update or delete

Empty: update row 1, and delete the newest row you can see.

3. Results

Latest result for each action. Copy these into your lab table.
Action	Latest result
Read all rows	not run yet
Insert a row	not run yet
Update a row	not run yet
Delete a row	not run yet

How to read the results

ALLOWED The publishable key could do it. Fine for things a stranger should do (read public rows, add a guestbook message); a leak for anything else.
0 ROWS (FILTERED) No error, but no rows came back or changed. With RLS on, rows you may not see or change are invisible, so the request matches nothing. That is RLS working, as long as the table really has rows (check the Table Editor).
REFUSED BY RLS A policy's with check rule rejected the new row: "new row violates row-level security policy".
REFUSED: NO GRANT "permission denied": the role has no permission for this action on this table at all. That blocks it, but through a grant, not RLS. From 30 October 2026 new tables get no grants until you add them. When you add one, turn RLS on and add policies in the same script; never fix this with a grant alone.
REFUSED BY A COLUMN RULE The data itself broke a column rule (empty, too long, wrong type). Valid data might still get through, so this says nothing about who may write.
ERROR Not a security result: a wrong URL, key, table or column name, or the project is paused. Fix the setup and try again.