Bubble Docs
  • Introduction
  • New? Start Here
  • What is Bubble?
  • The Glossary
  • User manual
    • Getting started
      • What is Bubble?
      • Building your first app
        • Planning features
        • Database structure
        • Design and UX
        • eCommerce and payments
          • Shopping cart
          • Checkout page
          • One-time payments
          • Subscriptions
          • Marketplace
      • Creating and managing apps
      • The Bubble editor
        • Tabs and sections
          • Design tab
            • The element tree
            • The property editor
          • Workflow tab
          • Data tab
          • Styles tab
          • Plugins tab
          • Settings tab
            • Application settings
              • Custom headers/body
              • Visual settings
              • Social media sharing
              • Translating your app
              • Email settings
              • Collaboration
            • Custom domain and DNS
          • Logs tab
        • Tools
          • Key features
          • The search tool
          • The Issue Checker
          • The element tree
          • The element property editor
          • The debugger
          • Notes
        • Previewing your app
      • Transitioning to Bubble from...
        • JavaScript
        • HTML and CSS
        • SQL
    • Design
      • Elements
        • The element hierarchy
          • The element tree
        • The page
        • Containers
          • Groups
          • Repeating groups
          • Table elements
          • Popups
          • Floating groups
          • Group focus
        • Visual elements
        • Input forms
          • Text and numbers
          • Dates and time
          • File uploads
          • Selection controls
        • Reusable Elements
      • Styling
        • Color variables
        • Font variables
        • Styles
        • Custom Fonts
      • Responsive design
        • Building responsive pages
        • Legacy articles
          • The Basics (Legacy)
          • Building Responsive Pages (Legacy)
          • Migrating Legacy Pages
          • Tips When Designing (Legacy)
      • Templates
      • The Component Library
      • Importing from Figma
    • Data
      • The database
        • Data types and fields
        • Creating, saving and deleting data
        • Finding data
        • Displaying data
        • Protecting data with privacy rules
        • The database editor
        • Export/import data
          • Exporting data
          • Importing data (CSV)
        • Working with location data
        • Using Algolia
        • Database structure by app type
          • Marketplace Apps
          • Directory & Listings Apps
          • Social Network Apps
          • SaaS Apps
          • Project Management Apps
          • CRM Apps
          • Professional Services Apps
          • On-demand Apps
          • Documentation/ CMS Apps
          • Applicant Tracking System (ATS) Apps
          • Portfolio Apps
          • Gallery Apps
          • Online Store / Ecommerce Apps
          • Blog Apps
          • Messaging App
          • Dashboards
          • Building Block Apps
          • Bubble as a backend
      • Files
      • Images
      • Static data
        • App texts (translations)
        • Option sets
      • Temporary data
        • Custom states
        • URL parameters
      • User accounts
        • Authentication plugins
          • Facebook plugin
          • Fitbit plugin
          • Google plugin
          • Instagram plugin
          • LinkedIn plugin
          • Pinterest plugin
          • Slack plugin
          • Wistia plugin
          • YouTube plugin
        • Cookies set by Bubble
      • Time, dates and time zones
    • Logic
      • The frontend and backend
      • Workflows
        • Events
          • Frontend events
            • Recurring workflows
            • Custom events
          • Backend events
            • Database trigger events
        • Actions
        • API Workflows
      • Dynamic expressions
      • Conditions
      • Navigation
        • Single-page applications (SPA)
        • Multi-page applications
        • Page slugs
    • Workload
      • Understanding workload
        • Activity types
        • The workload calculation
        • Client-side and server-side processing
      • Tracking workload
        • Measuring
          • Using App Metrics
        • Monitoring
          • Workload notifications
          • Infinite recursion protection
      • Optimizing workload
        • Optimization framework
        • Optimization checklist
          • Page load
          • Searches
          • Workflows and actions
          • Backend workflows
        • Agency showcases
          • Minimum Studio
          • Neam
          • Support Dept
    • Security
      • Bubble's security features
      • Planning app security
      • Client-side and server-side
      • Bubble account security
      • App security
      • Page security
      • Database security
      • API security
        • API Connector security
        • Data API security
        • Workflow API security
      • Flusk
        • Overview
        • Flusk plan features
        • Getting started with Flusk
        • Flusk security tools
          • The Issues Explorer
          • Issue details
          • Tools and settings
            • Pages rating
            • Database rating
        • Flusk FAQ
      • Cookies
      • Security checklist
    • Publishing your app
      • Web app
      • Native mobile app
        • Global native mobile settings
        • iOS App Store
        • Google Play Store
        • Publishing FAQ
    • AI
      • Generate apps with AI
        • About AI app generation
      • AI page designer
      • Connect to AI agents
    • Maintenance
      • Collaborators
      • Version control
        • Best practices: Version control
        • Transitioning from the legacy version control
        • Terminology: Version control
        • Version Control (legacy)
      • Commenting
      • Database maintenance
        • Copying the database
        • Restoring database backups
        • Bulk operations
          • Bulk operation methods compared
        • Wiping change history
      • Performance
        • Hard limits
        • Capacity Usage (legacy)
        • Notes on queries
      • SEO
        • Introduction to SEO
        • SEO: App
        • SEO: Page
      • Testing and debugging
        • Introduction to testing and debugging
        • The debugger
        • The server logs
        • Supported browsers
      • API workflow scheduler
    • Integrations
      • API
        • Introduction to APIs
          • What is a RESTful API?
        • The Bubble API
          • Bubble API terminology
          • Authentication
            • How to authenticate
            • No authentication
            • As a User
            • As an admin
          • The Data API
            • Data API Privacy Rules
            • Data API endpoints
            • Data API requests
          • The Workflow API
            • Workflow API privacy rules
            • Workflow API endpoints
            • API workflows
              • Creating API workflows
              • Scheduling API workflows
              • Recursive API workflows
              • API Workflow Scheduler
              • Case: Stripe notifications
        • The API Connector
          • Authentication
          • API Connector security
          • API guides
            • OpenAI
              • Authentication
              • Calls
                • ChatGPT
                  • Chat
            • Google Translate
              • How to setup Google API keys
          • Streaming API
        • API security
        • Plugins that connect to APIs
        • API Glossary
      • Plugins
        • What Plugins Can Do
        • Installing and using Plugins
        • Authentication plugins
        • Special Plugins
      • SQL Database Connector
      • Bubble App Connector
      • WorkOS
        • WorkOS SSO
        • WorkOS API
    • Infrastructure
      • Sub-apps
      • Bubble release tiers
      • Hosting and scaling
        • How Bubble hosting works
        • Scaling with Bubble
        • CDN (Cloudflare)
        • Bubble app names
        • Domain and DNS
      • Compliance
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks and standards
    • Bubble for Enterprise
      • Hosting and infrastructure
        • Dedicated instance
          • The Dedicated editor experience
          • Technical specs
          • Main cluster dependencies
          • Customizable options
          • Migration process
            • Pre-migration
            • During migration
            • Post-migration
      • Security and compliance
        • Single sign-on (SSO)
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks
        • Bubble's security features
      • Admin and collaboration
      • Priority support
      • Billing and Payment Guideline for Dedicated Instances
  • Core Reference
    • Using the core reference
    • Bubble's Interface
      • Design tab
      • Design tab (Legacy)
      • Workflow tab
      • Data tab
      • Styles tab
      • Styles tab (Legacy)
      • Plugins tab
      • Settings tab
      • Logs tab
      • Template tab
      • Toolbar
      • Top and context menu options
      • Deployment and version control
        • Deployment & Version Control Dropdown (legacy)
      • Notes
    • Elements
      • General properties
      • General properties (Legacy)
      • Styling properties
      • Styling Properties (Legacy)
      • Responsive Properties
      • Responsive Properties (Legacy)
      • Conditional formatting
      • States
      • Page Element
        • Page Element (Legacy)
      • Visual Elements
      • Containers
      • Container Layout Types
      • Containers (Legacy)
      • Input Forms
      • Reusable Elements
      • Element Templates (legacy)
    • Workflows
    • Events
      • General events
      • Element events
      • Custom events
      • Recurring event
      • Database trigger event
    • Actions
      • Account
      • Navigation
      • Data (things)
      • Email
      • Element
      • Custom
    • Data
      • Data Sources
      • Operators and comparisons
      • Search
      • Privacy
    • Styles
    • API
      • The Bubble API
        • The Data API
          • Authentication
          • Data API endpoints
          • Data API requests
        • The Workflow API
      • The API Connector
        • Authentication
        • Adding calls
    • Bubble-made Plugins
      • AddtoAny Share Buttons
      • Airtable
      • API Connector
      • Blockspring
      • Box
      • Braintree
      • Bubble App Connector
      • Chart.js
      • Circle Music Player
      • Draggable Elements
      • Dropzone
      • Facebook
      • Fitbit
      • Full Calendar
      • Google
      • Google Analytics
      • Google Optimize
      • Google Places
      • Ionic Elements
      • iTunes
      • Slidebar Menu
      • LinkedIn
      • Localize Translation
      • Mixpanel
      • Mouse & Keyboard Interactions
      • Multiselect Dropdown
      • Progress Bar
      • Rich Text Editor
      • Rich Text Editor (Legacy)
      • Screenshotlayer
      • SelectPDF
      • Slack
      • Segment
      • Slick Slideshow
      • SQL Database Connector
      • Star Rating
      • Stripe
      • Tinder-like Element
      • Twitter
      • YouTube
      • Zapier
    • Application Settings
      • App plan
      • General
      • Domain / email
      • Languages
      • SEO / metatags
      • API
      • Collaboration
      • Sub-apps
      • Versions
  • Account & Marketplace
    • Account and billing
      • Pricing and plans
        • Plans and billing
        • Billing cycle
        • FAQ: Pricing and Workload
      • Account Management
      • Building Apps for Others
      • Selling on the Marketplace
      • Plans & Billing (legacy)
    • Official Bubble Certification
      • Hiring certified developers
    • Building Plugins
      • The Plugin Editor
      • General Settings
      • Updating to Plugin API v4
      • Adding API Connections
      • Building Elements
      • Building Actions
      • Loading Data
      • Publishing and versioning
      • Github Integration
    • Building Templates
    • Application and data ownership
    • Marketplace policies
    • Bug reports
  • Vulnerability Disclosure Policy
  • Beta features
    • About the Beta features section
    • Native mobile apps 🔒
      • Introduction
        • What is a native mobile app?
        • Native mobile vs. web development
        • Differences in native and web elements
        • Native mobile app terminology
      • Building
        • Views and navigation
        • Native mobile actions
        • Components and gestures
        • Device resources
          • Location services
          • Camera/photo library
      • Previewing
      • Publishing
