Supabase Security Best Practices for Production Apps

Key Takeaways

• Enable RLS on every table containing user data before production deployment
• Use (select auth.uid()) instead of auth.uid() in RLS policies for better query optimization
• Never expose the service role key in client-side code; only the anon key is safe for browsers
• Index columns used in RLS policies to avoid 100x+ performance degradation on large tables
• Test RLS policies with different user contexts before deploying
• Document your security configuration for compliance audits (SOC 2 CC6, ISO 27001 5.15-5.18)

Supabase has become one of the most popular backend-as-a-service platforms for startups and growing companies. Its combination of PostgreSQL, real-time subscriptions, authentication, and storage makes it an attractive choice for rapid development. But that speed can come at a cost if security isn't built in from the start.

In January 2026, Moltbook exposed 1.5 million API keys because their Supabase database had Row Level Security disabled. Anyone with basic technical knowledge could access email addresses, authentication tokens, and API keys for every user on the platform. The fix took two SQL statements, but the damage was already done.

This guide covers everything you need to know to secure your Supabase application properly, from Row Level Security fundamentals to compliance considerations.

Row Level Security (RLS) Fundamentals

Row Level Security is the most critical security feature in Supabase. Without it, your database is essentially public. The Supabase client library includes your project URL and anon key in client-side code by design, and RLS is what prevents that key from granting access to data it shouldn't.

Why RLS is Non-Negotiable

When you create a table using SQL, migrations, or an ORM, RLS is disabled by default. Tables created through the Supabase Dashboard have RLS enabled automatically, but since most production applications use migrations, you should always explicitly enable RLS in your migration files. Without RLS, any authenticated request using the anon key can read and write any row in that table through the auto-generated REST API. This is intentional for development convenience, but it's catastrophic in production.

The Moltbook breach happened because RLS was never enabled on their agents table. Two SQL statements would have prevented the entire incident.

Enabling RLS on Tables

Enable RLS on every table that contains user data before your first production deployment:

1-- Enable RLS on a table
2ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
3
4-- Verify RLS is enabled
5SELECT tablename, rowsecurity
6FROM pg_tables
7WHERE schemaname = 'public';

Enabling RLS without creating any policies will deny all access by default. This is the secure starting point, and you then explicitly grant the access patterns you need.

Common RLS Policy Patterns

Users Can Only Access Their Own Data

The most common pattern: users can only read and modify rows they own.

1-- Users can only see their own profile
2CREATE POLICY "Users can view own profile"
3ON profiles
4FOR SELECT
5TO authenticated
6USING ((select auth.uid()) = user_id);
7
8-- Users can only update their own profile
9CREATE POLICY "Users can update own profile"
10ON profiles
11FOR UPDATE
12TO authenticated
13USING ((select auth.uid()) = user_id)
14WITH CHECK ((select auth.uid()) = user_id);
15
16-- Users can insert their own profile
17CREATE POLICY "Users can insert own profile"
18ON profiles
19FOR INSERT
20TO authenticated
21WITH CHECK ((select auth.uid()) = user_id);
22
23-- Users can delete their own profile
24CREATE POLICY "Users can delete own profile"
25ON profiles
26FOR DELETE
27TO authenticated
28USING ((select auth.uid()) = user_id);

Note the use of (select auth.uid()) instead of just auth.uid(). Wrapping the function call in a subquery allows PostgreSQL to optimize the query plan more effectively, which can provide significant performance improvements on large tables.

The USING clause filters which existing rows the policy applies to (for SELECT, UPDATE, DELETE). The WITH CHECK clause validates new or modified rows (for INSERT, UPDATE).

Role-Based Access Control

For applications with different user roles, you can create policies that check role membership:

