DEV Community: Munaf Khatri

HIPAA compliance evidence for the database layer on Supabase: RLS, functions, triggers and audit logs

Munaf Khatri — Sat, 31 Oct 2026 15:52:28 +0000

Supabase signs a BAA and has a High Compliance setting for projects that store PHI, which handles the platform. The database layer built on it is a separate matter. RLS policies, functions, triggers and audit tables are written by the project team, and a HIPAA review expects evidence that they protect PHI. Supabase’s shared responsibility model puts them on the customer’s side.

What Supabase covers

Encryption at rest and in transit, the BAA, and project settings. The HIPAA guide asks for these to be on:

Point in Time Recovery
SSL enforcement
network restrictions
connection logging
MFA on every account with access

The Security Advisor warns when any of them is off, and the linter flags patterns like a table in public with RLS off. Neither one runs the policies. They cannot show whether a nurse at one clinic can read another clinic’s visits, or whether a deleted record left a row in the audit table.

What the project owner has to show

A HIPAA review asks three questions about the database:

who can reach which patient rows - 164.312(a)(1)
is every change to that data recorded - 164.312(b)
can anyone alter that record afterwards - 164.312(c)(1)

164.308(a)(8) adds that this is evaluated again whenever the environment changes. On Supabase, the answers live in SQL the team wrote. A screenshot of the policies does not show what the database does when authenticated calls one of those functions. Only running it does.

Producing the evidence with unitautogen hipaa

unitautogen hipaa runs against the local Supabase stack, which is built from the migrations, so no patient data is involved:

bash supabase start unitautogen --supabase hipaa --schema public
It generates the tests and the rows they need, runs them as each role the app uses, and rolls the rows back. The tests are written to supabase/tests/seccover/security/, where supabase test db picks them up. The report goes to supabase/tests/seccover/hipaa/public/.

What it checks

Access. Functions, views and triggers that run as their owner bypass RLS. Each one is called as two different tenants, with data on both sides, and marked as holding or leaking. Open policies, column grants and PHI leaking through error messages are checked too.
Audit log. For every PHI table, and for each of insert, update and delete: did the change leave an audit row, and does that row record who made it. Connection logging does not answer this. It records who connected, not which rows changed.
Tampering. For each audit table and each client role: can that role edit, delete or forge rows. A common hole is a security definer function exposed through .rpc() that writes to the audit table, letting any logged-in user write anything into it.
Identity. Policies depend on auth.uid(), auth.jwt() or a session setting. The report shows whether a client session can change what those return.

What to fix

The report opens with a ranked “What to fix” list. There is one row per object, with:

the priority: fix now or review
the HIPAA section
what was found
the change that closes it
a link to the evidence

When many functions are callable only through PostgreSQL’s default PUBLIC grant, the report says so once above the list and gives the single fix:
sql REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA public FROM PUBLIC;

Every finding is backed by a pgTAP test that can be committed and re-run. Each result is mapped to its 164.312 section, and the report is stamped with a SHA-256 of every file behind it, so any later edit shows.

what to do on every migration

Schema changes reach Supabase as migrations in a PR. Add the hipaa command to the CI job that already runs supabase test db:

bash supabase start supabase test db unitautogen --supabase hipaa --schema public

Every PR then produces a new report, dated and stamped, kept as a build artifact. 164.308(a)(8) asks for an evaluation each time the environment changes. Each of these reports is that evaluation for the database.

Scope

The report gives evidence for RLS policies, functions, triggers and audit logs.

It does not cover:

encryption, backups and network settings - Supabase’s part

More on unitautogen hipaa: https://unitautogen.com/postgresql/unitautogen/hipaa/

RLS fails silently. Here's how to actually test your Supabase policies.

Munaf Khatri — Fri, 10 Jul 2026 11:52:00 +0000

A wrong RLS policy doesn't throw an error, it just returns the wrong rows, so it ships untested and you find out when data leaks. rlsautotest generates the pgTAP tests and the seed data straight from your policies, so you can catch it. Free and open-source.

