Without row-level security, the application loses a clean authorization boundary inside the database. That means data that should be restricted by session state, role, or business context can be returned to the wrong user. The practical failure is overexposure of sensitive fields, because authentication alone does not enforce fine-grained read and write control.
Why Database Authorization Breaks Without Row-Level Security
When Supabase tables are exposed without row-level security, the database stops being the enforcement point for who may see or change a row. That matters because authenticated users still share the same table surface, and unauthenticated users may reach any query path the application leaves open. Authentication only proves who is calling; it does not decide which records are appropriate for that caller.
The result is not just accidental oversharing. It is a structural collapse of authorization boundaries inside the data layer, where session state, tenant context, ownership, and business rules are no longer enforced close to the data. In practice, this is how teams end up debugging a breach-shaped access issue after the application already trusted the database to filter for them.
How It Works in Practice
Row-level security exists to make access decisions per row, based on the caller context and the policy attached to the table. In a Supabase-style application, that usually means the database can distinguish between public access, signed-in access, and access scoped to a specific user, tenant, or role. Without it, the application must rely entirely on upstream query construction and client-side discipline, which is a fragile place to put a trust boundary.
For authenticated users, the common failure is horizontal access: a user can query records that belong to another user, workspace, project, or account because the table itself does not enforce ownership. For unauthenticated users, the failure is broader. Any endpoint, RPC, or overly permissive query path that reaches the table may return rows that were never meant to be public. If writes are exposed too, an attacker or careless client can also create, alter, or delete records outside the intended business context.
The operational problem gets worse when applications mix public content, internal metadata, and privileged fields in the same table. Once the database stops filtering, every downstream consumer has to reproduce the same access logic correctly, consistently, and forever. That is difficult even with mature engineering teams, and it is especially brittle in fast-moving product environments.
NHIMG research shows how often identity and access failures become material: 97% of NHIs carry excessive privileges, which is a useful reminder that “can connect” is not the same as “should access.” For background on the wider NHI exposure problem, see Ultimate Guide to NHIs — Why NHI Security Matters Now.
- Read access becomes a data-exposure problem when policies are absent, incomplete, or only enforced in the application tier.
- Write access becomes an integrity problem when callers can modify rows they do not own.
- Tenant-aware applications are especially exposed because the lost boundary is often not obvious until cross-tenant data appears.
- Public endpoints and unauthenticated users magnify the blast radius because the table is effectively reachable without meaningful row filtering.
These controls tend to break down when multiple client apps, service roles, and ad hoc queries share the same tables because the access logic becomes fragmented and inconsistent.
Common Variations and Edge Cases
Tighter database authorization often adds development overhead, because teams must define policies explicitly and test them alongside schema changes. The tradeoff is worthwhile, but it means the guidance is not “turn it on once and forget it.”
There is no universal standard for every Supabase authorization pattern, but the safest approach is to treat any table that contains tenant data, user data, internal workflow state, or sensitive operational fields as policy-bound by default. Tables that are intentionally public should be designed as public from the start, rather than exposed by omission.
One common edge case is service-to-service access. A backend process may need broader privileges than a normal user, but that should be deliberate and isolated, not inherited from a table that is open to everyone. Another is mixed-sensitivity schemas, where one column is harmless but another is not. In those cases, row-level security still matters, but column separation or view-based access may also be needed to avoid accidental overreach.
Practitioners should also distinguish between “authenticated” and “authorized.” The first proves identity; the second proves entitlement. When those are conflated, a table can look protected while still leaking data to any signed-in user with a valid session.
Risk and Threat Considerations
Exposed tables without row-level security create a direct confidentiality and integrity risk because the database no longer applies a per-row trust boundary. That is especially dangerous for multi-tenant data, sensitive profile data, internal workflow records, and any table that carries identifiers or business state.
Failure mechanism: The control fails when application logic, client queries, or broad database credentials become the only enforcement layer. Attackers and misconfigured clients can then enumerate rows, pivot across ownership boundaries, or submit writes outside intended scope because the table itself does not constrain the result set.
Impact: The likely consequence is data overexposure, tenant crossover, and unauthorised modification of records. At scale, that can become a systemic trust failure because every downstream consumer assumes the database has already enforced the rule.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Exposed tables often pair with over-broad machine access and leaked credentials. |
| Recommendation — Inventory and restrict non-human credentials that can reach exposed tables. | ||
| CIS Controls v8 | 6 — Access Control Management | Missing row-level security is an access control failure at the data layer. |
| 5 — Account Management | Authenticated and unauthenticated paths depend on correct account and session handling. | |
| Recommendation — Enforce least-privilege access rules for every database role and caller path. Review account scopes so no session can query rows beyond its entitlement. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions | Row-level security is the mechanism that constrains access permissions per resource. |
| PR.DS-5 — Data is Protected | Unrestricted table access can expose sensitive data stored in the database. | |
| Recommendation — Apply resource-level permissions that limit each caller to authorised rows. Protect stored data with controls that prevent unintended disclosure. | ||
Practitioner Guidance
What to prioritise: Treat any table reachable by authenticated or unauthenticated clients as unsafe until its row filter is explicit and tested. The first review should focus on tenant-owned data, user-scoped records, and any table mixing public and private fields.
What to verify: Confirm that a caller with a valid session can only see rows it is entitled to see, and that an unauthenticated caller receives only the intentionally public surface. Verify both reads and writes, because many teams test visibility but miss modification paths.
Common mistake: Do not assume authentication middleware, API checks, or client-side filtering will compensate for a missing database policy. If the table can be queried directly, those upstream checks are not a reliable last line of defence.
Practitioner takeaway: The real decision is whether the database is allowed to enforce authorization itself; if it is not, every application path must remain perfectly correct forever, and that is usually the point where exposure begins.
Related resources from NHI Mgmt Group
- What breaks when generated apps rely on public backend keys without row-level security?
- What breaks when row-level security is bypassed by a privileged agent?
- What breaks when row-level security is missing in an AI app?
- What breaks when security tools are exposed to AI coding assistants without guardrails?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
