Is Airtable Safe? Security Review for Builders and Teams (2026)

Airtable processed a data exposure in December 2022 when a third-party analytics vendor leaked customer email addresses. Airtable itself was not breached, but the incident highlighted what many teams building on Airtable miss: the platform's security is solid at the infrastructure level, but the access model has sharp edges that require active configuration.

This review covers what Airtable does well, where it falls short, and the specific settings you need to check before storing anything beyond spreadsheet-equivalent data.

What Is Airtable?

Airtable is a cloud database platform used by teams to manage records, workflows, and data pipelines. Builders increasingly use it as a backend for internal tools and Softr apps, via its REST API. It is SOC 2 Type II certified and runs on AWS with encryption at rest (AES-256) and in transit (TLS 1.2+).

Our Verdict

The Share Link Problem

Airtable's most common security failure has nothing to do with infrastructure. It's the share link sent in a Slack message.

When you share a View, Airtable generates a URL like https://airtable.com/shrXXXXXXXXXXXXXX. Anyone with that URL can see every record in that view. There is no login prompt, no expiry, and no revocation notification if the link gets forwarded. The only way to stop access is to delete the link.

If your view contains customer names, emails, phone numbers, or financial data, that share link is a data breach waiting to happen.

API Key Exposure: Airtable's Most Common Real-World Incident

Airtable deprecated legacy API keys in February 2024 and migrated users to Personal Access Tokens (PATs). The reason: legacy keys were base-wide credentials with no scope controls. A leaked key gave full read-write access to every base the workspace owner could see.

PATs are a meaningful improvement. You choose which bases the token can access and what permission level it has (commenter, editor, creator). A leaked read-only PAT scoped to one base limits the blast radius significantly.

But PATs are still commonly mishandled:

• Hardcoded in frontend JavaScript (visible in browser DevTools)
• Committed to public GitHub repos (GitHub's secret scanning catches this, but only after the push)
• Stored as plain text in .env files that get committed when .gitignore is misconfigured

// DO NOT DO THIS
const AIRTABLE_PAT = 'patXXXXXXXXXXXXXX.XXXXXXX';
const response = await fetch(`https://api.airtable.com/v0/${BASE_ID}/${TABLE}`, {
  headers: { Authorization: `Bearer ${AIRTABLE_PAT}` }
});

// server-side only (e.g., Vercel serverless function, Node.js backend)
const AIRTABLE_PAT = process.env.AIRTABLE_PAT; // set in your hosting env vars
const response = await fetch(`https://api.airtable.com/v0/${BASE_ID}/${TABLE}`, {
  headers: { Authorization: `Bearer ${AIRTABLE_PAT}` }
});

HIPAA and Compliance Limits

Airtable's compliance coverage by plan:

HIPAA requires a signed Business Associate Agreement (BAA). Airtable only signs BAAs with Enterprise Scale customers. If you are building for healthcare, do not store Protected Health Information (PHI) in Airtable unless you are on Enterprise Scale with a signed BAA.

The same applies to financial data subject to PCI DSS: Airtable is not a PCI-compliant datastore and should not be used to store raw card numbers or sensitive cardholder data on any plan.

No Row-Level Access Control

This is the structural limitation that surprises most builders: Airtable has no native row-level access control inside a base.

If you give User A "Editor" access to a base, User A can see and edit every record in every table. You cannot configure policies like "user sees only records where email = their email." The only workaround is:

1. Separate bases per user or per data segment (operationally painful)
2. Build your own API proxy that filters records before returning them (requires backend development)
3. Use a platform like Softr that adds a user-context layer on top of Airtable (but Softr's security depends on correct configuration there)

If your use case requires per-user data isolation, Airtable's native sharing model is not the right tool. Consider Supabase (which has Row Level Security) or a traditional database.

Airtable Automations and Script Security

Airtable automations can run custom JavaScript via the "Run a script" action. These scripts execute on Airtable's infrastructure and can access base records, call external APIs, and send HTTP requests.

Key security considerations:

• Scripts run with the permissions of the user who created the automation, not the user who triggered it
• External API calls from scripts can embed secrets in the script code itself (visible to any base collaborator with creator access)
• There is no secrets manager built into Airtable automations; secrets in script code are stored as plain text in the automation config

If your automations call external services, avoid embedding API keys directly. Use a serverless function or proxy as the intermediary, and pass only non-sensitive identifiers from the automation.