Powered by GitBook
On this page
  • Guiding principles in Data API security
  • The principle of least privilege
  • Authentication and authorization
  • Authentication
  • No one has access
  • Some clients have access
  • Everyone has access
  • Authorization
  • Enabling data types
  • Privacy rules
  • Data API security checklist

Was this helpful?

  1. User manual
  2. Security
  3. API security

Data API security

This section covers security related to the Data API.

Last updated 1 year ago

Was this helpful?

This article covers the security aspects of using the Bubble Data API specifically. If you want to learn more about the Bubble Data API in general, you can check out the articles below:

Article: The Data API Article series: The Bubble API

The Data API allows external apps and systems to interact programmatically with the data stored in your Bubble app. It provides a set of endpoints for creating, reading, updating, and deleting data.

Naturally, giving an external system access to your app's database can open up for potential vulnerabilities, and it's important to learn how to use it correctly.

Guiding principles in Data API security

The principle of least privilege

As we've explored multiple times in our Security article series, also applies strongly to the Data API. We'll now go over how you can plan and execute to adhere to this principle when you set up the Data API.

In a bank, not every employee has the keys to the vault. A teller can access the cash drawer but doesn't have the authority to authorize large wire transfers. Conversely, the bank manager might have that authority but doesn't necessarily need access to every single safety deposit box.

