External Publication

Row-Level Security Failures in SaaS Multi-Tenancy

StackRundown June 26, 2026

A single RLS mistake can expose one customer’s data to another. In a shared-schema SaaS app, that usually happens because a table has no policy, a policy is wrong, a privileged role skips RLS, or pooled connections carry the wrong tenant context.

Here’s the short version:

Atenant_id column is not enough. If RLS is off or partial, rows are still open.
Common failure points include side tables, background jobs, BI tools, admin paths, and connection pooling.
PostgreSQL can skip RLS for table owners, superusers, and roles with BYPASSRLS unless you lock that down.
Testing matters as much as setup. I’d treat cross-tenant negative tests as release blockers.
The business risk is high. The article cites an average global breach cost of $4.88 million , plus HIPAA, SOC 2, contract, and sales risk.
Safer patterns include FORCE ROW LEVEL SECURITY, least-privilege app roles, SET LOCAL in transactions, and direct SQL tests with two seeded tenants.

If I were checking a SaaS vendor or my own stack, I’d ask three things right away:

Does any app, job, tool, or admin role bypass RLS?
Are exports, reports, queues, search, and support tools covered too?
Can Tenant A ever reach Tenant B’s rows in CI/CD or direct SQL tests?

The main point is simple: RLS is not something I’d trust just because it’s turned on. I’d want proof that policies, roles, and tenant context hold up across every data path.

Shipping Production-ready Multi-tenant SaaS with Postgres RLS

sbb-itb-fd683fe

How Row-Level Security Fails in Shared-Schema SaaS Systems

RLS Bypass Paths vs. Multi-Tenant Isolation Models: SaaS Security at a Glance

RLS usually breaks because of setup mistakes and day-to-day ops gaps, not because the feature itself is broken. A tenant_id column alone doesn't protect anything if enforcement is missing, partial, or easy to sidestep. The core risk isn't the tenant ID. It's the gap between the data model and the way RLS is put into use.

Missing or Incomplete Policies on Multi-Tenant Tables

In PostgreSQL, a tenant_id column does nothing on its own unless RLS is turned on for that table. If RLS is not explicitly enabled, every row stays open to anyone with access, even if the schema looks tenant-aware.

This problem shows up most often on secondary tables like audit logs, event logs, and notification queues. Teams lock down the main tables, then ship new support tables during a fast product push and forget to add policies. It’s a classic weak spot.

Another common miss: teams add read policies first and leave writes exposed. That means one tenant may be able to insert or update rows tied to another tenant’s data set.

Misconfigured Predicates and Unsafe Exceptions

Even when a policy exists, the rule itself can undercut the whole setup. One of the best-known examples is the table owner bypass. By default, PostgreSQL does not enforce RLS for the table owner or for superusers. So if the app connects as the table owner - which is common in smaller setups - PostgreSQL quietly skips all RLS policies unless FORCE ROW LEVEL SECURITY is turned on.

Roles with BYPASSRLS skip RLS too. Teams often create these roles for migration tools or backup scripts. That can seem harmless at first. But if that same role ends up serving app traffic, tenant isolation disappears.

There’s also a performance angle. Some policies rely on subqueries to check group membership or permissions. At scale, those checks can get slow, and under pressure, teams may decide to work around RLS on busy tables instead of fixing the policy. That’s where things start to go sideways.

Bypass Paths Outside Normal App Flows

RLS also falls apart when data access happens outside the main app request path. Background jobs are a steady source of trouble. A queue worker often runs without request-level tenant context, so it may operate with a missing or stale tenant value and touch rows across tenants.

Connection pooling adds another risk. In PgBouncer transaction mode, session variables set with SET can leak into the next use of that connection. If the connection is not reset the right way between tenants, the next request can inherit the last tenant’s context. The safer pattern is SET LOCAL inside an explicit transaction, but that detail is easy to miss.

Bypass Path	Why RLS Doesn't Help	Common Example
Background jobs	No tenant context is set in the worker session	Nightly export runs against all tenants
Connection pooling (transaction mode)	Session variable bleeds to the next tenant	PgBouncer reuses a connection without reset
Admin/support tooling	Elevated role with `BYPASSRLS` or table owner privileges	Internal dashboard with global data access
BI connectors / direct SQL	Bypasses ORM filters entirely	Analyst queries shared-schema tables directly

Any direct database access path, including BI tools, still needs database-level RLS. Without it, shared-schema tables can expose every tenant. And once another tenant’s rows are exposed, this stops being just a bug. It becomes a data protection and compliance problem.

What RLS Failures Mean for Data Protection, Compliance, and Trust

Cross-Tenant Exposure as a High-Impact Isolation Failure

An RLS failure isn't just a database bug. It breaks the tenant isolation promise that SaaS depends on.

When that wall fails, users can end up seeing the wrong row counts, cross-tenant exports, or child records that belong to another tenant. Research has found dashboard drift, nested-data leaks from eager loading, and export or reporting paths that skip live-app filters.

At that point, the problem stops being a simple access-control issue. It becomes regulated data exposure.

U.S. Compliance and Financial Risk

If those leaks hit production data, the risk turns legal and contract-related fast, not just technical. For U.S. SaaS companies, cross-tenant exposure can trigger state breach notices, HIPAA duties, and SOC 2 findings because app-layer filtering depends on developer discipline instead of database enforcement.

The dollar impact is hard to ignore. The average global breach cost reached $4.88 million. Moving from a shared schema to schema-per-tenant can take 5 to 7 weeks. Rebuilding multi-tenancy can take up to 6 months.

There’s also the deal risk. Enterprise contracts often spell out data-isolation requirements, and a failed security review can sink a sale or lead to a breach-of-contract claim.

