Retool + Supabase Security
Retool connects directly to Supabase via PostgREST or PostgreSQL. Internal tools often bypass RLS in the name of convenience — but internal users can be a significant threat vector.
Why Retool + Supabase?
Retool is commonly used to build admin dashboards and internal tools on top of Supabase data. The Supabase PostgreSQL resource type gives Retool direct SQL access, making it fast to build but requiring careful permission scoping.
Common Vulnerabilities
These are the security issues we find most often in Retool apps using Supabase.
Service Role Key as Retool Resource Credential
Retool Supabase resources often use the service_role key for convenience, giving every Retool user who can run queries full admin access to the database — bypassing all RLS.
SQL Injection via Retool Query Parameters
Retool queries that interpolate user input with string concatenation instead of parameterised queries are vulnerable to SQL injection, even in internal tools.
Overly Broad Retool User Permissions
All Retool users in an organisation may have access to queries that expose sensitive Supabase tables like payments, PII, or audit logs.
RLS Disabled for Internal-Only Tables
Teams sometimes disable RLS for internal Supabase tables to simplify Retool queries, leaving those tables exposed if the anon key is ever leaked.
What We Check for Retool + Supabase
Resource Key Audit
Verify which Supabase key is configured in the Retool resource — service_role provides admin access, anon key respects RLS.
Query Parameterisation
Review Retool queries for string concatenation of user-controlled values — use {{ variable }} parameterised syntax instead.
Permission Group Scoping
Check Retool permission groups to ensure sensitive queries and apps are restricted to the appropriate team members.
RLS Status on Internal Tables
Confirm RLS is enabled on all Supabase tables even if they are only accessed through Retool, as a defence-in-depth measure.
Quick Security Wins
Apply these fixes right now to improve your security.
Create a dedicated Supabase database role with only the permissions Retool needs — not service_role or postgres superuserIn Retool query editor, replace string concatenation with {{ parameterName }} syntax for all user-provided valuesUse Retool Permission Groups to restrict access to sensitive apps and queries to the correct internal teamsEnable RLS on all Supabase tables and create policies for the Retool service account roleAudit Retool Resource configuration: go to Resources tab and confirm no production service_role key is used in shared resourcesThe Bottom Line
Retool + Supabase is convenient for internal tooling but service_role key usage and SQL injection in queries are the two risks that appear most often. Create a least-privilege database role for Retool and parameterise all queries.
Secure Your Retool + Supabase App
Find Row Level Security misconfigurations, exposed credentials, and other vulnerabilities before attackers do.
Start Security ScanFrequently Asked Questions
Should Retool use the service_role key or anon key for Supabase?
Neither is ideal without additional hardening. Best practice is to create a custom PostgreSQL role with only the permissions Retool needs — for example SELECT on specific tables, INSERT on audit_logs. This is more restrictive than service_role and more capable than the anon key. Set it as the Retool resource credential.
How do I prevent SQL injection in Retool queries against Supabase?
In the Retool SQL editor, always use the {{ variable }} parameterised syntax instead of string concatenation. Retool sends parameterised values separately from the query, which PostgreSQL handles safely. String concatenation like 'WHERE id = ' + userId is dangerous and must be replaced.
Does Supabase RLS apply to queries made through Retool?
Only if Retool uses the anon key or a role-based key and the Supabase client passes an appropriate JWT. If Retool uses the service_role key, RLS is bypassed entirely. This is why creating a custom restricted database role for Retool is safer than using either built-in key.
How should I control which Retool users can access sensitive Supabase data?
Use Retool's Permission Groups feature. Create groups that map to roles (e.g. Support, Finance, Admin). Assign apps and queries to the appropriate group. For sensitive Supabase data like payments or PII, restrict the Retool app to the smallest group that needs it. Audit access quarterly.