Bubble.io Security: What You're Responsible For (and What Bubble Is)

Bubble.io security responsibility diagram

Bubble.io operates a shared responsibility model. Bubble secures the infrastructure — the servers, the runtime, the platform itself. You secure the application: the data model, the privacy rules, the API credentials, the compliance posture. Most Bubble security problems I've seen aren't platform vulnerabilities. They're gaps in the application layer that Bubble can't fill, because they're yours to fill.

This guide covers the application-layer responsibilities. It's practical, not legal advice. If you're in a regulated industry — insurance, healthcare, lending — some of this is a floor, not a ceiling.

The shared responsibility line

Bubble manages: physical security, network security, platform-level patching, DDoS mitigation, encrypted data in transit (TLS) and at rest, SOC 2 Type II compliance for the infrastructure layer, and their own internal access controls.

You manage: who can read what data in your database, how API credentials are stored and rotated, whether your app leaks data through the API, what happens if a user account is compromised, and whether your data handling meets the regulatory requirements of your industry.

This is the same model as every cloud platform. The difference with Bubble is that the line is easier to miss, because Bubble abstracts so much of the infrastructure that the application layer doesn't feel like your infrastructure. It is.

Privacy rules: the most important thing most Bubble apps get wrong

Bubble's privacy rules control what data users can retrieve through the API. Without them, your data is effectively public — any authenticated user can query any record of any type if they know the right API call. Bubble's own documentation warns about this. It's still one of the most common gaps I see in production apps.

The defaults are permissive. A new data type in Bubble has no privacy rules. That means: all users can find its records, all users can see all fields. Adding a rule that says "this record is only visible to the user it belongs to" requires you to explicitly add it.

For a fresh app, this is straightforward. For a production app that's been growing for two years with 40 data types, retrofitting proper privacy rules requires careful work — you have to understand which rules you're adding, test that existing workflows still work, and verify you haven't blocked something legitimate. I wrote up the retrofitting process in detail: how to retro-fit privacy rules to an existing Bubble app.

The common patterns that hold up in production:

Every user-owned record gets a rule: "the creator/owner can see this"
Admin-only records get a role check, not just an authentication check
Shared records (accessible to multiple users) use a list field or a junction table — not "all users can find"
Sensitive fields (payment data, health data, personal identifiers) are hidden even from records the user can otherwise find
API calls that return data are verified against the privacy rules, not just against the workflow logic

API credentials and secrets

Bubble's API Connector stores credentials in the connector configuration. They're not exposed in the editor UI, but they are accessible to anyone with access to your Bubble app editor. That means your API keys are as secure as your Bubble collaborator list.

A few things I enforce on any production Bubble app with integrations:

Scope credentials narrowly. If a Stripe key is only used for reading customer data, it shouldn't have permission to create charges. Use the minimum scope the integration needs. If the key is compromised, the blast radius is contained.

Use separate keys for test and production. This sounds obvious. A surprisingly high proportion of apps I've audited have a single Stripe or Twilio key across both environments. When you rotate the production key, you don't want test workflows going dark.

Plan for rotation. API credentials should be rotatable without a deployment event. In Bubble, that means updating the key in the API Connector. Know where every key lives, and audit it at least annually. For regulated industries, rotation frequency is often mandated.

Never put credentials in option sets. Option sets are queryable by the API. Credentials stored there are not secrets.

GDPR and data residency

Bubble's production infrastructure is in the US. Your data is stored in the US by default. If your users are in the EU and you're collecting personal data, that's a transfer of personal data outside the EEA. You need a legal basis for it — typically Standard Contractual Clauses (SCCs), which Bubble provides in their Data Processing Agreement.

Bubble has an EU data residency option (EU cluster). If you need to keep personal data in the EU — for regulatory reasons, for customer contractual reasons, or simply because it's the right call — this is the mechanism. It's a different cluster with a different endpoint. Migrating an existing app to the EU cluster is not trivial; it's easier to decide this at the start.

For GDPR compliance at the application layer, the requirements are practical: you need to know what personal data you hold, have a lawful basis for holding it, be able to delete or export it on request, and be able to demonstrate you've done this. I wrote a guide on the practical side of this: how to make your Bubble.io app GDPR compliant.

HIPAA: what Bubble can and can't cover

Bubble can sign a Business Associate Agreement (BAA). A signed BAA means Bubble will handle PHI in accordance with HIPAA's technical and physical safeguard requirements for their infrastructure layer. It does not make your application HIPAA-compliant. The application layer — access controls, audit logging, encryption of specific fields, breach notification procedures — remains your responsibility.

If you're building a healthcare application on Bubble that handles PHI:

Request a BAA from Bubble before you handle any PHI in production
Audit logging is required — every access to and modification of PHI should be logged with who did it and when. Bubble doesn't do this for you.
Access controls need to be role-based and demonstrably enforced — privacy rules are the mechanism, but they need to be designed for HIPAA's minimum-necessary standard
You need a breach notification procedure that covers the 60-day reporting window

HIPAA on Bubble is achievable. I've worked on patient record systems built on the platform. The bar is higher than a standard SaaS app, and the audit trail requirements in particular take real design work.

Penetration testing and security reviews

Bubble's terms allow security testing of your own application. You can commission a penetration test against your Bubble app; you need to notify Bubble in advance and scope it to your application, not the shared infrastructure.

What a Bubble security review typically finds, in order of frequency:

Missing or under-specified privacy rules
API endpoints that return more data than the workflow expects (the Bubble Data API returning whole record objects when only one field is needed)
Missing rate limiting on authentication endpoints
Credentials with broader scope than needed
Workflows that trust client-side data without server-side validation

None of these are Bubble platform vulnerabilities. They're all application-layer problems. Which means they're all fixable without waiting for Bubble.

When to think about moving beyond Bubble for security reasons

Bubble's shared infrastructure model means you don't control the platform version, the underlying runtime, or the infrastructure update schedule. For most businesses, that's fine — you're trading control for speed, and the trade is worthwhile. For some regulated businesses, the lack of control is itself a compliance problem.

Specific signals that the platform might be the limiting factor:

Your compliance regime requires you to document and approve all infrastructure changes — impossible on a shared platform
You need to run your own penetration tests on the full stack, including the runtime
Your data residency requirements exceed what Bubble's EU cluster covers
Your audit logging requirements go deeper than what the application layer can provide
You're in scope for a regulation that requires vendor lock-in risk assessment, and Bubble scores poorly on exit feasibility

If you're hitting these signals, the question isn't whether to stay on Bubble — it's when to move, and what to move to. I work specifically with businesses in insurance, healthcare, regulatory operations, and mortgage lending on this decision. The Bubble migration for regulated industries page covers the shape of that work.

The practical security checklist

For any Bubble app handling real user data in production:

Privacy rules — every data type has explicit rules; none are left at the permissive default
Collaborator access — your Bubble editor access list is current; anyone who no longer needs access has been removed
API credentials — every key has minimum necessary scope; test and production use separate keys; you know where every credential lives
Bubble Data API — if you're not using it, disable it; if you are, verify what it exposes against your privacy rules
Workflow API — if exposed, endpoints are authenticated and the actions they trigger are scoped appropriately
GDPR / data residency — you have a DPA with Bubble; if EU residency is required, you're on the EU cluster
Audit logging — for regulated industries, you have application-level logging of who accessed what and when
Breach procedure — you have a written procedure and know your notification obligations