1-- Create a function to check if user is admin
2-- Place this in a separate schema (not public) for security
3CREATE OR REPLACE FUNCTION private.is_admin()
4RETURNS boolean AS $
5BEGIN
6  RETURN EXISTS (
7    SELECT 1 FROM user_roles
8    WHERE user_id = auth.uid()
9    AND role = 'admin'
10  );
11END;
12$ LANGUAGE plpgsql SECURITY DEFINER
13SET search_path = public;
14
15-- Grant execute to authenticated role only
16GRANT EXECUTE ON FUNCTION private.is_admin() TO authenticated;
17
18-- Admins can view all users
19CREATE POLICY "Admins can view all users"
20ON profiles
21FOR SELECT
22TO authenticated
23USING (private.is_admin());
24
25-- Regular users can only view their own profile
26CREATE POLICY "Users can view own profile"
27ON profiles
28FOR SELECT
29TO authenticated
30USING ((select auth.uid()) = user_id);

Important Security Considerations for SECURITY DEFINER Functions:

1. Never place in exposed schemas: Functions in the public schema can be called via the API, potentially leaking information. Use a separate schema like private.
2. Always set search_path: Without this, attackers could exploit search path injection vulnerabilities.
3. Restrict execution: Only grant execute to roles that need it.

Multiple policies on the same table are combined with OR logic for the same operation. If any policy grants access, the operation is allowed.

Public Read, Authenticated Write

For content that should be publicly readable but only modifiable by authenticated users:

1-- Anyone can read published posts
2CREATE POLICY "Public can read published posts"
3ON posts
4FOR SELECT
5TO anon, authenticated
6USING (published = true);
7
8-- Authenticated users can read their own drafts
9CREATE POLICY "Authors can read own drafts"
10ON posts
11FOR SELECT
12TO authenticated
13USING ((select auth.uid()) = author_id);
14
15-- Only authors can insert posts
16CREATE POLICY "Authors can insert posts"
17ON posts
18FOR INSERT
19TO authenticated
20WITH CHECK ((select auth.uid()) = author_id);
21
22-- Only authors can update their own posts
23CREATE POLICY "Authors can update own posts"
24ON posts
25FOR UPDATE
26TO authenticated
27USING ((select auth.uid()) = author_id)
28WITH CHECK ((select auth.uid()) = author_id);

Organization-Based Access

For multi-tenant applications where users belong to organizations:

1-- Users can access data from their organization
2CREATE POLICY "Users can view organization data"
3ON documents
4FOR SELECT
5TO authenticated
6USING (
7  organization_id IN (
8    SELECT organization_id
9    FROM organization_members
10    WHERE user_id = (select auth.uid())
11  )
12);

For performance with complex membership queries, consider using a helper function or caching organization membership in the JWT claims.

RLS Performance: Indexing Matters

RLS policies that filter by columns like user_id will perform poorly on large tables without proper indexes. Always index columns used in your policies:

1-- CRITICAL: Index columns used in RLS policies
2CREATE INDEX idx_profiles_user_id ON profiles(user_id);
3CREATE INDEX idx_posts_author_id ON posts(author_id);
4CREATE INDEX idx_documents_organization_id ON documents(organization_id);

For tables with millions of rows, missing indexes on RLS policy columns can cause 100x+ performance degradation. The (select auth.uid()) pattern shown in the examples above also helps PostgreSQL optimize query plans more effectively than bare auth.uid() calls.

Testing RLS Policies

Never deploy RLS policies without testing them. Supabase provides tools to test policies as different users:

1-- Test as a specific authenticated user
2SET LOCAL ROLE authenticated;
3SET LOCAL request.jwt.claims = '{"sub": "user-uuid-here", "role": "authenticated"}';
4
5-- Run your query
6SELECT * FROM profiles;
7
8-- Reset
9RESET ROLE;
10RESET request.jwt.claims;

You can also use the Supabase Dashboard's SQL Editor with the "Run as" feature to test queries as different users. Note that testing custom claims in the SQL editor has limitations because auth hooks don't trigger. For comprehensive RLS testing, consider using pgTAP for automated database testing.

Write automated tests that verify:

1. Users can access their own data
2. Users cannot access other users' data
3. Unauthenticated requests are properly blocked
4. Edge cases (null values, deleted users) are handled

