Airtable Security Hardening Guide

A step-by-step guide to securing your Airtable bases, views, and integrations. Airtable is powerful but has a unique security model that catches many builders off guard: it wasn't designed as an application backend, so the security controls are different from what you'd expect in a traditional database.

Time estimate: 45–60 minutes for a typical base with 5–15 tables.

Understanding Airtable's Security Model

Airtable's security operates at three levels. Most builders only configure level 1 and leave levels 2 and 3 wide open:

Level 1: Account Security
  Who can log into your Airtable workspace?
  → MFA, SSO, password policy

Level 2: Base & Table Access
  Who can see and edit which bases and tables?
  → Workspace roles, base sharing, table permissions

Level 3: Record & Field Access
  Who can see which records and fields?
  → Views, Interfaces, API proxying
  → Airtable does NOT have row-level security (this is the big gap)

The critical thing to understand: Once someone has access to a base (as editor or above), they can see every record in every table in that base. There is no native row-level security. If you need users to see only their own records, you must use Views, Interfaces, or an API proxy — not direct base access.

Step 1: Workspace Account Security

1.1 Workspace Admin Settings

1. Enforce MFA for all workspace members

• Go to your workspace → Settings → Authentication
• Enable "Require two-factor authentication"
• This forces every member to set up MFA before accessing any bases

2. Set up SSO (Enterprise plan only)

• If your organization uses an identity provider (Okta, Azure AD, Google Workspace), configure SAML SSO
• SSO centralizes authentication and makes offboarding instant — disable the IdP account and Airtable access is gone

3. Review workspace members quarterly

• Go to Workspace → Members
• Remove anyone who no longer needs access
• Audit who has Owner vs. Creator vs. Editor roles

1.2 Individual Account Security

• [ ] Each team member uses a unique email (no shared accounts like team@example.com)
• [ ] Each team member has MFA enabled on their Airtable account
• [ ] Airtable password is unique (not reused from other services)
• [ ] Recovery email set and accessible
• [ ] Browser session reviewed — log out from unused devices

Step 2: Base-Level Security

2.1 Base Sharing Settings

This is where most Airtable security fails. Check every base:

1. Open your base → Share → Base sharing link

• Is the "Create a shared link to the whole base" toggle ON?
• If yes: anyone with the link can view your entire base. Turn this OFF unless you have a specific reason.
• A shared base link with "Editor" access means anyone with the URL can modify your data.

2. Review individual base shares

• Who has direct access to the base? (Listed under the Share menu)
• Remove any external collaborators who no longer need access
• Downgrade permissions where possible (does that person really need Editor, or would Commenter work?)

3. Check workspace-level access inheritance

• Workspace Owners can see all bases in the workspace
• If you have sensitive bases, consider a separate workspace for them

Base Permission Levels:

2.2 Shared Views

Shared views are safer than shared bases because they restrict what the recipient can see:

• [ ] Use shared views (not base shares) for external stakeholders
• [ ] Each shared view shows only the fields and records that recipient needs
• [ ] Shared view links reviewed quarterly — remove any that are no longer needed
• [ ] Grid views used for shared views do not have hidden fields with sensitive data (hidden fields in a shared view are still accessible via the Airtable API)
• [ ] Form views do not expose field names that reveal internal processes

2.3 Interface Access

Airtable Interfaces are the safest way to give users access to specific data:

• [ ] Interfaces used instead of direct base access for non-technical users
• [ ] Interface permissions set to restrict which records each user group can see
• [ ] Interface forms validate input (required fields, field types)
• [ ] Interfaces tested with a non-admin account to verify visibility restrictions

Step 3: API Security

Airtable's API is the biggest security risk for most Airtable-backed applications.

3.1 Personal Access Tokens (PATs)

Airtable deprecated the old single API key in favor of Personal Access Tokens. If you're still using the old API key, migrate immediately.

1. Create scoped tokens

• Go to airtable.com/create/tokens
• Create a separate token for each integration / use case
• Scope each token to: specific bases (not "all bases"), specific permission levels (read-only if possible)

2. Token hygiene

• [ ] One token per integration (not a shared token for everything)
• [ ] Each token scoped to the minimum bases and permissions needed
• [ ] Tokens named descriptively (e.g., "Website Contact Form - Write to Leads base only")
• [ ] Token creation date and purpose documented
• [ ] Unused tokens deleted

3.2 API Exposure Prevention

