Bubble Security Guide: Privacy Rules, API Tokens, and Data Exposure

Quick answer: Bubble apps are not secure by default. Without privacy rules, your database is publicly accessible via the Data API. To secure your app, you must implement Row-Level Security, protect 32-character API tokens, and authenticate backend workflows. SimplyScan's free audit helps detect these risks in ~30 seconds.

By Daniel A · Kraftwire Software

Bubble apps are not secure by default because they lack automatic Row-Level Security (RLS). To secure a Bubble app, you must manually define Privacy Rules for every data type, check the "Private" box for all API Connector headers to prevent token exposure, and enforce authentication on all Backend Workflows. Without these steps, your database is publicly accessible via the Data API.

If you have not explicitly defined Privacy Rules for every data type, your database is likely leaking information to anyone who knows how to query your app's Data API. In SimplyScan's scans of 187 AI-built apps, 68 of those 187 apps (36%) had at least one HIGH or CRITICAL severity issue, often stemming from the "vibe coding" approach where speed of development outpaces security configuration.

While Bubble provides the infrastructure for a secure app, it does not enforce secure defaults. This guide explores the critical steps required to harden your application against common vulnerabilities found in no-code and AI-generated software.

The Critical Bubble Security Checklist

If you are building with Bubble, Cursor, or Windsurf, your security posture depends on moving beyond the "it works" phase into a hardened production state. Use this checklist to audit your application against the most common vulnerabilities.

1. Missing Privacy Rules: The #1 Data Leak

Privacy Rules are Bubble's implementation of Row-Level Security (RLS). Without them, every record in your database is exposed to the public internet.

• The Risk: If a data type lacks privacy rules, anyone can query your app's Data API to download your entire database. They do not need to be logged in, and they do not need to use your front-end interface. They simply need to know the endpoint URL, which is standardized across all Bubble apps.
• The Misconception: Many builders believe that if data isn't "shown" on a page (e.g., not in a Repeating Group), it is safe. This is false. The Data API serves the raw data regardless of your UI design or "Search" constraints.
• The Fix: Navigate to Data > Privacy and define rules for every object. A common rule is This [Data Type]'s User is Current User, which ensures users can only see their own records. You should also define "Everyone else" rules to ensure that by default, no data is visible unless a specific condition is met.

For a deeper look at how this works in other ecosystems, see our RLS policies explained guide.

2. Exposed API Tokens and Admin Access

API tokens verify the requester's identity for API calls and are essential for server-to-server communication.

• Administrative Power: An API token allows a requester to bypass all privacy rules, modify or delete any data, and impersonate any user. It is effectively "God Mode" for your application.
• Common Leak Vectors: In Bubble, tokens are frequently leaked in the API Connector if the "Private" checkbox is not checked. When this box is unchecked, the token may be sent to the client's browser, where it can be intercepted. This is a major ai api security risk.
• Rotation and Revocation: If you suspect a leak, you must regenerate the token immediately in Settings > API. This will invalidate the old token and stop any unauthorized access.

3. Unprotected Backend Workflows

Backend workflows (API Workflows) are often used for sensitive logic like processing payments, changing user roles, or handling bulk data operations.

• The Vulnerability: If the setting "This workflow can be run without authentication" is checked, the workflow is a public endpoint. If an attacker discovers the URL · which is often predictable · they can trigger the logic repeatedly.
• The Solution: Always enforce authentication. If the workflow must be public (e.g., for a webhook from Stripe), use a "Secret Key" parameter and a conditional "Only when" step to verify the key before the workflow executes any sensitive actions.
• Audit Step: Regularly review your application security checklist to ensure your endpoints aren't acting as backdoors. SimplyScan can help detect if your backend workflows are responding to unauthenticated requests.

4. Data Exposure via Search and URL Parameters

Even with privacy rules, "vibe-coded" apps often leak metadata through client-side logic and insecure routing.