That’s why isolation design and cross-tenant testing move up the list fast. Once trust slips, the damage doesn’t stay inside the database.

How to Reduce RLS Risk: Mitigation Patterns and Testing Methods

These failures need controls at the policy, request, and query levels.

Isolation Patterns That Reduce RLS Risk

The research points to layered tenant isolation: database enforcement, request context, and query validation.

At the database layer, use ALTER TABLE ... FORCE ROW LEVEL SECURITY so the table owner can't skip RLS checks. Pair that with a least-privilege application role that does not have policy-bypass rights, and keep a separate superuser role ONLY for migrations.

For request context, derive tenant identity from a signed JWT claim or a verified ingress header. Bind it once per request with withTenantContext, then use SET LOCAL inside transactions so pooled connections don't carry old tenant context into the next request.

At the query-validation layer, parse AI-generated SQL and reject any query that does not include a tenant predicate before it runs.

The isolation model you choose depends on customer risk, regulatory exposure, and what your team can safely run day to day:

Approach	Security Strength	Best Fit
Shared-Schema RLS	High (Logical)	SMB / B2C SaaS
Schema-per-Tenant	Very High (Schema Boundary)	Mid-market / Regulated
Database-per-Tenant	Maximum (Physical)	Enterprise / High-security

SOC 2 and HIPAA auditors have increasingly flagged application-layer filtering as a high-risk control. That makes database-enforced RLS easier to defend as proof of data separation during compliance reviews.

How Teams Test for Cross-Tenant Access Failures

Once the controls are in place, test the same bypass paths that caused the failures.

These controls still need negative tests in CI/CD and direct SQL checks before release.

A reliable setup is to seed two test tenants in CI/CD and write negative tests where Tenant A tries to access Tenant B's resources. If any of those requests succeed, treat it as a release-blocking failure. For cross-tenant requests, return a 404 Not Found.

Direct SQL policy checks matter just as much. In a test environment, manually set tenant context with SET LOCAL app.current_tenant_id = '...' and then try to query another tenant's rows. That shows whether the RLS policy works on its own, without help from app-layer filters.

Teams also run EXPLAIN ANALYZE with RLS enabled to confirm that policies use composite indexes, with tenant_id as the leading column, instead of dropping into full table scans.

Analytics and AI-generated queries need their own tests as separate access paths. Don't assume they inherit the same controls as the main app. Research specifically flags embedded dashboards and AI-generated reports as routes that often bypass application-level authorization.

For AI agents and autonomous workflows, test delegation chains to make sure sub-agents use scoped-down tokens instead of master credentials. Teams also use property-based tests to generate random resource IDs and hammer on cross-tenant access paths.

Conclusion: What Founders and SaaS Buyers Should Take From the Research

Put all of this together, and the message is pretty clear: buyers should treat RLS as a control to test , not a label to trust. In backend-as-a-service stacks, RLS may be the last layer standing between tenant data and direct database access.

The ways it fails are often pretty ordinary. A team adds a new table and forgets the policy. Or an AI-generated policy looks fine at a glance but is loose enough to allow everything. In some cases, a policy can look enabled while still exposing all rows.

And policy design, by itself, doesn't solve the whole problem. Isolation also has to hold up outside the request path, including background jobs, webhooks, reporting, caching, and search.

Key Takeaways for Evaluating SaaS Data Isolation

For buyers and founders, the practical check is simple. Before you trust tenant isolation, ask three direct questions:

How is tenant isolation enforced, and does any privileged key or role bypass it?
Are exports, background jobs, reporting, cache, and search paths covered?
How is cross-tenant leakage tested in CI/CD, especially Tenant A trying to reach Tenant B's data?

For regulated buyers, including healthcare and finance, RLS failures can turn into compliance and financial-risk problems, not just engineering bugs. So don't stop at policy declarations. Ask how the system is tested, where tenant context is enforced, and whether the isolation model still holds when things move outside the happy path.

FAQs

How do I know if RLS is actually working?

Don’t rely on code review alone. Test RLS on purpose. Seed two tenants, then sign in as Tenant A and try to SELECT , INSERT , UPDATE , and DELETE Tenant B’s rows. If any of those attempts work, your RLS setup is broken.

It also helps to watch telemetry for queries that don’t line up with the authenticated tenant context. That can catch leaks you won’t spot in a pull request.

If you use connection pooling, reset session state between operations. And if the app connects as the table owner, turn on FORCE ROW LEVEL SECURITY so those policies still apply.

Which roles or tools can accidentally bypass RLS?

BYPASSRLS roles, superusers, and table owners can skip RLS unless FORCE ROW LEVEL SECURITY is turned on. In Supabase, the service-role key skips RLS too.

Other common causes include:

connection pool contamination
async context leaks
loose policies like USING (TRUE)
disabled RLS on raw-SQL tables
relying on app-level filters instead of database enforcement

That last one trips up a lot of teams. If you filter data in the app but don’t lock it down in the database, the guardrail isn’t where it needs to be. It may look fine in testing, then fall apart once another query path, background job, or admin script hits the same table.

When should a SaaS team move beyond shared-schema RLS?

Move beyond shared-schema row-level security (RLS) when scaling, compliance, or day-to-day ops start to strain under it. This often comes up when finance, healthcare, or enterprise customers ask for stronger data isolation.

It may also be time to migrate when one tenant’s CPU usage, connection load, or data growth starts affecting everyone else. The same goes for cases where tenant scale, catalog limits, or cross-tenant reporting become hard to handle. A hybrid model is common here: keep RLS for standard tiers, and isolate larger enterprise customers.