The most common Airtable security incident: a PAT is exposed in client-side code, giving anyone full access to the base.

• [ ] [CRITICAL] Airtable PAT never included in client-side JavaScript (browser-accessible code)
• [ ] [CRITICAL] Airtable PAT never included in URL parameters
• [ ] If your frontend needs to read/write Airtable data, use a backend proxy (a server-side function that holds the PAT and forwards requests)
• [ ] Airtable PAT not committed to version control (add to .gitignore or use environment variables)
• [ ] Airtable PAT not visible in no-code platform workflow logs

Correct Architecture for Web Apps Using Airtable:

WRONG (insecure):
  Browser → [PAT in JavaScript] → Airtable API
  Risk: Anyone can read the PAT from your page source

RIGHT (secure):
  Browser → Your Backend/Serverless Function → [PAT on server] → Airtable API
  The PAT never leaves the server

Backend options for no-code builders:

• Xano — API backend with Airtable connector
• Supabase Edge Functions — Serverless functions
• Make/Zapier — Webhook → Airtable (PAT stored in the connection, not exposed)
• Val Town — Quick serverless functions
• Cloudflare Workers — Serverless proxy (some coding required)

Step 4: Automation Security

4.1 Airtable Automations

• [ ] Each automation reviewed for unintended triggers (could a user manipulate a field to trigger the automation inappropriately?)
• [ ] Automations that send data externally (email, webhook, Slack) reviewed for data minimization
• [ ] Automations that modify data have error handling (what happens when the "Update record" step fails?)
• [ ] Automation run history reviewed monthly for unexpected executions
• [ ] Test automations cleaned up (no "Test" automations left running in production bases)

4.2 Scripting Extension Security

If you use the Scripting extension:

• [ ] Scripts do not hardcode API keys or secrets
• [ ] Scripts that access external APIs use the fetch function with HTTPS only
• [ ] Scripts reviewed for unintended data exposure (e.g., console.log of sensitive data)
• [ ] Script outputs do not include more data than the user running the script should see

Step 5: Data Protection

5.1 Sensitive Data Handling

Airtable is not designed for highly sensitive data (healthcare records, financial data under PCI scope). If you must store moderately sensitive data:

• [ ] Sensitive fields identified and documented
• [ ] Field descriptions used to mark sensitive fields (helps other collaborators understand handling requirements)
• [ ] Sensitive fields hidden from views that don't require them
• [ ] Attachments with sensitive content have view links that expire (not permanent URLs)
• [ ] Revision history considered — deleted field values may be recoverable via revision history

5.2 Backup Strategy

• [ ] Regular CSV exports of critical tables (weekly minimum)
• [ ] Exports stored securely (encrypted storage, not an open Google Drive folder)
• [ ] Backup restoration tested (can you recreate the base from CSVs?)
• [ ] Third-party backup service considered for critical bases (On2Air Backups, Miniextensions backup, or API-based export scripts)

Step 6: Compliance Considerations

GDPR-Specific Items for Airtable

