Softr security guide: user groups and data restrictions

By Thunkle · Platform references checked 19 September 2026

Softr portal security depends on both who belongs to each user group and what data that group can access. Page and block configuration should support the permission model, not stand in for a review of the records and actions behind it.

Softr's launch guidance describes global data restrictions at the app level and distinguishes them from block-level conditions. Confirm the controls available in your current plan and configuration before relying on a rule. Softr's official pre-launch walkthrough.

If your portal contains private customer records or operational workflows, our application security audit reviews the agreed configuration and tests the resulting access.

Have a developer test the portal's access lifecycle

A developer review of a Softr portal should connect group membership, global restrictions and connected data workflows. The question is not only what today's user can see, but what happens when they join a company, edit a profile or lose access. Those transitions deserve explicit tests before a portal becomes a place customers trust with private records.

Bring your portal's roles and sensitive workflows to our paid Softr application security review. This developer-led audit produces evidence-backed findings and a practical remediation plan within an agreed scope. Agreed fixes receive a free re-review, while implementation is quoted separately.

Start with a role-and-record map

For each connected table or dataset, identify the groups allowed to view, create, edit and delete records. Include signed-out visitors and newly registered users, not just the staff account used to build the app.

Record which fields determine group membership or customer association and who can change those fields. An editable company name should not accidentally act as proof that a person belongs to that company. Prefer a clearly defined identity and membership process appropriate to the application.

Check onboarding and invitations too. A newly created account should receive the intended initial access, and a removed user should lose the relevant access. Test those transitions rather than checking only stable existing accounts.

Review global restrictions and every way records appear

Use a synthetic supplier portal: suppliers may view their own orders, purchasing staff may amend orders, and finance may approve payment. Viewing an order does not imply permission to change its approval status.

Review the restrictions for each operation. Then inspect lists, detail pages, searches, selection controls, exports and actions that reference the same records. A portal can expose information through a field's available options even if the main list appears correct, so include those surfaces in your acceptance tests without assuming they are currently vulnerable.

Keep public catalogue information separate from private order notes in your requirements. A publicly readable record is not automatically a finding if its fields and audience are intentional.

Test the actual customer journey

Preview tools are useful for checking configuration, but also verify the running experience with dedicated test accounts in an authorized environment. Confirm Supplier A can read A's synthetic order, Supplier B cannot read or modify it, and the permitted purchasing role can make the allowed change.

Retain a successful allowed request as a control. Use existing fixtures and valid sessions, then inspect saved state after a denied write. Test a direct detail link as well as navigation from a list. A hidden button or unavailable page alone does not establish that the underlying operation is protected.

For approval or payment workflows, use a test provider and disposable records. Do not execute real purchases, send customer notices or grant genuine supplier access as casual security tests.

Follow access into the connected data source

A portal's controls and the source's sharing settings are different layers. Review collaborators, shared views, direct database access and integrations that can bypass the intended portal journey.

List workflows that copy data into documents, messages or another application. An authorized read inside the portal can still produce an overly broad export or a document shared with the wrong audience. Inspect the destination and the fields transferred using synthetic data.

Where custom code or an external API is involved, review that path independently. Do not assume a portal permission automatically propagates to a separately hosted backend. Establish how the backend authenticates the caller and restricts the requested records.

Recheck after the portal grows

Adding another group, data source or reusable block can change who encounters a record. Keep a compact regression checklist for the critical read, write, export and lifecycle cases. Document which configuration and release passed it.

Our two-account test explanation is useful for test design, but the downloadable Supabase checker is not a Softr permission tester.

Is hiding a page enough?

It can be part of the user experience. The review must also establish which data and actions the account can actually reach.

When is a professional audit worthwhile?

When a portal has multiple customer organizations, sensitive documents or workflows that create financial or operational consequences. No audit can guarantee the absence of all vulnerabilities.

Get a security audit quote. Share your roles, data sources and launch deadline, not credentials. We agree scope and permitted testing, provide prioritized evidence and remediation guidance, and offer a free re-review of agreed fixes. Implementation can be scoped separately.