• Search Constraints vs. Privacy Rules: While search constraints filter what a user sees in the UI, they are not a security boundary. An attacker can modify the search parameters in the browser console. Only Privacy Rules prevent the data from being sent from the server to the browser in the first place.
• Insecure ID Enumeration: If your URLs use sequential IDs, users can guess other IDs to access data. Bubble uses unique IDs (UIDs) by default, which are non-sequential. However, you must still ensure the page has a "Type of Content" and that the user has the right to view that specific record via Privacy Rules.
• Option Sets: These are global and public. Never store secrets, API keys, or sensitive configuration values in Option Sets. Anything in an Option Set is downloaded to the client's browser upon page load.

5. Windsurf and Cursor Security Risks in No-Code

When using AI agents like Windsurf or Cursor to write custom code or plugins for Bubble, you introduce a new layer of risk. AI is excellent at generating functional code but often ignores security best practices.

• AI-Generated Vulnerabilities: AI may suggest insecure patterns, such as passing sensitive data through URL parameters or failing to sanitize inputs in a custom JavaScript action. This can lead to XSS or code injection.
• Code Review: Always perform an ai code review security check on any custom code snippet. Do not assume the AI understands the security context of your Bubble app.
• Tooling: For those using these agents, refer to our Windsurf security guide and Cursor security checklist to ensure your AI-assisted development remains secure.

6. Securing the Test Environment

The version-test environment is a frequent target for attackers because it often contains a mirror of production data but lacks production-grade protections.

• Password Protection: Go to Settings > General and enable a username and password for the test environment. This prevents search engines from indexing your test site and prevents unauthorized users from poking around.
• Data Hygiene: Never use real user passwords or unencrypted PII in your test database. If you must use production data for testing, ensure it is anonymized.
• Monitoring: Use uptime monitoring to ensure your test environment isn't being probed by malicious bots.

Performance and Security: The Hidden Link

Security isn't just about data leaks; it's about availability and reliability. In SimplyScan's scans of 187 AI-built apps, speed issues (medium) appeared in 129 apps (69%). A slow app is not just a UX problem; it's a security risk.

• DDoS and Rate Limiting: A slow app is easier to take down with a low-volume Denial of Service attack. Efficient searches and optimized backend workflows improve both the user experience and the app's resilience.
• Revenue Impact: Security breaches and downtime directly impact your bottom line. For more on why performance matters, read speed equals revenue.
• GDPR and Compliance: Security is a prerequisite for compliance. If you are leaking data via the Data API, you are likely in violation of GDPR. SimplyScan checks for GDPR/compliance signals to help you stay on the right side of the law.

How to Audit Your Bubble App with SimplyScan

Manual testing is prone to human error. SimplyScan provides a comprehensive security-scanner/bubble that mimics an attacker's perspective.

• Run a Free Scan: Enter your URL at simplyscan.io. The scan takes ~30 seconds and requires no signup.
• Check the 8 Dimensions: We grade security, speed, SEO, AI visibility (AEO), accessibility (WCAG), GDPR signals, domain health, and email security (SPF/DKIM/DMARC).
• Identify Exposed Data: Our engine detects if your Data API is leaking records, if sensitive headers are missing, or if your version-test environment is wide open.
• Get Actionable Fixes: Each scan provides a clear list of what is wrong and how to fix it, tailored for the Bubble environment.

Advanced Protection: Security Headers and Compliance

For apps handling sensitive data, standard Bubble settings are just the baseline.

• Security Headers: Ensure your app implements a strong Content Security Policy (CSP) to prevent XSS. Use our CSP guide to understand how to configure these.
• Email Security: Protect your domain reputation by configuring SPF, DKIM, and DMARC. This prevents attackers from spoofing your app's transactional emails.
• AEO and AI Visibility: As search shifts to AI, ensure your app is discoverable by engines like Perplexity and ChatGPT while keeping sensitive data hidden. Check your AI visibility (AEO) to stay ahead of the curve.

Summary of Key Takeaways

• Privacy Rules are non-negotiable: If you haven't configured them, your data is public. This is the single most common mistake in Bubble development.
• API Tokens are "God Mode": Treat them with the same secrecy as your root password. Never share them and always check the "Private" box in the API Connector.
• Backend Workflows require Auth: Never rely on a "hidden" URL for security. Use built-in authentication or secret keys.
• Test Environments need Passwords: Don't leave your version-test site open to the world.
• Automate your testing: Use SimplyScan to catch what manual audits miss. One free scan grades 8 dimensions in one pass, including security and speed.