• [ ] Data Processing Agreement (DPA) signed with Airtable (available at airtable.com/dpa)
• [ ] Airtable's data residency noted — data is stored in the US by default (Enterprise plan offers data residency options)
• [ ] Process exists to fulfill data subject access requests (export a specific person's data)
• [ ] Process exists to fulfill data deletion requests (find and delete all records for a specific person across all tables)
• [ ] Cookie consent handled if embedding Airtable forms or views on your website

Hardening Checklist Summary

*See also: ../checklists/secrets-management.md for API key storage best practices, and data-privacy-and-compliance.md for GDPR compliance details.*

Bubble Security Hardening Guide

A step-by-step guide to securing Bubble applications. Bubble is one of the most powerful no-code platforms, but its flexibility means there are many places where security can go wrong. Privacy Rules are the heart of Bubble security — if they're misconfigured, your entire database is exposed.

Time estimate: 1–2 hours for a typical Bubble app with 5–15 data types.

Understanding Bubble's Security Model

Bubble's security operates on three layers. Layer 2 (Privacy Rules) is where 90% of security failures happen:

Layer 1: App-Level Security
  Deployment settings, SSL, API access, debug mode
  → Configured in Settings tabs

Layer 2: Data-Level Security (Privacy Rules)
  Who can see / find / modify / delete each data type
  → Configured per data type in the Data → Privacy tab
  → THIS IS THE MOST IMPORTANT LAYER

Layer 3: Page & Workflow Security
  Who can access which pages, who can trigger which workflows
  → Configured in page settings and workflow conditions

The most dangerous default: A data type without Privacy Rules is visible to everyone, including unauthenticated users. If you create a User data type and don't add Privacy Rules, anyone can query the Bubble API and retrieve every user's data — email, name, everything.

Step 1: Privacy Rules (Do This First)

Privacy Rules are Bubble's row-level security. Every data type in your app MUST have at least one Privacy Rule.

1.1 Audit Existing Privacy Rules

1. Go to Data → Privacy tab

2. For each data type, check:

• Does it have at least one Privacy Rule? If not, add one immediately.
• Is the default (when no rules match) to deny access? It should be.

3. The correct mental model: deny all, then allow specific access

1.2 Privacy Rule Configuration

For each data type, configure:

• [ ] Who can view — which users can see records of this type?
• [ ] Who can find in searches — which users can find these records via search/filter?
• [ ] Which fields are visible — even if a user can view the record, can they see all fields?
• [ ] Who can modify — which users can edit records?
• [ ] Who can delete — which users can delete records?

Common Privacy Rule Patterns:

Pattern 1: Users can only see their own data
  Rule: "Current User is this thing's Creator" or "Current User is this thing's owner"
  → Allow view, find, modify for matching users
  → Deny everything for non-matching users

Pattern 2: Team members can see team data
  Rule: "Current User's team is this thing's team"
  → Allow view and find for team members
  → Allow modify only for the record's creator or team admin

Pattern 3: Public content (blog posts, product listings)
  Rule 1: "Everyone" — Allow view and find, deny modify and delete
  Rule 2: "Current User is Admin" — Allow everything

Pattern 4: Sensitive records (payments, private messages)
  Rule: "Current User is this thing's sender OR Current User is this thing's recipient"
  → Allow view only for involved parties
  → Deny find in searches (prevent enumeration)
  → Deny modify and delete for everyone (use workflows for state changes)

1.3 Privacy Rule Testing (Critical)

After configuring Privacy Rules, test them thoroughly:

1. Log in as a regular user (not the admin/developer account)

2. Try to access data that shouldn't be visible:

• Use the browser URL bar to navigate to data pages
• Check if search results leak data from other users
• Verify that hidden fields are actually hidden (not just visually hidden)

3. Use Bubble's "Run as" feature (if available on your plan) to impersonate different user roles

4. Test the API directly:

• Open: https://YOUR-APP.bubbleapps.io/api/1.1/obj/YOUR-DATA-TYPE
• If this returns data when you're not logged in, your Privacy Rules are wrong

Step 2: API Security

2.1 API Workflow Security

• [ ] Data API exposure reviewed: Settings → API → check which data types are exposed via the API
• [ ] Only data types that need external API access are enabled
• [ ] API workflows that modify data require authentication
• [ ] API workflows validate all input parameters (type, length, allowed values)
• [ ] API workflows have rate limiting configured (Settings → API → Rate limiting)

2.2 API Connector (Outgoing API Calls)

• [ ] API keys stored in the API Connector with the "Private" checkbox checked
• [ ] Private keys never referenced in client-side expressions
• [ ] API calls use HTTPS exclusively
• [ ] API call responses validated (handle error responses gracefully)
• [ ] Unused API connections removed

Private vs. Non-Private in the API Connector:

2.3 GraphQL Introspection

Bubble uses GraphQL under the hood. On development/test versions:

• [ ] Introspection queries not accessible on live version (they expose your entire data schema)
• [ ] Development version has different access controls than live version
• [ ] API documentation endpoint not publicly accessible unless intentional

Step 3: Page-Level Security

3.1 Page Access Control

• [ ] Admin pages have a "Page is loaded" workflow that checks Current User's role is admin, and redirects to the login page if not
• [ ] The redirect happens in a "Page is loaded" event, not just conditional visibility
• [ ] Direct URL access to admin pages is blocked (test: paste the admin page URL in an incognito window)
• [ ] Login page doesn't redirect authenticated users back to admin pages they shouldn't access
• [ ] 404/error pages don't reveal internal page names

3.2 Conditional Element Visibility vs. Security

Important distinction: Hiding an element with a conditional is NOT security. It's UX convenience.

WRONG (insecure):
  "Only show this admin button when Current User's role is admin"
  → The button is hidden, but the workflow behind it still works
  → An attacker who knows the workflow can trigger it via browser tools

RIGHT (secure):
  1. Conditional: hide the button for non-admins (UX convenience)
  2. ALSO: Add a condition to the workflow: "Only when Current User's role is admin"
  3. ALSO: Privacy Rules prevent non-admins from accessing the data the workflow uses
  → Three layers: UI, workflow, data

• [ ] Every admin-only button/link has BOTH a visibility conditional AND a workflow-level permission check
• [ ] Data-modifying elements have workflow-level role checks (not just UI-level hiding)
• [ ] Forms validate that the current user has permission to submit (at the workflow level)

Step 4: Deployment & Environment Security

4.1 Development vs. Live

• [ ] [CRITICAL] Live version deployed from a tested development version (not edited directly in live)
• [ ] Development version has test data, not real user data
• [ ] Development version is not accessible to end users (Bubble's dev URL: YOUR-APP.bubbleapps.io/version-test)
• [ ] Debug mode disabled on the live version (Settings → General → uncheck "Expose debug data to users")
• [ ] Server logs reviewed for errors before deploying to live

4.2 Debug Mode

Debug mode is the single biggest information leak in Bubble apps:

• [ ] [CRITICAL] "Expose debug data to users" is UNCHECKED for the live version
• [ ] Verified: appending ?debug_mode=true to the live URL does NOT show the debugger
• [ ] If debug mode was previously enabled: assume that advanced users may have inspected your data structure

What debug mode exposes:

• Every database query and its results (including fields hidden in the UI)
• Page load performance data with internal field names
• Workflow execution details
• API call details including response data
• Privacy Rule evaluation results

4.3 Custom Domain & SSL

• [ ] Custom domain configured (instead of YOUR-APP.bubbleapps.io)
• [ ] SSL certificate active and auto-renewing
• [ ] HTTP redirects to HTTPS
• [ ] Domain registrar account secured with MFA
• [ ] Old/test subdomains removed from DNS

Step 5: Authentication Configuration

5.1 Signup & Login Settings

• [ ] Password minimum length set (Settings → General → minimum 10 characters)
• [ ] Email verification required for new signups
• [ ] Password reset email doesn't reveal whether an email exists in the system
• [ ] Login page rate-limited (consider adding a CAPTCHA plugin for public-facing login pages)
• [ ] "Remember me" session duration reasonable (default is 365 days — consider reducing for sensitive apps)

5.2 OAuth/Social Login

• [ ] OAuth providers configured in Settings → General → OAuth
• [ ] OAuth client secrets stored securely (Bubble handles this, but verify)
• [ ] OAuth scopes limited to what's needed (email + profile is usually sufficient)
• [ ] OAuth callback URLs configured correctly (no wildcards)
• [ ] Login workflows handle both "new user" and "returning user" OAuth flows

Step 6: Plugin Security

6.1 Plugin Audit

Bubble plugins run third-party code in your app. Each plugin is a potential security risk:

• [ ] All installed plugins inventoried (Settings → Plugins)
• [ ] Each plugin reviewed: does it still serve a purpose? Remove unused plugins.
• [ ] Plugin permissions reviewed: what data does each plugin access?
• [ ] Plugin author/publisher evaluated: is this from a reputable developer?
• [ ] Plugin updates applied (outdated plugins may have known vulnerabilities)
• [ ] Free plugins from unknown authors treated with extra caution (review their changelog and support forum)

Plugin Risk Assessment Questions:

1. Does this plugin have access to user data? (Authentication plugins, form plugins)

2. Does this plugin make external API calls? (Analytics, tracking, payment plugins)

3. Does this plugin inject JavaScript into the page? (UI enhancement plugins)

4. Is there a native Bubble feature that could replace this plugin?

5. When was this plugin last updated?

Step 7: Performance & Abuse Prevention

7.1 Rate Limiting & Abuse

• [ ] Public-facing forms have CAPTCHA (Google reCAPTCHA plugin or similar)
• [ ] Signup rate limited (prevent bot account creation)
• [ ] File upload size limited (Settings → General)
• [ ] File upload types restricted (no executable files: .exe, .bat, .sh, .js)
• [ ] Public search endpoints don't allow unrestricted queries (paginate results, limit result count)
• [ ] Bulk data export workflows restricted to admin roles

Hardening Checklist Summary

*See also: ../checklists/auth-and-authorization.md for deeper authentication patterns, and ../checklists/api-and-webhook-security.md for API security details that apply across platforms.*