Authentication and authorization

In our Introduction to APIs article we explored the two sibling concepts of authentication and authorization.

The way this logic is structured is no different than in real life: before you let someone in through your front door, you would want to know who it is. In that way, they authenticate (you recognize their face), and this allows you to authorize what they have access to (step into your house).

The same pattern of identification and authorization is applied in countless real-life scenarios:

  • Airports: (who is the passenger? What plane do they have access to)

  • Cinemas: (does the person have a ticket? To what movie?)

  • Banks (who is the customer? What bank accounts do they have access to)

The reason for highlighting this in real-life scenarios is to emphasize the authentication/authorization way of thinking to your security planning. When you are planning security for your Data API, you can ask the question in exactly the same way:

  • Who is the client trying to access my app's database?

  • What should this client have access to?

When you combine this way of thinking with the principle of least knowledge, we have some very helpful rules of thumbs to guide your thinking:

  • Who is the client trying to access my app's database?

    • I need to know in order to apply the principle of least knowledge

  • What should this client have access to?

    • According to the principle of least knowledge – only as much as they need and not an inch more

Having established those principles, let's look at what that means in practice as you develop your app.

Authentication

The first step in any secure transaction is that of knowing who the client is. For the Data API, this follows a range that we can split into three categories:

  • No one has access (the Data API is disabled)

  • Some clients have access (the Data API is enabled, but requires authentication)

  • Everyone has access (the Data API is enabled, and requires no authentication)