The problem: RLS fails quietly
Row-Level Security is what keeps one tenant's data from another's.
When it's wrong, it doesn't error. It returns the wrong rows.

Too strict → empty results → your app looks broken.
Too loose → rows the user shouldn't see → your app leaks.

Neither raises an exception. You find out from a confused user, or a security report.
And "it works in the SQL editor" proves nothing. The SQL editor bypasses RLS, so your policies were never exercised.

Why nobody tests it
Supabase's own docs admit writing pgTAP tests for RLS is "inaccessible to most web developers."
To test one policy by hand you have to:

create a few users (owner, other user, anon, role-holder)
insert rows owned by different users
become each identity (set JWT claims + role)
run SELECT / INSERT / UPDATE / DELETE as each
assert exactly which rows each can and can't touch

Per table. Per policy.

And the seed data matters as much as the test. Assert "the owner sees their row" against an empty table and it passes while proving nothing.
Most teams take one look and skip it. So the actual security boundary ships untested.

What a real RLS test checks
From each identity's point of view:

owner → sees and changes their own row
other user / tenant → can't see it at all
anon **→ blocked
**role-holder → exactly the access the role grants

All against a row really owned by the identity under test.
And "denied" has two flavors a good test keeps apart:

row-level filtering → zero rows
missing grant → permission error

That's a lot of careful setup, for every policy.

Generate it instead
I got tired of doing this by hand, so I built rlsautotest **(open-source, Apache-2.0).
**Repo: https://github.com/unitautogen/rlsautotest#readme

Not Supabase-only. It runs on any Postgres (Neon, RDS, your own server). I've tested it most on Supabase, so the examples here are Supabase-flavored.
Point it at a disposable copy of your DB. It reads your policies from the catalog and generates the tests and the seed data:
bashpip install rlsautotest

# quick check: who can touch what, as an HTML report
rlsautotest --db-url "$DATABASE_URL" --schema public --html rls-report.html

# or emit a native pgTAP suite to commit + run in CI
rlsautotest --db-url "$DATABASE_URL" --schema public --emit supabase/

The report reads like a permissions table:

notes SELECT INSERT UPDATE DELETE
service_role ✓ ✓ ✓ ✓
authenticated, authorized ✓ ✓ ✓ ✓
authenticated, not authorized · · · ·
anon · · · ·
You're hunting for one thing: a ✓ where a · should be. An anon or unauthorized user who can act. That's a hole, and it jumps out.

Two things make it trustworthy:
Real seed data. It works backward from each policy to a row actually owned by the identity, so green means real isolation, not an empty-table pass.
No false greens. Anything it can't verify soundly, it marks instead of faking.

And --report exits non-zero on a leak or an RLS-off table, so it drops straight into CI.

The bug that passes code review
The kind of thing this catches that humans miss:
A table has two permissive UPDATE policies. Each one's WITH CHECK limits the value a row can become (one status per role). But the check for who may write sits only in USING, not in WITH CHECK.

Here's the trap:

Postgres OR-combines every permissive policy's WITH CHECK, independent of which USING matched.

So the effective check becomes the union of all of them, with the "who" gone. Any identity that can touch the row can write any value any policy allows. A role can set a status its own policy forbids.
Each policy looks correct alone. The leak only exists in the combination. rlsautotest enumerates the value space per identity and shows you exactly which forbidden value slips through.

What it won't do (on purpose)

It proves your DB enforces what your policies declare, not what you intended. A wrong-but-consistent policy is confirmed, greenly.
A command with no policy shows as blocked and isn't asserted unless you opt in.
A policy behind an opaque function is reported, not faked.

A tester that emits confident checkmarks it can't back up is worse than no tester. So when it can't prove something, it says so.
Try it
Got policies you're not 100% sure about? Point it at a throwaway copy and read the report. One command. Worst case, you confirm you're fine.
Repo **+ **docs: https://github.com/unitautogen/rlsautotest#readme