Security review of a Bolt-built client portal

I built a client portal in Bolt for a freelance developer. The admin manages clients, projects, progress updates and invoices, and each client logs in to see only their own. Bolt wrote the app, a Postgres database with row-level security, and an edge function that lets the admin create client accounts. Then I reviewed it the way I'd review a client's app.

The access rules were solid. Sign-up was the hole. It was open to anyone, and Bolt's settings toggle to turn it off failed every time. Bolt's first fix was a trigger that trusted a created_by_admin flag in user_metadata, but whoever signs up writes that metadata, so one signUp call with the flag set got straight past it.

Bolt's second fix used a server-only secret, read through a database function. It revoked access from the anon and authenticated roles but not from PUBLIC, which every role inherits, so a request with nothing but the public key returned the secret. A second helper function had the same gap. The final migration revokes EXECUTE from PUBLIC on both, allows only the service role, and rotates the leaked secret. The same request now gets permission denied.

Then I ran an isolation test with real sign-ins as each client. Each one sees only their own projects, updates and invoices. A client asking for another client's project by ID gets zero rows. Clients can't change a status, add an invoice, make themselves admin or call the admin function. 16 of 16 checks passed, and no data changed.

If your Bolt app is about to hold real client data, this is the review I'd run on it first.