What are the most critical Supabase security issues and how can you fix them?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• Upgrade Supabase Auth to v2.185.0 or later to close the OIDC token bypass.
• Enable Row Level Security (RLS) on every table; the default is still off for many legacy projects.
• Never ship the service_role JWT to client - side code; rotate it immediately if exposed.
• Audit all SECURITY DEFINER RPC functions and restrict them to authenticated roles.
• Disable the auto - generated Data API or protect it with strict RLS policies.
• Harden self - hosted templates by changing default PostgreSQL passwords and binding ports to localhost.

Is an outdated Supabase Auth version exposing my users to account takeover?

Yes. Versions of supabase/auth (GoTrue) earlier than 2.185.0 allow crafted OIDC ID tokens to bypass authentication and create full sessions for any email address. The vulnerability (CVE - 2026 - 31813) is medium severity but grants complete account takeover.

Remediation steps:

1. Update the Auth package to v2.185.0 or later.
2. Enable multi - factor authentication (MFA) for all users.
3. Review the identities table for unexpected iss values that may indicate malicious tokens.
4. If you cannot patch immediately, disable Apple and Azure providers in the Auth settings.

Does leaving Row Level Security disabled on new tables put my data at risk?

Yes. When RLS is off, the public anon key can read or write any row through Supabase’s auto - generated REST API. The issue (CVE - 2025 - 48757) is rated critical (CVSS 9.3) and has exposed resumes, passwords, and payment data in real - world incidents.

Remediation steps:

-- List tables without RLS
SELECT tablename FROM pg_tables WHERE schemaname='public' AND NOT rowsecurity;

-- Enable RLS on each table
ALTER TABLE my_table ENABLE ROW LEVEL SECURITY;

-- Example policy that limits access to the owner
CREATE POLICY owner_policy ON my_table USING (auth.uid() = user_id);

Apply the ALTER TABLE … ENABLE ROW LEVEL SECURITY; command to every table, then create owner - scoped policies.

Can an exposed service_role key give an attacker full database control?

Yes. The service_role JWT bypasses all RLS checks. If it appears in client - side bundles or public repositories, anyone can issue unrestricted SELECT/INSERT/UPDATE/DELETE queries.

Remediation steps:

1. Remove the key from all front - end code and public repos.
2. Store it only in secure server - side environments (Edge Functions, backend services).
3. Rotate the key immediately via the Supabase dashboard.
4. Enable the Supabase Security Advisor alerts for "exposed service_role" findings.

Are security - definer RPC functions a backdoor for unauthenticated users?

Yes. Functions marked SECURITY DEFINER run with the owner’s privileges and ignore RLS. Several templates (Cap - go, others) expose such functions to the anon role, allowing enumeration, data insertion, or credential checks (e.g., CVE - 2026 - 56245, GHSA - 7r6g - whg3 - 5mm4).

Remediation steps:

-- Find all security - definer functions
SELECT proname FROM pg_proc WHERE prosecdef = true;

-- Revoke public execution rights
REVOKE ALL ON FUNCTION public.get_user_id(text) FROM anon;
REVOKE ALL ON FUNCTION public.record_build_time() FROM anon;

Replace SECURITY DEFINER with normal ownership or add explicit auth checks inside the function. Limit EXECUTE rights to authenticated roles only.

Should I disable the auto - generated Data API for legacy projects?

Yes. The Data API is enabled by default and will expose every table unless RLS blocks it. Projects that never disabled the Data API remain vulnerable even after RLS is enabled on some tables.

Remediation steps:

1. Open the Supabase project settings.
2. Turn off the Data API if you do not need the public REST endpoint.
3. If you must keep it, verify that RLS is enabled on all tables and that policies deny access for the anon role.

How do I secure self - hosted or one - click Supabase templates?

The one - click Docker template publishes PostgreSQL on 0.0.0.0:5432 with the default password postgres (CVE - 2026 - 16503). This allows anyone on the internet to connect as a super - user.

Remediation steps:

1. Change the PostgreSQL super - user password in the .env file before starting the container.
2. Bind the database port to 127.0.0.1 or remove the host - port mapping entirely.
3. Add firewall rules (UFW, iptables) to restrict external access to the database port.
4. Regularly scan the container image for known vulnerabilities.

Comparison of common Supabase misconfigurations

How can Decloak help you detect these Supabase issues?

Decloak’s free scan runs eight core layers in about 15 seconds. Layer 7 (vibe - coded platform security) specifically fingerprints Supabase projects and checks for the most common real - world misconfigurations, including:

• Publicly readable tables with RLS disabled.
• Exposed service_role keys in client - side bundles.
• insecure SECURITY DEFINER RPC functions. When such findings are detected, the report shows the table name, row count, and field names (no actual data) or the exact RPC that is exposed, giving you provable evidence to remediate.

What are the next steps after fixing the findings?

1. Re - run a Decloak free scan to confirm the issues are resolved.
2. Enable the Supabase Security Advisor alerts for continuous monitoring.
3. Integrate Decloak’s REST API (POST /api/v1/scans) into your CI pipeline to catch regressions early.
4. For larger teams, consider a Starter plan to get DNS/TLS analysis and subdomain takeover detection, which can surface additional exposure vectors.

All technical details are derived from publicly disclosed CVEs, vendor advisories, and security research published between 2025 - 2026.