TL;DR
A Softr app is only as secure as the Airtable base behind it. Two settings do most of the work: user groups decide who belongs where, and block visibility decides what each group actually receives. Get those wrong and the data still reaches the browser. And think hard before putting anything genuinely sensitive in Airtable; it wasn't built to hold it.
How Softr Security Works
Softr is a front end for an Airtable base. Four pieces carry the security weight:
- Airtable connection: Uses API key to read/write data
- User authentication: Built-in user management
- Visibility rules: Control what users see
- User groups: Role-based access control
Airtable Security
Whatever Airtable is, your app is too. That inheritance runs in both directions.
API Key Security
- Softr stores your Airtable API key/token
- Give Softr its own Airtable user, not your own
- Scope that user to the bases it actually needs
- Rotate API keys periodically
Airtable Base Configuration
- Don't store passwords or highly sensitive data
- Airtable isn't designed for HIPAA/PCI compliance
- Assume someone you didn't intend will read the base, and plan from there
Important: Airtable is a spreadsheet with an API. It's not a vault. Passwords, SSNs and card data need encryption and a compliance story Airtable alone won't give you.
User Authentication
Softr ships its own user management. The defaults are permissive, so walk through them.
User Groups
- Create groups for different access levels
- Assign users to appropriate groups
- Use group-based visibility rules
- Regularly review group memberships
Authentication Settings
- Enable email verification
- Configure password requirements
- Set appropriate session timeouts
- Consider enabling Google/social login with MFA
Visibility Rules
Visibility rules are where most Softr access-control bugs live.
Block-Level Visibility
- Configure visibility for each block
- Filter data by logged-in user
- Use conditions to show/hide content
- Don't rely on hiding alone for security
Page-Level Access
- Restrict pages to specific user groups
- Configure redirect for unauthorized users
- Test access with different user types
Testing tip: Make a test account in every user group and log in as each one. Read the network tab, not just the page. That gap is what bites: the row is gone from the view and still sitting in the JSON behind it.
Data Filtering Best Practices
- Filter lists by user email or user ID
- Use linked records for ownership relationships
- Always filter at the query level, not just UI level
- Test filters with different user accounts
Security Checklist
- Dedicated Airtable account for Softr connection
- User groups configured for access control
- Visibility rules on all blocks with sensitive data
- Page access restricted by user group
- Email verification enabled
- No highly sensitive data in Airtable
- Testing completed with different user types
Is Softr secure for business applications?
It can be, once it's configured. What decides it is your Airtable base permissions, your Softr visibility settings and your user groups. For anything sensitive, set conditional visibility and user permissions rather than leaving the defaults.
Can users see data they shouldn't in Softr?
Yes, if you haven't set it up. Visibility rules and user groups are what filter the data. Hiding a block in the UI isn't filtering. The records still travel. Filter so the unauthorized rows never leave Airtable.
How does Softr connect to Airtable?
Through an API key or personal access token, which carries the permissions of whichever Airtable user issued it. Give Softr its own account, scoped to the bases it needs, so a leaked token doesn't expose your whole workspace.
Is Airtable secure enough for my data?
Airtable is secure for general business data. For highly sensitive data (PII, financial, health), consider whether Airtable meets your compliance requirements. Don't store passwords or unencrypted sensitive data.
Building with Softr?
Make sure your app is properly secured.