Vai al contenuto

Chiunque può leggere il tuo database Supabase

Critico Intero dominio Sicurezza

Istruzioni generali. Apri questo articolo dal tuo report PageCheck per vederlo compilato con i record del tuo dominio e i passaggi esatti del tuo provider DNS.

Che cos’è

Il Suo sito conserva i contenuti in un database Supabase. La pagina accede a questo database con una chiave pubblica che fa parte del codice della pagina, quindi il browser di ogni visitatore la possiede. Questa chiave è pensata per essere pubblica: a proteggere i dati sono le regole di accesso di ogni tabella (Supabase le chiama Row Level Security).

Cosa non va

Il tuo database Supabase risponde alla chiave pubblica ed elenca le sue tabelle, quindi Row Level Security è disattivato o incompleto. Chiunque apra il tuo sito può leggere, e spesso modificare o cancellare, i dati che ci sono dietro.

Come correggere

1. Attivi le regole di accesso per ogni tabella. Nella dashboard di Supabase apra Authentication → Policies (oppure Table editor → ogni tabella → Row Level Security) e attivi Row Level Security per ogni tabella dello schema public. Con la funzione attiva e nessuna policy, la chiave pubblica non può leggere nulla.

2. Aggiunga una policy solo per ciò che serve al pubblico. Se una parte di una tabella deve essere davvero pubblica (per esempio un elenco di prodotti), aggiunga una policy che consenta di leggere solo quelle righe e colonne. Tutto il resto rimane privato e vi accede soltanto il codice lato server del Suo sito, che usa una chiave segreta, mai la chiave presente nella pagina.

3. Verifichi dall’esterno. Apra il sito in una finestra di navigazione privata e controlli che funzioni ancora, poi ripeta questa verifica. Non serve cambiare la chiave pubblica: è pensata per essere pubblica; a proteggere i dati sono le regole di accesso.

Lock down my Supabase database: it is readable with the public anon key because Row Level Security is off.
Project: <my .supabase.co project>.

Steps:
1. List every table in the public schema and tell me which, if any, genuinely need to be readable by anonymous visitors.
2. Enable Row Level Security on every table in the public schema.
3. For the tables that must be public, add the narrowest SELECT policy that serves the site (only the needed rows and columns); leave the rest with no anon policy.
4. Make sure the app reads private data only through server-side code using the service_role key, never the anon key in the browser.
5. Give me the SQL for the policies and the exact dashboard steps, and tell me how to verify from an anonymous client that the private tables return nothing.
Do not rotate the anon key — it is public by design; the fix is the access rules.

Controlla il tuo sito per sapere se ha questo problema. Controlla un sito