Securing Multi-Tenant SaaS: Complete Guide Against IDOR & RLS Leaks
How to detect and fix IDOR vulnerabilities and Supabase RLS bypasses in modern SaaS applications. Includes Next.js Server Action code patterns and PostgreSQL policies.
Insecure Direct Object References (IDOR) remain the #1 security risk in multi-tenant SaaS applications, enabling authenticated users to access other tenants' data by tampering with record IDs. This guide explains how to secure PostgreSQL Row-Level Security and Next.js Server Actions.
1. What is an IDOR Vulnerability in SaaS?
IDOR (also categorized as Broken Object Level Authorization / BOLA by OWASP) occurs when an application exposes a direct reference to an internal object without verifying tenant ownership.
For example, on `/api/projects/123/export`, if User B can access Project 123 belonging to Organization A simply by altering the URL parameter, the application is vulnerable.
Using random UUIDs instead of auto-incrementing integers prevents guessing, but DOES NOT fix IDOR: if an attacker captures the UUID, they can still read the object if the server fails to verify ownership.
2. Common PostgreSQL & Supabase RLS Pitfalls
Key mistakes developers make when implementing RLS:
- **Unscoped SECURITY DEFINER functions:** A function created with `SECURITY DEFINER` executes with creator privileges, bypassing all RLS policies unless explicit `auth.uid()` filters are implemented.
- **Selective Operation Policies:** Creating a restrictive `SELECT` policy while forgetting `UPDATE` or `DELETE`.
- **Unprotected Related Tables:** A join between a protected table and an unprotected foreign key table can allow cross-tenant data leaks.
-- Multi-tenant Row-Level Security Policy Example
CREATE POLICY "Users can only access records belonging to their tenant"
ON public.documents
FOR ALL
TO authenticated
USING (
tenant_id IN (
SELECT org_id FROM public.memberships
WHERE user_id = auth.uid()
)
);Frequently asked questions
Do UUIDs prevent IDOR vulnerabilities?
No. UUIDs only prevent enumeration; they do not enforce access control. If an attacker discovers an ID, they can still access the data if ownership is not checked.
How should I test for IDOR in my SaaS?
Create two test accounts belonging to separate tenants. Attempt to view or modify an object from Tenant A while authenticated as Tenant B.
Is your SaaS ready for production?
Identify critical vulnerabilities before your users do with the Validra Security Review in 5 business days.