Question 1

What is Row Level Security (RLS) in Supabase and why does it matter?

Accepted Answer

Row Level Security (RLS) is a PostgreSQL feature that Supabase exposes to control which rows a user can access in a database table. Without RLS policies enabled, any user with the anon key can read, insert, update, or delete all rows in a table through the Supabase REST API. RLS policies act as WHERE clauses that are automatically appended to every query, ensuring users only access data they are authorized to see. Enabling RLS on every table is considered a fundamental security requirement when building with Supabase. UNPWNED checks whether your Supabase project has RLS enabled and flags tables that are publicly accessible without policies.

Question 2

Is Supabase secure by default?

Accepted Answer

Supabase is not fully secure by default. When you create a new table, RLS is disabled, meaning the table is accessible to anyone with your project URL and anon key. The anon key is designed to be public and is embedded in client-side code, so it provides no protection on its own. Supabase relies on developers to explicitly enable RLS and write appropriate policies for each table. Storage buckets also default to private but require proper policies to enforce access control. UNPWNED scans your Supabase project to identify tables and storage buckets that lack proper security policies.

Question 3

How do I check if RLS is enabled on my Supabase tables?

Accepted Answer

You can check RLS status in the Supabase Dashboard by navigating to the Table Editor and looking for the RLS badge on each table. Alternatively, you can run the SQL query SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' in the SQL Editor to see which tables have RLS enabled. Tables showing rowsecurity as false are exposed to any authenticated or anonymous request through the API. Supabase also shows a warning banner in the dashboard when tables lack RLS. UNPWNED automatically detects tables without RLS and reports them as critical security findings.

Question 4

Can Supabase data be accessed without authentication?

Accepted Answer

Yes, if RLS is disabled or if RLS policies allow anonymous access, data can be accessed without authentication using only the project URL and anon key. The anon key is a JWT that corresponds to the anon role in PostgreSQL, and it is intended to be public. Any table without RLS enabled is fully readable and writable by anyone who has this key, which is typically exposed in client-side JavaScript. This is one of the most common misconfigurations in Supabase projects. UNPWNED tests for unauthenticated data access and flags any tables that expose data to anonymous users.

Question 5

What is the difference between the Supabase service_role key and the anon key?

Accepted Answer

The anon key is a public JWT token meant to be used in client-side applications and is restricted by RLS policies. The service_role key bypasses all RLS policies entirely and has full read/write access to every table in the database. Exposing the service_role key in client-side code or public repositories is a critical security vulnerability because it grants unrestricted database access. The service_role key should only be used in secure server-side environments like backend APIs or serverless functions. UNPWNED checks for exposed Supabase keys in your application and alerts you if a service_role key is found in client-accessible code.

Question 6

How do I secure Supabase Storage buckets?

Accepted Answer

Supabase Storage uses the same RLS system as database tables, with policies defined on the storage.objects table. Each bucket can be set to public or private, where public files are accessible via URL without authentication and private files require a signed URL or valid JWT. Even private buckets need proper RLS policies to control who can upload, download, or delete files. Common mistakes include creating public buckets for user uploads or writing overly permissive policies that allow any authenticated user to access all files. UNPWNED analyzes your Supabase storage configuration and identifies buckets with missing or weak access policies.

Question 7

How secure are Supabase Edge Functions?

Accepted Answer

Supabase Edge Functions run on Deno Deploy and are isolated from your database by default. They can access the database using the service_role key, which means any vulnerability in an edge function could lead to unrestricted database access. Edge functions should validate and sanitize all user input, implement proper authentication checks, and avoid exposing sensitive environment variables in responses. By default, edge functions require a valid JWT in the Authorization header unless verify_jwt is set to false. UNPWNED tests your edge function endpoints for common vulnerabilities including missing authentication, input validation issues, and information disclosure.

Question 8

How can I test the security of my Supabase project?

Accepted Answer

You can test Supabase security by attempting to access your API endpoints with just the anon key and no authentication to check for RLS bypasses. The Supabase Dashboard includes an RLS debugger that lets you simulate queries as different roles. You should also verify that your service_role key is not exposed in any client-side code or public repositories. Testing should include checking storage bucket policies, edge function authentication, and database function permissions. UNPWNED provides automated security scanning that tests all of these vectors and generates a detailed report with specific remediation steps.

Question 9

What are the most common Supabase security mistakes?

Accepted Answer

The most common mistake is leaving RLS disabled on tables, which exposes all data to anyone with the anon key. Other frequent issues include exposing the service_role key in client-side code, writing RLS policies that are too permissive such as using true for the USING clause, and forgetting to secure storage buckets. Developers also commonly expose database function results that bypass RLS by using SECURITY DEFINER without proper input validation. UNPWNED detects all of these misconfigurations and provides specific guidance on how to fix each issue.

Question 10

What are the security best practices for Supabase?

Accepted Answer

Enable RLS on every table without exception and write specific policies that match your application logic. Never expose the service_role key in client-side code and use it only in secure server environments. Enable email confirmation for authentication and configure proper password requirements. Use pgAudit or Supabase logs to monitor for suspicious database activity. Keep your Supabase project updated, restrict network access where possible, and enable two-factor authentication on your Supabase dashboard account. UNPWNED continuously monitors your Supabase security posture and alerts you to new misconfigurations or vulnerabilities.

Supabase Security Questions