1// Example test with Supabase client
2describe('RLS Policies', () => {
3  it('user cannot access another user profile', async () => {
4    // Sign in as user A
5    await supabase.auth.signInWithPassword({
6      email: 'userA@example.com',
7      password: 'password'
8    });
9
10    // Try to access user B's profile
11    const { data, error } = await supabase
12      .from('profiles')
13      .select('*')
14      .eq('user_id', 'user-b-uuid');
15
16    expect(data).toHaveLength(0);
17  });
18});

Authentication Best Practices

Supabase Auth provides a complete authentication system, but proper configuration is essential.

Secure Authentication Configuration

In your Supabase Dashboard under Authentication > Settings:

Site URL and Redirect URLs: Only allow redirects to your actual domains. Never use wildcards in production.

1# Good
2https://yourapp.com
3https://yourapp.com/auth/callback
4
5# Bad - allows redirect to any subdomain
6https://*.yourapp.com

Email Confirmations: Enable email confirmation for production applications. This prevents account enumeration and ensures email ownership.

Password Requirements: Set minimum password length (at least 8 characters, preferably 12+) and consider requiring complexity.

Session Management

Supabase uses JWTs for session management. Configure appropriate token lifetimes:

1// supabase client configuration
2const supabase = createClient(
3  process.env.NEXT_PUBLIC_SUPABASE_URL,
4  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
5  {
6    auth: {
7      autoRefreshToken: true,
8      persistSession: true,
9      detectSessionInUrl: true
10    }
11  }
12);

In your Supabase Dashboard, configure:

• JWT expiry: Default is 3600 seconds (1 hour). Shorter is more secure but requires more frequent refreshes.
• Refresh token rotation: Enable to invalidate old refresh tokens when a new one is issued.

Token Handling on the Client

Never store tokens in localStorage for sensitive applications. Use httpOnly cookies when possible:

1// For Next.js applications, use the SSR package
2import { createServerClient } from '@supabase/ssr';
3
4export function createClient() {
5  return createServerClient(
6    process.env.NEXT_PUBLIC_SUPABASE_URL!,
7    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
8    {
9      cookies: {
10        get(name: string) {
11          return cookies().get(name)?.value;
12        },
13        set(name: string, value: string, options: CookieOptions) {
14          cookies().set({ name, value, ...options });
15        },
16        remove(name: string, options: CookieOptions) {
17          cookies().set({ name, value: '', ...options });
18        },
19      },
20    }
21  );
22}

Multi-Factor Authentication

Enable MFA for applications handling sensitive data:

1// Enroll user in TOTP MFA
2const { data, error } = await supabase.auth.mfa.enroll({
3  factorType: 'totp',
4  friendlyName: 'Authenticator App'
5});
6
7// data.totp.qr_code contains the QR code to display
8// data.totp.secret contains the secret for manual entry
9
10// Verify MFA during sign-in
11const { data: challengeData } = await supabase.auth.mfa.challenge({
12  factorId: factorId
13});
14
15const { data: verifyData } = await supabase.auth.mfa.verify({
16  factorId: factorId,
17  challengeId: challengeData.id,
18  code: userProvidedCode
19});

Create RLS policies that require MFA for sensitive operations by checking the Authenticator Assurance Level (AAL) claim:

1-- Only allow access if MFA is verified (AAL2)
2CREATE POLICY "MFA required for sensitive data"
3ON sensitive_documents
4FOR ALL
5TO authenticated
6USING (
7  (select auth.jwt() ->> 'aal') = 'aal2'
8);

The aal claim indicates the authentication assurance level: aal1 means single-factor authentication, while aal2 indicates the user has completed multi-factor authentication.

API Key Management

Supabase provides two types of API keys, and understanding the difference is critical.

Anon Key vs Service Role Key

Anon Key (also called the public key):

• Safe to expose in client-side code
• Subject to RLS policies
• Should be the only key used in browsers and mobile apps

Service Role Key:

• Bypasses all RLS policies
• Has full database access
• Must NEVER be exposed in client-side code

