ScanYourSite

Mira lo que tu proyecto de Supabase le enseña al mundo

La anon key está pensada para ser pública. La protección es Row Level Security — y la única clave que se la salta nunca debe llegar al navegador. Comprobamos ambas cosas desde fuera, como lo haría un atacante, sin tocar tus datos.

Gratis, sin registro. El análisis básico hace solo las peticiones que haría un navegador normal.

Ver un informe completo de ejemplo

Lo que revisamos

Compruébalo tú mismo en cinco minutos

Todo lo que comprobamos desde fuera puedes comprobarlo desde tu propio panel y tu terminal. Hazlo solo en tu propio proyecto.

  1. Lista las tablas sin Row Level Security

    Panel de Supabase → SQL Editor. Cualquier tabla pública con rowsecurity = false se puede leer con la clave anon si siguen vigentes los permisos (grants) por defecto. El Security Advisor (Advisors → Security) muestra la misma lista.

    select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

  2. Pruébalo como un desconocido

    Usa la clave anon de tu sitio — la misma que tiene cada visitante. Si esto devuelve filas, se las devuelve también a cualquiera.

    curl 'https://<project>.supabase.co/rest/v1/<table>?select=*&limit=1' \
  -H "apikey: <anon key>" \
  -H "Authorization: Bearer <anon key>"

  3. Asegúrate de que la clave secreta nunca llegó al navegador

    En tu sitio en producción abre DevTools y busca en todos los archivos cargados (Cmd/Ctrl + Option/Alt + F) service_role y sb_secret_. Cualquier coincidencia significa: rota la clave en Project Settings → API y luego mueve ese código a una Edge Function.

  4. Activa RLS y añade una política

    Activar RLS sin una política lo bloquea todo — añade una que encaje con cómo se usa la tabla. Para una tabla de perfiles de usuario:

    alter table public.profiles enable row level security;

create policy "read own profile"
on public.profiles for select
using (auth.uid() = id);

Una solución que tu IA puede aplicar

El prompt del informe nombra las tablas y el problema exacto, y pide a tu IA que active RLS con políticas que encajen con cómo usa la app cada tabla.

Corrige estos problemas en app.example.com.

1. La tabla "profiles" devuelve 1240 filas a la anon key.
   Activa Row Level Security en ella y añade una política para que cada usuario solo pueda hacer select de su propia fila (auth.uid() = id).

2. La tabla "orders" devuelve 87 filas a la anon key.
   Activa RLS; permite select solo al dueño del pedido.

Al terminar, vuelve a revisar: https://scanyoursite.app/es?check=app.example.com

Una tabla nueva es un riesgo nuevo

Cada migración puede añadir una tabla sin política. Con Pro el análisis de tablas se ejecuta en cada revisión programada, y te enteras de una tabla recién abierta el mismo día.

Ver planes

Preguntas

¿Por qué tengo que verificar mi dominio para el análisis de tablas?

Consultar una base de datos va más allá de lo que hace un navegador en una página, así que solo lo hacemos para el propietario. La verificación se hace con un registro DNS, un archivo o una etiqueta meta.

¿Se guardan mis datos?

No. Contamos las filas con una petición HEAD y guardamos solo el número y el nombre de la tabla.

¿La anon key es una filtración?

No. Es pública por diseño. La mostramos como dato informativo, no como problema.

Para vibe coders

Pega tu URL. Tendrás la lista en un minuto, más o menos.

Cada hallazgo te dice qué significa para ti y cómo arreglarlo — o trae un prompt que tu herramienta de IA puede aplicar.

Gratis, sin registro. El análisis básico hace solo las peticiones que haría un navegador normal.