A login screen is not an access-control test
An app can display the correct dashboard while its underlying requests expose information to the wrong person. Start your review with a specific question: can account B read, change or delete account A’s private records? The answer needs evidence from the deployed access path. A screenshot of a hidden button cannot provide it. This guide proposes a small review exercise for a product you own or are authorised to test; it is not a universal security certification.
What builders are discussing
March, April, June and July Reddit discussions raise variations of the same concern: an application works after a permissions change, but nobody has proved that the change is appropriately restrictive. Some posts promote scanners, and commenters disagree about where checks should live. We use these conversations to identify questions, not to repeat their claimed breach rates. The useful distinction is between making a request succeed and establishing which requests must fail.
Separate public keys from privileged credentials
Supabase publishable keys and legacy anon keys are intended for public clients. Their presence in a browser is not, by itself, a leak. Secret keys and legacy service_role credentials are privileged and belong on the server. Review the built application as well as source files: a value can enter a browser bundle during compilation. If a privileged credential was exposed, removing the line alone is insufficient; revoke or rotate it and investigate its use. The linked API-key documentation explains the distinction.
Write the access rules before changing policies
For each resource, describe the intended reader and writer in ordinary language. For example: a customer reads their own invoices, a billing administrator reads invoices for their organisation, and a visitor reads only the public pricing catalogue. Identify the operation as well as the role. A person allowed to read an invoice should not automatically be able to change its owner. This short access matrix becomes the specification your tests must challenge.
Review grants and RLS together
Database grants determine which operations a role can attempt; RLS policies restrict the affected rows. Check both on exposed tables. An enabled RLS toggle does not prove that a broad policy is suitable. Conversely, a public read policy can be intentional for public content. Do not label every USING (true) expression a vulnerability without examining the resource, role and operation. Keep changes in migrations so that preview and production can be compared.
Run a two-account evidence exercise
Create two synthetic organisations and one customer in each. Give each customer a private invoice with unmistakably different test values. Record the expected result for own-account reads, cross-account reads, logged-out reads, cross-account updates and deletion. Use the application’s ordinary unprivileged request path. Confirm both denial and preservation of the underlying records. Then verify that authorised actions still work. Repeat after changing membership or removing a role; stale access is an important separate case.
Look beyond the first table
Expand the resource inventory to exports, attachments, search, invitations and administrator actions. A protected screen may offer a download endpoint with a different decision path. Ask which component owns each access decision and how it determines the current organisation. Review privileged server handlers separately: their ability to reach the database does not establish that the incoming customer request is authorised. Keep the inventory tied to real product journeys so that new features have an obvious place in the review.
What to retain before you launch
Keep the access matrix, deployment identifier, migration revision and allow/deny results together. Record unresolved cases with an owner and a decision date. Do not attach real customer records or credentials to a public ticket. An independent assessment becomes useful when you cannot explain a boundary, when multiple tenants share sensitive data, or when a permissions change has consequences you cannot confidently test. The deliverable you need is reproducible evidence and a fix plan, not a reassuring badge.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Prepared with AI-assisted research and checked against the linked documentation. Community discussions inform the questions; they are not verified incident reports.