1// Client-side: Always use anon key
2const supabase = createClient(
3  process.env.NEXT_PUBLIC_SUPABASE_URL,
4  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY  // Safe to expose
5);
6
7// Server-side only: Service role key for admin operations
8const supabaseAdmin = createClient(
9  process.env.SUPABASE_URL,
10  process.env.SUPABASE_SERVICE_ROLE_KEY  // Never expose this
11);

When to Use Each Key

Use the anon key for:

• All client-side operations
• User-facing API endpoints
• Any code that runs in the browser

Use the service role key for:

• Server-side admin operations
• Webhooks that need to bypass RLS
• Database migrations and seeding
• Background jobs running in secure server environments

Environment Variable Management

Never commit API keys to version control. For a deeper dive into secrets management, see our guide on secrets management best practices.

1# .env.local (not committed)
2NEXT_PUBLIC_SUPABASE_URL=https://yourproject.supabase.co
3NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
4SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
5
6# .gitignore
7.env.local
8.env*.local

For production deployments, use your platform's secret management:

• Vercel: Environment Variables in project settings
• AWS: Secrets Manager or Parameter Store (see also common AWS security misconfigurations)
• Google Cloud: Secret Manager

Rotate your service role key periodically and immediately if you suspect exposure.

Database Security

Beyond RLS, proper database design significantly impacts security.

Schema Design for Security

Keep sensitive data in separate tables with stricter policies:

1-- Public profile information
2CREATE TABLE profiles (
3  id UUID PRIMARY KEY REFERENCES auth.users(id),
4  username TEXT UNIQUE,
5  avatar_url TEXT,
6  created_at TIMESTAMPTZ DEFAULT NOW()
7);
8
9-- Sensitive user data in separate table
10CREATE TABLE user_private (
11  id UUID PRIMARY KEY REFERENCES auth.users(id),
12  email_verified BOOLEAN DEFAULT FALSE,
13  phone_number TEXT,
14  billing_address JSONB
15);
16
17-- Different RLS policies for each
18ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
19ALTER TABLE user_private ENABLE ROW LEVEL SECURITY;
20
21-- Profiles might be publicly readable
22CREATE POLICY "Profiles are publicly readable"
23ON profiles FOR SELECT USING (true);
24
25-- Private data is strictly user-only
26CREATE POLICY "Users can only access own private data"
27ON user_private FOR ALL USING (auth.uid() = id);

Foreign Key Constraints

Use foreign keys to maintain data integrity and prevent orphaned records:

1CREATE TABLE posts (
2  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
3  author_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
4  title TEXT NOT NULL,
5  content TEXT,
6  created_at TIMESTAMPTZ DEFAULT NOW()
7);
8
9CREATE TABLE comments (
10  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
11  post_id UUID NOT NULL REFERENCES posts(id) ON DELETE CASCADE,
12  author_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
13  content TEXT NOT NULL,
14  created_at TIMESTAMPTZ DEFAULT NOW()
15);

The ON DELETE CASCADE ensures that when a user is deleted, their posts and comments are also removed, preventing data leakage from orphaned records.

Input Validation

While Supabase uses parameterized queries that prevent SQL injection, you should still validate input at the application layer:

1import { z } from 'zod';
2
3const createPostSchema = z.object({
4  title: z.string().min(1).max(200),
5  content: z.string().max(10000),
6  published: z.boolean().default(false)
7});
8
9async function createPost(input: unknown) {
10  const validated = createPostSchema.parse(input);
11
12  const { data, error } = await supabase
13    .from('posts')
14    .insert(validated)
15    .select()
16    .single();
17
18  return { data, error };
19}

Validate on the server side even if you validate on the client. Client-side validation is for user experience; server-side validation is for security.

Views and RLS

By default, views bypass RLS because they're created with security_definer semantics. If you create views on tables with RLS, the view will see all rows regardless of the current user. For PostgreSQL 15+, use security_invoker to make views respect RLS:

