Database Security Audit: can customers see each other's data?

Row-level security is a rule inside the database that decides which rows each signed-in person can see or change. Without it, the database trusts the app's screens to hide other people's data - and anyone who skips the screens sees everything. With it, the database refuses on its own. On Supabase it is switched on per table, as Supabase's own guide explains; GigXchange has it on 277 tables.

Every table, back-end function and stored key checked, every hole fixed, and proof the fixes match the live database. That means row-level security on each table, functions the public should not call locked away, a scan of your code for 13 kinds of leaked key, a blocker for dangerous commands, and a rebuild file checked against live. You get a plain report of what was open and what is now closed.

Not if they are done in the right order, which is why every fix is rehearsed first. Each change runs in a practice transaction - a trial that undoes itself automatically - signed in as your real user types, so we see exactly what each person can and cannot do afterwards. Only then is it applied, with your go-ahead. If a screen relied on a hole, we fix the screen too.

No - the audit reads the structure of your database, not your customers' records. I need read-only access to the rules, tables and functions; the rows themselves stay untouched and unread. Fixes are applied with your approval, one at a time. This is also part of the "appropriate security" UK GDPR expects; the GDPR Compliance Kit covers the rest of that paperwork.

The £49 a month re-check is optional: it reruns the audit checks every month and tells you if anything has drifted. New tables get added, a developer opens a rule for a quick test and forgets it, an AI tool writes a function without a lock. The re-check catches those before they sit open for months. Cancel any month; the fixes from the audit stay in place.

A penetration test tries to break in from outside; this audit reads every rule from the inside and fixes what it finds. A tester sees what they happen to reach in the time they have. Reading the rules shows every table and function, including the ones nobody has found yet. If a contract demands a certified test, you still need one - this makes it far more likely to come back clean.

Seven days from the day read-only access arrives. Days 1-2 are reading, day 3 is the report, days 4-6 are the rehearsed fixes and day 7 is the proof against live. A very large database can take longer, and I will say so after day 1 rather than on day 7. Your app stays live and usable the whole time.

You hear about it the same day, with what was exposed and since when, so you can decide what to do. A personal data breach that risks people's rights must be reported to the ICO within 72 hours of you becoming aware of it. The hole gets closed first. An Incident & Continuity Plan writes down who does what on that kind of day, before it comes.