Most of what I write about involves code-generating tools: Lovable, Bolt, Cursor, and similar. A different, equally common category deserves its own look: no-code database and app tools like Airtable, Glide, or Notion, used to turn a spreadsheet-like table into something closer to a real internal app. They have their own specific security shape, and it's less talked about than the code-generation tools' issues, partly because the risk here isn't about code at all.
What makes these tools genuinely useful
These platforms let someone build a functional database-backed view, a client tracker, an inventory list, a booking system, without writing any code, often by generating a shareable link or a lightweight app interface directly from the underlying table. That accessibility is the whole point, and it's genuinely valuable for a huge range of small business needs.
Where the risk actually lives
The core mechanism in most of these tools is a shared view or a public link into some subset of the underlying data. The setting that controls how much of that data a given link actually exposes is often more permissive by default than people realize, and because there's no code to review, no obvious "file" to check for a leaked key, the risk hides inside a settings panel instead of a codebase. A view meant to show a client their own booking status can, depending on how the filter and sharing settings were configured, sometimes expose far more of the underlying table than intended, other clients' bookings, internal notes, fields that were never meant to be part of the shared view at all.
Why this is easy to get wrong specifically in these tools
- A shared link is often generated with a single click, and the exact scope of what it exposes isn't always obvious from the interface without deliberately checking.
- Fields added to the underlying table after a share link was created don't always automatically stay excluded from that link, depending on the platform and how the view was configured.
- Permissions on these platforms are usually per-view or per-base, and it's easy to have several different links floating around with inconsistent scopes, since each one was created at a different point for a different purpose.
- Because there's no 'admin route' or 'API endpoint' in the traditional sense, the mental model of 'check if a URL requires login' doesn't map cleanly, and it's easy to assume a shared link is safer than it actually is simply because the tool feels more contained than a full custom app.
What's actually worth checking
- Open every active shared link or public view your team currently has generated, and check exactly what data and fields it actually exposes, not what you assume it shows.
- Confirm whether a link requires any form of authentication or is fully public to anyone who has the URL, and treat any fully public link as something that could be found by anyone, the same as a URL on the open web.
- Periodically audit which links still exist and are still needed, the same way you'd audit any other standing access, since these tools make it easy to generate a link and easy to forget it exists.
No-code tools didn't remove the underlying security questions. They just moved them from a codebase into a settings panel, which makes them easier to overlook precisely because there's no code to point at and say "this is the risky part." The risky part is a checkbox, and it's worth actually clicking through to find it.