The Bubble app security checklist

Most no-code apps that leak data aren’t defeated by clever attacks. They leak because a setting was left on its default: application rights set to “Everyone can view”, a data type marked visible to everyone, an API key sitting in an option set. Attackers go after the low-hanging fruit, and defaults are the lowest fruit there is.

The fix is not paranoia; it’s a checklist. Bubble gives you every control you need, but it won’t turn them on for you. Here are the principles that make the controls make sense, followed by the full configuration checklist to run on every project before it goes anywhere near production.

The rule of least privilege means restricting access to your app and its data to the absolute minimum that is necessary for each user, role, account and API connection. The goal is to minimise the vulnerabilities and surface area you offer a potential attacker.

Three principles that do most of the work

Least privilege. Think through every way people and systems can touch your app: each user, each role, each account, each API connection. Then ask, for each one, “how can I make this harder for a potential attacker?” Most hackers look for easy opportunities and quick wins. An app that restricts access to only those who genuinely need it is simply not worth their time.

Stay current. Security practice moves, so read the news and the cyber journals, including the cautionary tales. The basics compound: strong passwords, rotation, no password reuse, a password manager, an individual account for every user rather than shared credentials, two-factor authentication (authenticator apps are considered more secure than SMS codes), not clicking untrusted links or downloading untrusted attachments, and keeping your operating system and applications updated. If you want structured learning, look at the security assessments big companies face, such as SOC 2 compliance surveys, online courses on platforms like Coursera, and government resources; in Australia, the Signals Directorate publishes the Essential Eight guidelines.

People are the weakest link. Most successful hacks don’t brute-force the system. They go after the unpredictable element: people. Social engineering stories look silly in retrospect, but the victims usually just weren’t paying attention in the moment. Technical hardening matters, and so does the habit of thinking carefully before you click.

The checklist

Run through every point on every project. Some will need judgement for your specific use case; none should be skipped without a reason you could defend.

App settings and front end

1. Set your application rights to private. In Settings, under General. “Everyone can view” is fine for a training app someone needs to mark; the moment your app reaches production, or holds anything sensitive like API keys, it must be private.
2. Enforce password-related security. On the same privacy and security tab you’ll find password strength, email confirmation, two-factor authentication and password rotation. Use cases differ, so you may enable or disable different options, but think each one through deliberately.
3. Restrict front-end elements from loading. Put your app’s UI inside an outer container that is not visible on page load, and only show it when the user is logged in, has the right role, and isn’t deactivated or archived. Privacy rules protect the database, but without this a visitor can still see your data structures and admin options. Nobody should see the inside of your admin tool unless they’re an admin.
4. Clean up test pages. Delete them, or at minimum hide them inside the same security container.

Database and privacy

5. Configure appropriate privacy rules. This is specific to your use case, so think it through carefully, and especially avoid leaving a data type on “This type is visible by everyone”. That means the database has no restrictions, and someone with a little web development knowledge can access the data directly.
6. Don’t store sensitive data in option sets. Option sets are not the place for API keys or any private information.
7. Don’t pass sensitive data in URL parameters. URLs are visible in your logs, and in the logs of other web services.
8. Always upload sensitive files as private. The file and picture uploaders have a checkbox to make the file private and attach it to a row of data; use it for anything sensitive.

Back end and APIs

9. Keep your back-end workflows set to private where possible.
10. Don’t enable the Data API where possible, or if you must, enable only the endpoints for the data types you actually require.
11. Store API keys in the API Connector’s private parameters. A private parameter means the key is only available to your Bubble back end, never to any user.
12. Keep stored tokens back-end only. If you do store tokens in your database, for example user-supplied tokens or two-factor auth tokens, your privacy rules should grant no access to that data type at all. Interact with those records only in back-end workflows, where privacy rules can be ignored.

Discipline and keys

13. Document areas of risk for yourself and for future developers. Small changes can have big security implications. If there’s a workflow that must never change the account field, or a user-role field that must never be edited casually, note it so nobody inadvertently breaks your access model.
14. Write your logic explicitly to prevent data leakage. “Current user’s role is Admin” is explicit: only admins will ever match. “Current user’s role is not Customer” is implicit: the day someone adds a Team Member role, team members suddenly see everything admins can see, because the rule only excluded customers. Say who gets access, not who doesn’t.
15. Use restricted keys for external services. Services like SendGrid and Stripe let you create keys scoped to specific endpoints rather than the whole account. Use them wherever they’re offered.
16. Only give collaborators the permission they need. In Bubble’s Settings, the Collaborators tab lets you grant full admin rights, restrict someone to the test version only, or narrow access further to logs, the editor or data. Grant the minimum.
17. Roll your API keys periodically, and especially after granting anyone temporary access. If another developer has your keys, they have the keys to the car and can drive it away. Rolling means deleting the old key in the external service, creating a new one, and copying it into your app.

Verify, vet and report

18. Check what’s actually being sent to the front end. Use your browser’s Inspect tools to look at the JSON objects your app loads. You’ll see exactly which data reaches the client, whatever your interface shows.
19. Use only credible, trusted plugins. This is somewhat subjective, but look at the reviews, the volume of installs, and the forum for reported issues, and generally avoid anything unproven.
20. Report vulnerabilities to Bubble support. If you find one, don’t post it on Twitter to complain; report it so it can be fixed.
21. Understand each project’s specific security requirements. You might need onshore hosting, obscured data, or HIPAA compliance. Bubble may not be able to meet every requirement, and even where it can, data may still surface in logs. No two projects are the same; work out what this one needs.
22. Secure your Bubble account itself. Your Bubble account is effectively a master account over every app you own. Everything above is undermined if the account controlling it all is weak, so secure it properly and turn on two-factor authentication.

Try it yourself

Open an app you’ve built and run points 1, 5 and 18 right now: check your application rights, open the Privacy section and look for any data type still “visible by everyone”, then load your app logged out with the browser’s network inspector open and read what comes back. Those three checks take ten minutes and catch the majority of real-world exposure. Then keep the full list somewhere you’ll see it at the start of every project; it will evolve as you find items worth adding.

This skill in the AI era

A security checklist is one of the most transferable assets a builder owns, because AI coding tools inherit your standards or your gaps. When we direct Claude Code on a build, this same discipline becomes the review layer: least privilege in the data model, explicit allow-lists in the logic, keys kept server-side, and a verification pass on what actually reaches the client. The tools write the code faster than ever; the habits that carried over from Bubble decide whether it’s safe. It’s exactly how a senior Claude Code developer earns the “senior”: not by typing, but by knowing what to check.