1-- Make views respect RLS (PostgreSQL 15+)
2CREATE VIEW user_posts WITH (security_invoker = true) AS
3SELECT id, title, created_at
4FROM posts
5WHERE published = true;

Without security_invoker = true, this view would expose all posts to any user who can access the view, bypassing your RLS policies on the posts table.

Realtime Subscriptions and RLS

Supabase Realtime subscriptions also respect RLS policies. When a user subscribes to changes on a table, they will only receive events for rows they have permission to access. This is important for applications using real-time features: your RLS policies automatically protect your Realtime channels.

1// This subscription will only receive changes for rows the user can access
2const channel = supabase
3  .channel('posts-changes')
4  .on(
5    'postgres_changes',
6    { event: '*', schema: 'public', table: 'posts' },
7    (payload) => {
8      // Only receives changes for rows passing RLS policies
9      console.log('Change received:', payload);
10    }
11  )
12  .subscribe();

Edge Functions Security

Supabase Edge Functions run on Deno Deploy and provide serverless compute. Secure them properly.

Securing Edge Functions

Verify the JWT in every function that requires authentication:

1import { createClient } from 'https://esm.sh/@supabase/supabase-js@2';
2
3Deno.serve(async (req) => {
4  // Get the authorization header
5  const authHeader = req.headers.get('Authorization');
6  if (!authHeader) {
7    return new Response(
8      JSON.stringify({ error: 'Missing authorization header' }),
9      { status: 401 }
10    );
11  }
12
13  // Create client with the user's JWT
14  const supabase = createClient(
15    Deno.env.get('SUPABASE_URL')!,
16    Deno.env.get('SUPABASE_ANON_KEY')!,
17    {
18      global: {
19        headers: { Authorization: authHeader }
20      }
21    }
22  );
23
24  // Verify the user
25  const { data: { user }, error } = await supabase.auth.getUser();
26  if (error || !user) {
27    return new Response(
28      JSON.stringify({ error: 'Invalid token' }),
29      { status: 401 }
30    );
31  }
32
33  // Proceed with authenticated request
34  // The supabase client will respect RLS policies for this user
35});

CORS Configuration

Configure CORS headers appropriately:

1const corsHeaders = {
2  'Access-Control-Allow-Origin': 'https://yourapp.com',  // Specific origin, not *
3  'Access-Control-Allow-Methods': 'POST, OPTIONS',
4  'Access-Control-Allow-Headers': 'authorization, content-type',
5};
6
7Deno.serve(async (req) => {
8  // Handle preflight
9  if (req.method === 'OPTIONS') {
10    return new Response(null, { headers: corsHeaders });
11  }
12
13  // Your function logic
14  return new Response(
15    JSON.stringify({ message: 'Success' }),
16    { headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
17  );
18});

Rate Limiting

Implement rate limiting to prevent abuse:

1// WARNING: This in-memory approach does NOT work reliably in Supabase Edge Functions
2// because each invocation may run on a different isolate with separate memory.
3// For production, use Redis, Supabase Database, or Upstash for distributed rate limiting.
4// This example is for illustration purposes only.
5const rateLimitMap = new Map<string, { count: number; resetTime: number }>();
6
7function checkRateLimit(identifier: string, limit: number, windowMs: number): boolean {
8  const now = Date.now();
9  const record = rateLimitMap.get(identifier);
10
11  if (!record || now > record.resetTime) {
12    rateLimitMap.set(identifier, { count: 1, resetTime: now + windowMs });
13    return true;
14  }
15
16  if (record.count >= limit) {
17    return false;
18  }
19
20  record.count++;
21  return true;
22}
23
24Deno.serve(async (req) => {
25  const clientIP = req.headers.get('x-forwarded-for') || 'unknown';
26
27  if (!checkRateLimit(clientIP, 100, 60000)) {  // 100 requests per minute
28    return new Response(
29      JSON.stringify({ error: 'Rate limit exceeded' }),
30      { status: 429 }
31    );
32  }
33
34  // Continue with request handling
35});

Secret Management

Store secrets in Supabase's secret management, not in code:

1# Set a secret
2supabase secrets set STRIPE_SECRET_KEY=sk_live_...
3
4# Use in Edge Function
5const stripeKey = Deno.env.get('STRIPE_SECRET_KEY');

Never log secrets or include them in error responses.

Storage Security

Supabase Storage uses the same RLS patterns as the database.

Bucket Policies

Create buckets with appropriate access levels:

1-- Create a private bucket (no public access)
2INSERT INTO storage.buckets (id, name, public)
3VALUES ('private-documents', 'private-documents', false);
4
5-- Create a public bucket (for assets like avatars)
6INSERT INTO storage.buckets (id, name, public)
7VALUES ('avatars', 'avatars', true);

File Access Policies

Define who can access files in each bucket:

1-- Users can only access their own files in private bucket
2-- Note: PostgreSQL arrays are 1-indexed, so [1] gets the first folder segment
3CREATE POLICY "Users can access own files"
4ON storage.objects
5FOR SELECT
6TO authenticated
7USING (
8  bucket_id = 'private-documents'
9  AND (select auth.uid())::text = (storage.foldername(name))[1]
10);
11
12-- Users can upload to their own folder
13CREATE POLICY "Users can upload to own folder"
14ON storage.objects
15FOR INSERT
16TO authenticated
17WITH CHECK (
18  bucket_id = 'private-documents'
19  AND (select auth.uid())::text = (storage.foldername(name))[1]
20);
21
22-- Authenticated users can upload avatars
23CREATE POLICY "Authenticated users can upload avatars"
24ON storage.objects
25FOR INSERT
26TO authenticated
27WITH CHECK (bucket_id = 'avatars');
28
29-- Anyone can view avatars
30CREATE POLICY "Public avatar access"
31ON storage.objects
32FOR SELECT
33TO anon, authenticated
34USING (bucket_id = 'avatars');

Signed URLs for Private Files

For private files, generate signed URLs on the server:

1// Server-side function to generate signed URL
2async function getPrivateFileUrl(userId: string, filePath: string) {
3  // Verify user has access to this file
4  if (!filePath.startsWith(`${userId}/`)) {
5    throw new Error('Access denied');
6  }
7
8  const { data, error } = await supabaseAdmin
9    .storage
10    .from('private-documents')
11    .createSignedUrl(filePath, 3600);  // 1 hour expiry
12
13  if (error) throw error;
14  return data.signedUrl;
15}

Set appropriate expiry times for signed URLs. Shorter is more secure.

Monitoring and Auditing

Visibility into your Supabase application is essential for security.

Supabase Logs

Access logs through the Supabase Dashboard or API:

• API logs: All requests to your Supabase APIs
• Postgres logs: Database queries and errors
• Auth logs: Authentication events
• Edge Function logs: Function invocations and errors

Configure logging through the Supabase Dashboard under Project Settings > Database. Note that advanced logging configuration like custom log_statement settings requires contacting Supabase support, as ALTER SYSTEM commands require superuser privileges not available to users.

Query Monitoring

Use Supabase's built-in query performance monitoring to identify:

• Slow queries that might indicate missing indexes
• Unusual query patterns that could indicate abuse
• Failed queries that might indicate bugs or attacks

Alerting on Suspicious Activity

Set up alerts for security-relevant events:

1// Example: Log and alert on failed authentication attempts
2const { data, error } = await supabase.auth.signInWithPassword({
3  email,
4  password
5});
6
7if (error) {
8  // Log the failed attempt
9  await supabase.from('security_events').insert({
10    event_type: 'failed_login',
11    email: email,
12    ip_address: request.headers.get('x-forwarded-for'),
13    timestamp: new Date().toISOString()
14  });
15
16  // Check for brute force patterns
17  const { count } = await supabase
18    .from('security_events')
19    .select('*', { count: 'exact' })
20    .eq('event_type', 'failed_login')
21    .eq('email', email)
22    .gte('timestamp', new Date(Date.now() - 15 * 60 * 1000).toISOString());
23
24  if (count && count > 5) {
25    // Trigger alert or lock account
26    await notifySecurityTeam(`Multiple failed login attempts for ${email}`);
27  }
28}

Integrate with external monitoring tools (Datadog, Sentry, PagerDuty) for comprehensive observability.

Compliance Considerations

If you're pursuing SOC 2, ISO 27001, or other compliance certifications, your Supabase configuration directly impacts your compliance posture.

How Supabase Security Maps to Compliance Requirements

SOC 2 CC6 (Logical and Physical Access Controls):

• RLS policies document your access control implementation
• Authentication configuration demonstrates identity verification
• API key separation shows principle of least privilege
• MFA satisfies multi-factor authentication requirements

SOC 2 CC8 (Change Management):

• Document your RLS policies and review them periodically
• Track changes to security configuration through migrations
• Maintain inventory of API keys and their purposes

ISO 27001 Controls 5.15-5.18 (Access Control):

• RLS provides role-based access at the database level (5.15, 5.18)
• MFA implementation satisfies strong authentication requirements (5.17)
• Storage policies enforce need-to-know access to files (5.15)

Note: For organizations with ISO 27001:2013 certifications, these map to Annex A.9 controls.

Documentation Requirements

Maintain documentation of:

1. RLS Policies: What each policy does and why it exists
2. API Key Inventory: What keys exist, what they're used for, who has access
3. Authentication Configuration: Password policies, MFA requirements, session lifetimes
4. Storage Policies: What data is stored, who can access it

Example policy documentation:

1## RLS Policy: user_data_access
2
3**Table**: user_profiles
4**Created**: 2026-01-15
5**Owner**: Security Team
6
7**Purpose**: Ensures users can only access their own profile data
8
9**Policy**:
10- SELECT: user_id must match authenticated user
11- UPDATE: user_id must match authenticated user
12- INSERT: user_id must match authenticated user
13- DELETE: Not allowed (soft delete only)
14
15**Testing**: Covered by test suite in /tests/rls/user_profiles.test.ts
16**Last Review**: 2026-02-01

Access Control Evidence

Auditors will want evidence that your access controls work. Provide:

• Screenshots of RLS configuration in Supabase Dashboard
• SQL exports of your RLS policies
• Test results showing policies block unauthorized access
• Logs showing authentication events
• Documentation of key rotation procedures

Security Checklist

Pre-Launch Checklist

Before deploying to production:

• RLS enabled on ALL tables containing user data
• RLS policies tested with different user contexts
• Service role key removed from all client-side code
• Environment variables properly configured (no keys in code)
• Email confirmation enabled for authentication
• Password minimum length set to 12+ characters
• Redirect URLs limited to your domains only
• Storage bucket policies configured
• Edge Function authentication implemented
• CORS configured with specific origins
• Rate limiting implemented on public endpoints
• Logging enabled for security events
• Database schema reviewed for sensitive data exposure

Ongoing Maintenance

Regular security tasks:

• Review RLS policies quarterly
• Audit API key usage and rotate if needed
• Review authentication logs for anomalies
• Update Supabase client libraries
• Test backup and recovery procedures
• Review and remove unused tables and columns
• Check for new Supabase security features
• Conduct penetration testing annually

Conclusion

Supabase provides powerful security features, but they require proper configuration. The Moltbook breach demonstrated what happens when these features are ignored: a simple misconfiguration exposed 1.5 million API keys to anyone who looked.

The security measures in this guide aren't optional extras. They're the baseline for any production application. RLS policies, proper key management, authentication configuration, and monitoring are fundamental requirements, not nice-to-haves.

Take the time to implement security correctly from the start. Two SQL statements to enable RLS and create a basic policy take minutes. Recovering from a data breach takes months, and some organizations never fully recover.

Bastion helps startups and SMBs build secure applications and achieve compliance certifications like SOC 2 and ISO 27001. If you're building on Supabase and want to ensure your security controls meet compliance requirements, get started with Bastion.