Migraciones de Base de Datos No en Repo
Los cambios de esquema de base de datos se aplican manualmente por el Dashboard de Supabase en vez de archivos de migración trackeados, haciendo imposible auditorías de seguridad y rollbacks.
Cómo Funciona
Cuando los devs modifican el esquema de base de datos directamente por el SQL editor del Dashboard de Supabase en vez de usar archivos de migración, los cambios no son trackeados ni revisables. No hay historial de qué se cambió, cuándo o por quién. Las políticas RLS, definiciones de funciones y estructuras de tablas pueden ser modificadas silenciosamente sin code review. Esto hace imposible auditar configuraciones de seguridad, reproducir la base de datos en un nuevo entorno o hacer rollback de cambios peligrosos. También previene que CI valide que RLS esté configurado correctamente.
# Project structure missing migrations
my-app/
src/
package.json
# No supabase/ directory!
# Schema changes done manually in Dashboard# Proper Supabase project structure
my-app/
src/
package.json
supabase/
migrations/
20240101000000_create_profiles.sql
20240102000000_add_rls_policies.sql
20240103000000_create_storage_policies.sql
seed.sql
config.tomlEjemplo Real
Una startup fintech no tenía archivos de migración y hacía todos los cambios de esquema por el Dashboard. Cuando un dev accidentalmente eliminó una política RLS en producción, no había registro de la política original, no había forma de hacer rollback, y la tabla estuvo expuesta por 3 horas antes de que alguien lo notara.
Cómo Prevenirlo
- Usa supabase db diff para generar archivos de migración desde cambios del Dashboard
- Guarda todas las migraciones en el repo bajo supabase/migrations/
- Requiere code review para todos los archivos de migración antes de aplicarlos
- Configura CI para correr supabase db lint en cada pull request
Tecnologías Afectadas
Data Hogo detecta esta vulnerabilidad automáticamente.
Escanea Tu Repo GratisVulnerabilidades Relacionadas
Row Level Security Deshabilitado
criticalLas tablas de Supabase sin RLS habilitado permiten a cualquier usuario autenticado o anónimo leer, insertar, actualizar y eliminar todas las filas usando la librería cliente.
Política RLS con USING(true)
criticalLas políticas RLS que usan USING(true) o WITH CHECK(true) efectivamente deshabilitan la seguridad a nivel de fila al permitir todas las operaciones para todos los usuarios.
RLS Habilitado Sin Políticas
highRLS está habilitado en una tabla pero no hay políticas definidas, lo que silenciosamente bloquea todo el acceso incluyendo queries legítimos de tu aplicación.
Service Role Key Expuesta
criticalLa service_role key de Supabase está hardcodeada en código frontend, comiteada en un repo o expuesta en bundles del cliente, dando acceso admin completo a la base de datos a cualquiera.