Supabase Audit

What your Supabase policies do.
Not what you meant them to do.

Supabase is fantastic for shipping fast. It also accelerates access-control mistakes when RLS, Storage, RPC, and service_role usage haven't been reviewed properly. This audit checks what is really exposed in your Supabase stack from the outside.

What we verify

RLS policies, table by table

SELECT, INSERT, UPDATE, DELETE, tenant isolation, admin permissions, and consistency across sensitive tables.

Supabase Storage

Public buckets, direct file access, signed URLs that are too broad, predictable paths, and sensitive documents left reachable.

Keys and privileged roles

service_role usage, over-powered tokens, and admin logic handed off to the client.

RPC, Edge Functions, and automations

Functions that bypass RLS expectations, webhooks wired into Supabase, and backend flows that can change data without proper guardrails.

What we often find

RLS present, but incomplete

SELECT is locked down, UPDATE or DELETE isn't. A low-privilege user can still modify or remove data they should never touch.

Buckets or URLs that are too permissive

Contracts, attachments, exports, or HR documents reachable by direct URL — sometimes with no meaningful authentication at all.

Admin actions exposed through the frontend

Account creation, role changes, or automation triggers wired to endpoints visible in public JavaScript.

RPC that breaks isolation

SQL functions or Edge Functions that can read or modify data beyond the tenant or role boundary the team assumes.

Ideal for

  • SaaS, client portals, and internal apps built on Supabase Auth + PostgreSQL
  • Teams that shipped fast with Lovable, Bolt, or Cursor — or a prototype that became production
  • Apps already live that have never had a proper RLS policy review
  • Stacks handling HR, financial, health, or client-document data

FAQ

Need an external review of your HR SaaS?

Share your product, stack, and client context. We will come back with the right review scope.

Discuss your audit