📄 Article
✓ Link checked
Free
Beginner
Why we picked it
This is the official, canonical explanation of the one feature that actually protects your data in Bubble. It makes the core point directly: privacy rules stop data at the server, so it never even reaches the browser, unlike a filter or a hidden element that only pretends the data is gone. Read this before you build anything real, because a Bubble app with empty privacy rules is an open database.
From
Bubble Docs
by Bubble
- Privacy rules run on the server, so blocked data never leaves the database
- Hiding an element on the page does not hide the underlying record
- Set a rule on every data type, starting from deny and granting access explicitly
Open
manual.bubble.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Your app has a second front door most builders forget: the Data API, a public URL that returns your tables as raw JSON. This page shows how that endpoint respects (or ignores) your privacy rules and how to disable it per data type. It is the exact surface an attacker hits when they skip your pages entirely and just query your database over HTTP.
From
Bubble Docs
by Bubble
- The Data API can expose whole tables as JSON if privacy rules are missing
- Turn off Data API access for any data type that does not need it
- The same privacy rules protect both your pages and your API
Open
manual.bubble.io →
🧵 Thread
✓ Link checked
Free
Intermediate
Why we picked it
Nothing makes the risk concrete like real numbers, and this audit of over 11,000 live Bubble apps found that most of them leak. Roughly 13 percent exposed user records through an open Data API, and 79 percent had privacy rule gaps totaling hundreds of millions of records. Read it as a checklist of the exact mistakes other founders shipped so you do not repeat them.
From
Bubble Forum
by ankur1
- Most audited apps had at least one data type with no privacy rule
- Millions of user records were readable without any login
- Nearly a third leaked an API key or secret into the browser
Open
forum.bubble.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
When your app calls a paid service (OpenAI, a payment provider, an email tool), the key can end up visible in the browser if you set it up in the wrong place. This page explains where Bubble keeps those keys private (server side) versus where they leak (client side calls). Getting this right is how you avoid handing strangers your billing.
From
Bubble Docs
by Bubble
- Mark third-party keys as server-side so they never render in the browser
- Client-side API calls expose the key in the network tab
- A leaked key can run up real charges on your account
Open
manual.bubble.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This is the number one web security risk, and it is exactly your question: users reaching data they should not. OWASP is the reference the whole industry uses, and this page names the concrete failures (enforcing access on the page instead of the record, trusting an ID in the URL) in plain terms. Understanding the category helps you spot it in any tool, not just Bubble.
From
OWASP
by OWASP Foundation
- Broken access control has been the top web risk for years
- Enforce permissions on the server for every request, not per page
- Deny by default and grant access only where you mean to
Open
owasp.org →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
IDOR is the everyday version of the danger in one sentence: change the id in a URL or request from 1042 to 1043 and read someone else's record. This page defines it and shows why the fix is an ownership check on the server, not an unguessable id. Once you see it, you will test your own app by changing numbers in requests.
From
OWASP
by OWASP Foundation
- Editing an id in a request can return another user's data
- The fix is checking ownership on the server, not hiding the id
- Random or long ids are not a substitute for an access check
Open
owasp.org →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
If you use Supabase as your backend (common under tools like FlutterFlow, Bolt, or a Webflow front end), Row Level Security is the equivalent of Bubble's privacy rules and it is off until you turn it on. This doc shows how to enable it and write a policy so each user only sees their own rows, enforced right in the database. Skipping it means your anon key exposes every table.
From
Supabase Docs
by Supabase
- Enable RLS on every table or it stays fully readable
- Policies enforce access in the database, below the app layer
- The public anon key is safe only once RLS is on
Open
supabase.com →
📄 Article
✓ Link checked
Free
Advanced
Why we picked it
Once you need real roles (admin, member, viewer), this shows the clean pattern: store roles and permissions in tables, put the role in the user's token, then check it in your policies. It is the deeper follow-up to basic RLS when a single owner check is not enough. Use it when different kinds of users need genuinely different access.
From
Supabase Docs
by Supabase
- Model roles and permissions as tables, not scattered checks
- Carry the role in the user's token via an auth hook
- Enforce the role inside your security policies
Open
supabase.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Xano is a popular no-code backend behind Webflow and FlutterFlow front ends, and this build-along shows how to gate endpoints by role using middleware that runs before your logic. It is the concrete answer to the admin-versus-user problem when your data lives in Xano. You end with a working pattern for who can do what.
From
Xano
by Xano
- Check roles in middleware before any endpoint logic runs
- Common roles are admin, owner, and guest with different rights
- Access rules belong on the backend, not the front end
Open
xano.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
Before roles, you need real login, and this walks through signup, login, and fetching the current user with tokens rather than fragile front-end tricks. It shows how a Webflow site can have proper authentication backed by a real server. A solid starting point if your stack is a visual front end plus a no-code backend.
From
Xano
by Xano
- Real auth uses server-issued tokens, not hidden pages
- Signup, login, and a current-user check are the three pieces
- The backend decides who is logged in, not the browser
Open
xano.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This clears up a mistake that leaks data straight out of Airtable and similar tools: putting a private key in front-end code where anyone can read it. It explains the public-versus-private key distinction and why a private key must sit behind a backend proxy that the browser calls instead. Read it before you connect any service that hands you one all-powerful key.
From
WeWeb
by WeWeb
- Only public keys belong in front-end code
- A private key in the browser grants full read and write access
- Route private keys through a backend proxy the browser calls
Open
weweb.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Airtable's tokens have no row-level control: a valid token can read and write the entire base, so leaking one is a full breach. This guide explains why that key must never touch the browser and exactly what to do if it already has (rotate it, scope it down, restrict it). Essential if you treat Airtable as your database behind a public front end.
From
GitGuardian
by GitGuardian
- One Airtable token grants access to the whole base
- Never embed an Airtable token in front-end code
- If a key leaks, rotate and re-scope it immediately
Open
gitguardian.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
The safe pattern for Airtable is to keep keys and logic server-side, and this is Airtable's own feature for storing secrets inside automations instead of pasting them where they can leak. It shows the vendor-blessed place to keep sensitive values. Pair it with a backend or webhook so the browser never holds the token.
From
Airtable Community
by Airtable
- Store keys in Airtable secrets, not in shared scripts or the front end
- Keep sensitive logic server-side in automations
- The browser should never receive a full-access token
Open
community.airtable.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
When you want the full picture beyond one tool, this is the friendliest serious book on application security, written for people who are not security experts. It covers access control, authentication, testing your own app, and the common pitfalls, all through clear stories rather than jargon. A worthwhile read if security is going to matter for your product long term.
From
She Hacks Purple
by Tanya Janca
288 pages
- Learn access control and authentication from the ground up
- Understand how to threat-model and test your own app
- Written to be readable by builders, not just security pros
Open
shehackspurple.ca →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A plain overview of where no-code tools tend to leak, useful because the same handful of mistakes repeats across Bubble, Airtable, Glide, and the rest. It frames the recurring theme: the visual builder hides the security model, so you have to go look for it. Good orientation before you dig into your specific stack.
From
CodeStringers
by CodeStringers
- The same few mistakes recur across every no-code platform
- Visual builders hide the data-access layer you must configure
- Default settings are usually convenient, not secure
Open
codestringers.com →