Deep Dive: The Anatomy of a Bubble Data Breach

To truly understand the stakes, let's look at how an attacker exploits a Bubble app with missing Privacy Rules. When you create a new data type, such as Customer_Invoices, Bubble does not automatically restrict access to it. If you enable the Data API for your app, that data type becomes an endpoint: https://your-app.bubbleapps.io/api/1.1/obj/customer_invoices.

Without Privacy Rules, an attacker can send a simple GET request to this URL and receive a JSON object containing every single invoice in your database. This includes sensitive fields like names, addresses, and payment amounts. In SimplyScan's scans of 187 AI-built apps, 68 of those 187 apps (36%) had at least one HIGH or CRITICAL severity issue, often involving exactly this kind of total data exposure.

Protecting the API Connector

The API Connector is one of Bubble's most powerful features, but it is also a common source of credential leaks. When you add a header like Authorization: Bearer [YOUR_SECRET_KEY], Bubble gives you a checkbox labeled "Private".

If you leave this unchecked, Bubble treats the value as a client-side variable. This means the secret key is sent to the user's browser so that the browser can make the API call. Anyone who opens the browser's developer tools can see your secret key in plain text. By checking "Private", you tell Bubble to keep that key on the server. The browser never sees it; instead, Bubble's server makes the call on the browser's behalf.

Architecture Risks in AI-Built Apps

When using tools like Lovable or Bolt to generate Bubble logic, the resulting architecture can be messy. In SimplyScan's data, architecture issues (medium) appeared in 81 apps (43%). These issues often manifest as redundant data calls or insecure data structures that make applying Privacy Rules difficult.

To mitigate this, ensure your AI prompts specify "secure architecture" and "least privilege access." If the AI generates a complex data structure, verify that every link between data types is protected by a corresponding Privacy Rule.

Related Guides

• The Ultimate Vibe Coding Security Checklist
• Is Bubble Safe? A Deep Dive
• No-Code Platform Security Guide
• Xano Security Guide
• FlutterFlow Security Guide
• Weweb Security Guide
• Firebase Rules for AI Apps
• CSRF and Security Headers Guide

---

FAQ

Is Bubble secure by default?

No. Bubble provides the tools for security but starts with open defaults to make development easier. For example, new data types have no privacy rules, meaning their records are publicly accessible via the Data API until you manually add protections. You must take responsibility for configuring these settings correctly to protect your users' data.

What are privacy rules in Bubble and do I really need them?

Privacy Rules are Bubble's version of Row-Level Security (RLS). They are mandatory for any app handling non-public data. Without them, even if data isn't shown on a page, it can be scraped directly from Bubble's Data API by anyone with the URL. You must define who can find, view, and modify each data type to prevent massive data leaks.

What can an attacker do with a leaked Bubble API token?

A leaked 32-character API token grants full administrative access. An attacker can bypass all privacy rules, read every record in your database, modify or delete data, and trigger any backend workflow. They can essentially take over the entire application, steal all user data, and delete your entire database in seconds.

Do I need a paid Bubble plan to get security checks?

While Bubble offers a security dashboard on higher plans, basic security features like Privacy Rules are available on all plans, including the Free plan. SimplyScan offers a free scan that detects many of these issues from the outside, regardless of your Bubble plan, providing an extra layer of verification.

How do I find out if my Bubble app is leaking data?

You can manually check by opening your app in an incognito window and inspecting the Network tab in DevTools for Data API responses. A more reliable and faster method is using SimplyScan's security-scanner/bubble, which automatically tests for exposed endpoints, missing security headers, and common misconfigurations in ~30 seconds.

Is a secret URL enough to protect a Bubble backend workflow?

No. Security through obscurity is not a valid defense strategy. If an attacker guesses, intercepts, or finds the URL in your client-side code, they can execute the workflow. You must use Bubble's built-in authentication or a secret key parameter validated within the workflow logic to ensure only authorized callers can trigger it.