Supabase RLS: auditoría manual o escáner

Row Level Security es la línea entre un proyecto Supabase que protege sus datos y uno que los expone silenciosamente. Cuando RLS está bien configurado, su base de datos aplica reglas de acceso a nivel de fila, para roles sujetos a RLS. Los roles privilegiados, incluido el rol de servicio, pueden eludir esas reglas. Cuando está mal configurado, las tablas parecen protegidas mientras que las políticas dejan pasar más de lo previsto.

Este artículo compara dos formas de ejecutar una verificación de seguridad Supabase RLS: verificar las políticas manualmente y ejecutar una auditoría RLS automatizada. Ambos tienen un lugar. Saber dónde se descompone cada uno es la forma de verificar que sus políticas de acceso a la base de datos funcionen según lo previsto.

RLS es una característica de Postgres que Supabase expone por tabla. Una vez habilitada, una tabla niega el acceso a filas a roles sujetos a RLS a menos que una política lo permita; Los propietarios de tablas y los roles con privilegios de omisión son excepciones. Las políticas se evalúan en función del usuario actual, sus reclamos y la consulta que se ejecuta. el auth.uid() La función suele ser el ancla: una política como using (auth.uid() = user_id) limita el acceso a las filas de la base de datos del usuario que ha iniciado sesión.

El modelo está limpio. Los fracasos no lo son, porque rara vez lo parecen.

Algunos patrones explican la mayoría de los problemas del RLS:

• RLS habilitado en algunas tablas, no en todas. Una nueva tabla agregada después del lanzamiento, o una creada a través de una migración, se puede enviar con RLS desactivado. Luego, cualquier rol con acceso a la tabla puede leer cada fila.

• Una política que es más amplia de lo que parece. using (true) en una política seleccionada significa que todas las filas son visibles. Es fácil agregarlo durante el desarrollo para depurarlo y olvidarse de eliminarlo.

• El papel de servicio asumido en todas partes. El código del lado del servidor que utiliza la clave de función de servicio omite por completo RLS. Si las solicitudes de cara al usuario se ejecutan a través de esa clave, las políticas nunca se aplican.

• Políticas que marcan la columna incorrecta. auth.uid() = id en una mesa donde id es la clave principal de la fila, no el propietario, nunca coincidirá con la intención. La política existe, devuelve un error o un conjunto vacío y la superficie aún se comporta.

• Actualizaciones y eliminaciones de bases de datos sin controles de acceso adecuados. Los desarrolladores a menudo protegen la selección minuciosamente y dejan libres las políticas de escritura. Pasar una verificación de lectura no dice nada sobre quién puede modificar la fila a continuación.

Ninguno de estos se anuncia por sí solo. Cada uno mantiene la aplicación en funcionamiento, que es exactamente la razón por la que sobreviven hasta la producción.

Una auditoría manual es directa y no requiere herramientas nuevas. Usted analiza las políticas mismas, tabla por tabla.

Comience enumerando todas las tablas y confirmando que RLS esté habilitado en cada una. Luego, para cada tabla, enumere las políticas y asígnelas al acceso previsto: quién debe leer, quién debe escribir y quién nunca debe tocarlo. Lea cada expresión de política en comparación con la columna que compara. Confirme que seleccionar, insertar, actualizar y eliminar tengan una política que coincida con la función prevista.

A continuación, verifique la ruta del código. Determine qué clave utiliza realmente su aplicación para las solicitudes de los usuarios y si alguna de ellas se ejecuta a través del rol de servicio. Luego escriba consultas de prueba como usuarios diferentes y confirme que los resultados coincidan con las expectativas: un usuario debe leer sus propias filas y las de nadie más, y no debe poder actualizar una fila que no le pertenece.

Vale la pena hacer una revisión manual y capta muchas cosas. También tiene puntos ciegos predecibles.

• Prueba lo que recuerdas probar. Si no piensa en intentar eliminarlo como segundo usuario, es posible que se pierda una política de eliminación demasiado amplia. Con RLS habilitado, ninguna política de eliminación aplicable significa que la eliminación está denegada.

• Envejece. Las políticas varían a medida que se agregan funciones. Una revisión exhaustiva del último trimestre no dice nada sobre la tabla que agregó la semana pasada.

• Depende de la misma persona que configuró las políticas. El constructor que redactó la póliza es el que tiene menos probabilidades de detectar su propia suposición.

• Necesita evidencia registrada. "Lo revisé y parecía correcto" no deja nada atrás: ni evidencia, ni alcance, ni artefacto que puedas volver a escanear más tarde.

La auditoría manual responde a la pregunta "¿coincide esto con mi modelo mental del sistema?" Por sí solo, no prueba lo que realmente devolverá la base de datos.

Un control de seguridad automatizado Supabase RLS funciona desde la otra dirección. Ejerce el proyecto como lo haría un atacante o un cliente mal configurado e informa lo que realmente permite la capa de datos.

Ese cambio es importante por tres razones. En primer lugar, escala más allá de la memoria: el análisis repite las comprobaciones en las tablas y puntos finales disponibles dentro de su alcance configurado. Un análisis externo no puede inspeccionar todas las políticas sin el acceso adecuado. En segundo lugar, produce evidencia sobre la cual se puede actuar: el hallazgo nombra la tabla, el estado de la política y la condición que la hizo accesible, para que sepa qué cambiar y por qué. En tercer lugar, es repetible. Una verificación que puede ejecutar nuevamente convierte una revisión única en una verificación continua.

VICE escanea aplicaciones web y configuraciones Supabase/RLS, luego informa los hallazgos con la evidencia detrás de ellos y una guía de corrección para trabajar. Puede marcar una solución y solicitar una nueva verificación, pero solo una nueva exploración comparable confirma que el problema está resuelto: la solución se verifica con el mismo alcance, no se asume a partir de la edición. Los escaneos y alertas programados respaldan el monitoreo continuo, por lo que una tabla agregada el próximo mes no reintroduce silenciosamente la brecha.

La división del trabajo es sencilla. Ejecute la verificación automática para encontrar lo que se omitió en su revisión manual, luego use un pase manual para confirmar la intención detrás de cada política que marca el análisis. La automatización le dice lo que permite la base de datos; usted decide si ese permiso fue deliberado.

Una puntuación de cualquier escaneo describe el alcance probado, no una garantía de que un proyecto sea completamente seguro. Trátelo como una señal de dónde buscar, no como un certificado.

Si está implementando un producto creado con Supabase y nunca ha auditado sus políticas, la respuesta honesta es ambas, en orden. Comience con una verificación automatizada de RLS para tener una imagen actual y respaldada por evidencia de lo que permiten sus tablas. Luego recorra los hallazgos manualmente, confirme la intención de cada política y corrija las que se desviaron. Programe la verificación automatizada en un cronograma para que las nuevas tablas y políticas reciban el mismo escrutinio que las originales.

Omitir cualquiera de los dos enfoques puede dejar una política de acceso a la base de datos que parece proteger los datos pero aún permite el acceso no autorizado.

Iniciar un escaneo gratuito en vice-platform.com para consultar su sitio web público antes de registrarse. Un escaneo especializado Supabase requiere un dominio verificado y una suscripción paga o crédito comprado; su cobertura depende del acceso configurado.