No one has access

Before you make any decisions regarding your app's Data API, you need to determine whether anyone should have access at all. The Data API is disabled by default, but can be enabled in the Settings – API section of your app by checking Enable Data API.

If your app doesn't need any external app or system to access the database, you can safely keep that checkbox unchecked. This keeps the Data API completely disconnected and no other security measures are needed.

Some clients have access

The second level in our access range is to give one or more clients access, but not everyone. This is where most apps with an enabled Data API will be, and it means we need to authenticate ("check the ID") of every system that wants access to the database.

There are two ways to authenticate an external app or system without giving everyone access. To learn how to set up each one, following the article link listed below:

  • Authenticating as a user essentially means to "log in" to your app in the same way as a regular user would. This means that you can apply Privacy Rules to control what that user has access to. This is an access level that gives you a high degree of control over what that user can and can't do in your database. Article: The Data API - authenticating as a user Using this authentication method, you will usually continue to set up rules for who can access what. Or in other words, authorization. Follow this link to continue setting that up.

  • Authenticating as an admin means to use Bubble's built-in API token system to give access. This automatically gives them full administrator access, which means the same access level as you have as the app's developer (not to be confused with any admin role you set up in your app). This access level grants extensive permissions, allowing the reading, modification, and deletion of all data in your app. Ensure it's used only with external apps or systems you trust implicitly. Article: The Data API - authenticating as an admin

Everyone has access

In this option, we disregard the authentication step altogether: the door is open and anyone can walk in. The logic then follows that since we're not checking who walks through the door, we can't determine what each visitor should have access to. Everyone is treated the same.

This method should only be used when you are determined to give free, public access to your database. Keep in mind this can not only affect your security, but also the amount of that your app consumes (as API requests will spend server resources, adding to your total workload).

To learn how to set up your Data API to offer everyone access, see the article below: Article: The Data API - no authentication

Authorization

Returning to the bank metaphor: a person who registers as a customer in a bank needs to have access to their own account, but most would find it strange if they were given access to all accounts. The same logic applies to an app where you don't want to share all data even to people that are authenticated to use the app in the first place.

We've taken care of the authentication (who is the client), and now it's time to explore how we determine the authorization for those client (what the client can access). This is done in two ways:

Enabling data types

The first step to protect data is to enable only the data types that you want to expose.

Keep in mind the following:

  • Unchecked data types are not available in the Data API regardless of how the user authenticates

  • Checked data types are exposed, but adhere to the privacy rules in combination with the client’s authentication. We'll look at data types in the next step.

When you enable the Data API, you will see the list of of data types that you want to show.

The data types that are not enabled (unchecked) will not be accessible by anyone. In the example above, we have a data type Product that we want to share with another app. Following the principle of least privilege, we'll only activate that one, and keep all other data types unchecked.

This setting takes care of the overarching authorization: what data types any client has access to. In the next step we'll look at privacy rules: they provide the fine-grained control

Privacy rules

After enabling the data types we want to expose, it's usually a good idea to use privacy rules to control which fields on those data types can be accessed, and what kind of actions can be performed.

Just like in your regular app, privacy rules are set up on a user-basis. In other words, which user you authenticate determines the level of access they have to:

  • Find in searches

    • What fields and uploaded files to expose

  • Make changes to

    • Create

    • Edit

    • Delete

For more in-depth instructions on how to set up the privacy rules for a data type exposed in the API, check out the article below:

Article: The Data API - Setting up Privacy Rules

Data API security checklist

With the methods above in mind, let's go over the tools that secure your Data API.

  • Keep the principle of least access in mind (link)

  • Decide who has access (authentication) First, decide who has access to the data API:

    • No one (link)

    • Selected clients (link)

    • All clients (link)

  • Decide what they have access to (authorization)

    • Enable only the data types you want to expose (link)

    • Use privacy rules for fine-grained control over fields and editing rights (link)

Authentication identifies who the client is and authorization determines what they should have access to.
Click the image to see a larger version.