DEV Community: wendel andrady

RLS was enabled and tenants could still read each other's data — the SECURITY DEFINER hole, and the query that catches it

wendel andrady — Sun, 25 Oct 2026 13:50:31 +0000

RLS protects rows from the invoking user's context. It does nothing about a function that runs SECURITY DEFINER — that function executes with the owner's rights, and unless it re-implements tenant filtering internally, every caller rides past your policies. This isn't theoretical: I found exactly this in my own multi-tenant app. RLS was on, policies looked right, and a single RPC that returns usage data still crossed tenants — because it filtered by an org_id the caller passed in as an argument.

The mechanics, in one paragraph. Postgres evaluates RLS against the role executing the query. SECURITY DEFINER swaps that role for the function owner — typically the table owner, which your policies exempt or treat as privileged. If the function does SELECT * FROM usage WHERE org_id = $1 without pinning the tenant to the caller's org, the caller chooses $1. RLS never gets a vote.

How I caught it. Not by reading code — by writing an adversarial test that logs in as org A, calls the RPC with org B's id, and asserts zero rows come back. Rows came back. That test ships in the project's hardening suite now, and the fix went out as a numbered migration.

Three fixes to consider, in order of preference: (1) make the definer honor RLS anyway — explicit org_id filter derived from caller identity (in Supabase, auth.uid() from the JWT; in plain Postgres, current_user or a session GUC), never from arguments; (2) if the function must be definer for a reason, SET search_path explicitly and REVOKE from roles that shouldn't call it; (3) add a regression test that tries the cross-tenant call — if you only test the happy path, this class of bug ships.

Audit query to run today — list every SECURITY DEFINER function in your database, then check each one filters by caller identity rather than arguments:

sql

select n.nspname, p.proname
from pg_proc p join pg_namespace n on n.oid = p.pronamespace
where p.prosecdef = true;
Full write-up with the migration that fixed it is on my site's postmortems page: https://andrady.co/postmortems/security-definer. Disclosure: I also sell a multi-tenant Next.js + Supabase starter (B2B SaaS OS) that ships this test suite — but everything above is useful whether or not you ever look at it.

Your B2B SaaS Isn't Production-Ready Until You Test These 10 Failure Cases

wendel andrady — Wed, 09 Sep 2026 21:55:52 +0000

Most B2B SaaS security testing focuses on the happy path.

A user signs in.

They can access their organization's data.

The right role can perform the right action.

Stripe sends a webhook and the subscription updates.

Everything looks correct.

But production failures usually happen somewhere else:

When someone does something they're not supposed to be able to do.

Here are 10 failure cases I think every multi-tenant B2B SaaS should test before production.

User A can access User B's data

Create two organizations:

Organization A
└── User A
└── Project A

Organization B
└── User B
└── Project B

Then try to access Project B while authenticated as User A.

Don't only test through the UI.

Try:

Direct API requests
Known resource IDs
Modified URLs
Nested resources
Search endpoints

The expected result should always be denial.

A tenant_id column by itself doesn't provide tenant isolation.

Changing a resource ID bypasses authorization

Suppose your endpoint is:

GET /api/projects/123

What happens if User A changes 123 to 456, where 456 belongs to another organization?

This is a classic place for authorization bugs.

The server needs to verify both:

The resource exists.
The current user is allowed to access it.

Never treat possession of a resource ID as authorization.

RBAC works in the UI but not the API

Hiding an admin button from a member isn't security.

Try calling the underlying endpoint directly as a member.

For every sensitive action, test:

Owner
Admin
Member
Unauthenticated user

Authorization needs to exist at the server boundary, not just in the frontend.

A revoked invitation can still be used

Invitations have more states than:

invited → accepted

You should test:

Expired invitation
Revoked invitation
Already-used invitation
Invitation belonging to another organization

An invitation should not become a permanent access token.

A revoked API key still works

API keys are another authentication path.

