AI App Builder Audits · AI Development Series
Softr App Audit
Softr puts a decent interface on data you already keep somewhere else. The audit question is what that somewhere else will hand out if asked directly.
What Softr actually hands you
Softr builds client portals, directories and internal apps on top of a data source you already maintain. It is deliberately a front end: it does not hold your data, it presents it.
What a Softr application is made of
- Data source Airtable most commonly, or Google Sheets, Postgres, MySQL
- Application Softr's hosted front end, no exportable code
- Access control User groups and per-block visibility conditions
- Users Softr's own user management, or an external list
- Logic Conditional filters and actions on blocks
- Hosting Softr only
Because Softr is a presentation layer, its security depends on two separate things: what Softr shows, and what the underlying source will give up independently. People almost always check the first and almost never check the second.
The usual arrangement is that Softr connects to Airtable with a key that has access to the whole base. Softr then filters what each user sees. That works, provided nothing else can reach that base — but the key exists, the base is not itself restricted per user, and any other integration, automation or leaked token has the same broad access.
What we consistently find
These are the recurring issues in Softr and Airtable setups.
A connection with access to everything
The token connecting Softr to Airtable typically has full read and write across the base, because narrowing it makes things stop working. All per-user restriction happens in Softr, above that connection.
The base itself therefore has no concept of who is asking. Anything else holding that token — another tool, an automation, a former contractor — sees everything.
What it costs you: one credential exposing the entire base regardless of your portal rules.Visibility conditions doing the work of permissions
Softr blocks can be shown or hidden per user group, and filters can restrict which records a list displays. Whether that is genuine protection or merely presentation depends on how the block and its filters are configured.
The failure mode to look for is a detail page reachable by its address: the list correctly shows only your records, but the individual record page will happily render somebody else's if you navigate to it.
What it costs you: records reachable by anyone who changes an identifier in the address bar.Airtable being asked to be a database
Airtable is a superb spreadsheet-database hybrid and a poor transactional database. It has record limits, rate limits on its API, no enforced relationships and no protection against simultaneous edits.
Portals built on it work beautifully until the base gets large or busy, at which point pages get slow, the API starts refusing requests, and records begin colliding.
What it costs you: a portal that degrades sharply once the base grows.Where Softr is genuinely good
Softr solves a real and common problem: you keep your operational data in Airtable, and you need clients or staff to see part of it without giving them the base. Building that portal by hand is weeks of work that earns you nothing.
Genuinely well suited to
- Client portals over data you already keep in Airtable
- Internal directories and dashboards
- Membership and community sites
- Getting a portal live in days rather than months
- Teams whose operations genuinely run on Airtable
Where it needs engineering behind it
- Portals where users must never see each other's records
- Personal data, health data or financial records
- Bases approaching Airtable's record or rate limits
- Anything needing a real audit trail
- Data with relationships that must stay consistent
The honest summary: Softr is a sensible answer to a real problem, and its weakness is structural rather than a flaw: it can only restrict what it is asked to display. Whether your data is actually protected is a question about the base underneath, which is the part nobody audits.
Prefer to watch? The short version of who we are and how we work
Do you need an audit?
Get it looked at if
- Clients or external users log into the portal
- The base holds personal or commercially sensitive data
- Users must not be able to see each other's records
- Several tools connect to the same Airtable base
- The base has grown large or the portal has slowed down
You are probably fine if
- It is internal and everyone could see the data anyway
- It holds nothing you would mind losing or leaking
- It is read-only over public information
- A handful of trusted colleagues use it
Questions about auditing a Softr build
The risk sits in the connection to your data source. Softr connects with credentials that typically reach everything, then relies on the page to show each user only their part. If the filtering happens in the page, the data has still left your base.
Softr is a capable way to put a client portal in front of data you already keep, and plenty of businesses run real portals on it. The care needed is in the permission model, because the natural way to build one is also the way that leaks.
No, and the difference matters. A visibility condition decides what a page displays. A permission decides what data is allowed to reach the browser at all. Access control built out of visibility conditions produces a portal that looks correct and still sends more than it shows.
It is the most common fault we find. Where list filtering happens after the records have been fetched, the other clients' rows are already in the browser and can be read there, whatever the page chooses to render.
Once permissions are enforced at the data source rather than in the page, and the connection is scoped to what the portal actually needs. If clients can reach each other's records you have a reportable incident rather than a display bug.
For modest volumes and simple structures, often yes. It struggles once you need real relationships, enforced constraints or many concurrent users, because it is a spreadsheet-shaped product being asked to behave like a database. The portal usually outgrows the base before it outgrows Softr.
Tightening permissions and scoping the connection is usually quick. Moving the underlying data to a proper database is the larger piece. The audit is £495 + VAT and separates the urgent from the eventual. Credited back in full if we then do the work.
It is the right start, but it only covers what the portal does. The question we also ask is what the Airtable base would return to anything else holding the connection token, and whether an individual record page can be reached directly by changing an identifier. Those are the two gaps that portal-level filtering does not close.
View access to the Softr application so we can see the blocks, user groups and filters, and read access to the Airtable base or database behind it. We do not need write access and we will not change anything.
No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not Softr expertise, it is that the thing being audited is a data source, a set of credentials and a permission model, which is what we have been working with for years.
Built with something else?
We audit what these tools produce, whichever one you used.
Other AI app builders
- Lovable app audit
- Emergent app audit
- Replit app audit
- UI Bakery app audit
- Bolt app audit
- v0 app audit
- Base44 app audit
- Firebase Studio app audit
- Databutton app audit
- Rork app audit
- a0.dev app audit
- FlutterFlow app audit
- Bubble app audit
- Glide app audit
- Adalo app audit
- Retool app audit
- Appsmith app audit
- Budibase app audit
- ToolJet app audit
- Xano app audit
- Airtable app audit
The audit
Find out what you are sitting on
The AI Code Audit is £495, fixed.
Tell us roughly what you built and how many people use it. If an audit is not the right thing for you, we will say so.
What the report covers:
- What the underlying base exposes to anyone holding the connection
- Whether portal filtering is protection or only presentation
- Whether individual records can be reached directly
- Whether your data source will hold up as it grows
We reply within one working day.
