Glossary / AI & Vibe Coding
BaaS Exposure
BaaS exposure is when a backend-as-a-service setup (Supabase, Firebase, Appwrite and similar) is reachable from a product front end in a way that leaks data or lets unauthorised actions through, usually because access rules were left permissive while the client-side config sits in plain view.
What is BaaS exposure?
BaaS exposure is when a backend-as-a-service setup (Supabase, Firebase, Appwrite and similar) is reachable from a product front end in a way that leaks data or lets unauthorised actions through, usually because access rules were left permissive while the client-side config sits in plain view.
Key takeaways
- BaaS platforms ship connection config to every visitor by design; the rules are the security.
- The platform is not the problem; permissive default rules are.
- Storage buckets leak as often as tables, and people forget to check them.
- Detecting the exposed config and missing rule is enough; you never need to read the data to prove it.
Why it matters
Backend-as-a-service platforms move the security boundary into rules you configure, and ship the connection details to every visitor by design. That trade is fine when the rules are right and catastrophic when they are not, and AI code tools frequently scaffold the connection while leaving the rules wide open.
How Devoq approaches it
We treat any BaaS front end as guilty until its rules prove otherwise. The platform is not the problem; Supabase, Firebase and Appwrite are all secure when configured correctly. The problem is that the default developer experience optimises for "it works" and the security step is opt-in and invisible. When we audit a BaaS-backed product we inventory exactly what the client can reach: which tables, which storage buckets, which functions, and whether each is gated by a real policy scoped to the current user. We check storage separately, because an open bucket leaking uploaded documents is a breach people forget to look for. We never read the client data to prove the point; detecting the exposed config and the missing rule is enough, and reading it would be the very thing we are warning against. The deliverable is a map of the attack surface and the specific rules to close it, in the platform own terms.
What to check on a BaaS front end
- Every table and collection is gated by a rule scoped to the current user.
- Storage rules are not "allow read: if true".
- Serverless functions check auth, not just the client.
- You verified the rules with the public key, from the client.
Example
A CRM built on Firebase looks locked because login works. Its Storage rules still read "allow read, write: if true", so every uploaded contract is public to anyone with the URL pattern. Login never gated the files.
Related terms
Scan your SaaS for backend exposure
A free, passive check that detects Supabase, Firebase and Appwrite exposure and explains the fix. Detection only.
Scan your SaaS for backend exposure