Test:

Valid key → allowed
Invalid key → denied
Revoked key → denied
Expired key → denied
Wrong tenant → denied

Also verify that API-key permissions are enforced just like browser-based authentication.

Usage limits can be bypassed

If your SaaS has usage limits, don't only test:

User reaches limit → request fails.

Try concurrent requests.

For example, if the limit is 100 operations, what happens when 20 requests arrive simultaneously while the tenant has 95 operations remaining?

If the application checks and increments usage incorrectly, several requests may pass before the limit is updated.

Usage enforcement needs to happen server-side and should account for concurrency where relevant.

The same Stripe webhook produces the effect twice

Webhook providers retry events.

Your application should assume that the same event can arrive more than once.

Test:

Webhook received
Webhook received again

The second delivery should not:

Create a duplicate subscription
Apply a credit twice
Process an upgrade twice
Trigger duplicate provisioning

Webhook processing should be idempotent.

A background job loses tenant context

Your HTTP request may correctly know:

organization_id = A

But what happens when that work moves into a background job?

The job needs enough trusted context to know which tenant it belongs to.

Test jobs that:

Read tenant data
Modify tenant data
Delete tenant data
Process billing events
Process usage

Background jobs are still part of your application's security boundary.

A new table doesn't have tenant isolation

This is one of the easiest problems to introduce as a SaaS grows.

You add:

reports

The application works.

Existing tests pass.

But the new table doesn't have the same isolation protections as your other tenant-owned resources.

For every tenant-owned table, verify:

[ ] Ownership relationship exists
[ ] Database policy exists
[ ] Server authorization exists
[ ] Cross-tenant read tested
[ ] Cross-tenant write tested
[ ] Cross-tenant delete tested

Related resources create an indirect access path

Imagine:

Organization
└── Project
└── Document

You may correctly protect Projects but forget that someone can access a Document directly.

Test the entire chain.

Can User A access a Document belonging to Organization B by knowing:

The document ID?
The project ID?
A nested endpoint?
A search query?
A download URL?

Tenant isolation needs to survive indirect access paths too.

The test that matters most

Don't only ask:

"Does my SaaS work?"

Ask:

"Can I make my SaaS do something I'm not authorized to do?"

That's the test that exposes the gaps.

Free B2B SaaS production checklist

I put the complete production-readiness checklist and a deeper tenant-isolation guide into a free GitHub repository.

production-saas-readiness
It covers authentication, multi-tenancy, RLS, RBAC, invitations, API keys, usage limits, billing, webhooks, background jobs, and production verification.

If you'd rather start with this infrastructure already implemented instead of building it yourself, I've also built a B2B SaaS OS around these components.

andrady.co

How I approached multi-tenancy in Next.js with PostgreSQL RLS

wendel andrady — Sun, 06 Sep 2026 15:19:35 +0000

Multi-tenancy looks simple at first.

You add an organization_id to your tables, check it in your queries, and move on.

The problem is that this puts a lot of responsibility on application code.

I wanted tenant isolation to be enforced at the database level too, so I used PostgreSQL Row Level Security (RLS).

The basic architecture is:

Users belong to organizations
Organization membership determines access
Server-side authorization handles application permissions
PostgreSQL RLS provides another layer of tenant isolation
Roles such as Owner, Admin, and Member control what users can do

This also makes other parts of the application more interesting:

Team invitations
Organization switching
API keys
Usage limits
Billing tied to organizations

The biggest lesson for me was that multi-tenancy isn't really a single feature.

It's an authorization model that needs to stay consistent across the application and database.

I built these patterns into a reusable B2B SaaS foundation because I got tired of rebuilding them for every project.

If you're building a multi-tenant SaaS with Next.js and Supabase, I've put the full foundation here:

https://andrady.co

I'd be interested to hear how other Next.js developers approach tenant isolation. Do you rely mainly on application-level checks, RLS, or both?