Lovable ejecuta análisis de seguridad básicos al momento de su lanzamiento, pero los análisis automatizados no pueden probar que la autorización comercial sea correcta.
Especialmente para el proyecto Supabase, “RLS está habilitado” y “la política no excederá la autoridad” en la tabla son dos cosas diferentes.
Primero, dibuje límites claros de identidad y datos
Enumere usuarios anónimos, usuarios registrados, administradores y tareas en segundo plano.
Luego, enumere los campos de propietario y de inquilino de cada tabla.
|
|
Es difícil escribir estrategias confiables para tablas sin campos de propiedad claros.
Confirme que RLS esté habilitado para cada tabla de negocios
Consulta el estado real en Supabase SQL Editor.
|
|
Es más fácil pasar por alto el RLS al agregar nuevas tablas.
Guarde los resultados como un archivo adjunto de auditoría en línea.
La estrategia debe cubrir cuatro operaciones respectivamente.
Los riesgos son diferentes para SELECT, INSERT, UPDATE y DELETE.
Permitir que se lean las propias filas no significa que se deba permitir modificar todos los campos.
Utilice WITH CHECK para verificar la propiedad de la nueva fila al insertar.
Al actualizar, verifique la visibilidad de la fila anterior y la legalidad de la nueva fila al mismo tiempo.
Las operaciones de eliminación generalmente requieren roles más estrictos.
No se limite a comparar user_id para la estrategia multiinquilino
Los productos de equipo a menudo dependen de tablas de membresía.
La política debe verificar que el usuario actual pertenece a la organización de destino.
Verifique también si el estado de miembro es válido y si el rol permite la operación.
Los miembros desactivados no deben seguir leyendo datos de inquilinos antiguos.
Los registros de invitación no pueden ser equivalentes a los de miembros oficiales.
Usa dos cuentas para realizar pruebas no autorizadas
Cree el usuario del inquilino A, Alice, y el usuario del inquilino B, Bob.
Haga que Alice cree un registro de prueba identificable.
Bob intenta realizar una consulta de lista, consultar por ID, actualizar y eliminar el registro.
No se limite a probar la interfaz de usuario.
Copie la solicitud en las herramientas de desarrollo del navegador, reemplace la ID del recurso y reprodúzcala.
Todas las solicitudes no autorizadas deberían devolver resultados vacíos o errores de autorización.
La clave de función de servicio no debe ingresar al front-end
Omite RLS y solo debe existir en servidores controlados.
Busque repositorios y cree productos:
|
|
Si se ha enviado anteriormente no termina por eliminar el fichero.
Las claves se deben rotar inmediatamente y se deben verificar el historial de Git y los registros de implementación.
La clave anónima se puede hacer pública pero los permisos no se pueden relajar
La clave anon de Supabase se usa originalmente en el lado del cliente.
Su seguridad se basa en RLS y permisos de bases de datos.
No ignore el costo de una solicitud si se hace un mal uso solo porque es pública.
Se agregaron límites de velocidad y códigos de verificación para interfaces de alto costo.
El almacenamiento también requiere una estrategia independiente
Compruebe si el depósito es público o privado.
Los archivos privados utilizan URL firmadas de corta duración.
Preferiblemente, la ruta del objeto debe contener un prefijo de usuario o inquilino de confianza.
No deduzca la propiedad únicamente de los nombres de archivos de los clientes.
Intente pasar la ruta del objeto de otro inquilino a la interfaz de descarga.
La función Edge valida el token en lugar de confiar en los parámetros
La función debe autenticar al usuario desde el encabezado Autorización.
No acepte user_id en el cuerpo de la solicitud como base para la identidad.
La acción del administrador solicita la función en el lado del servidor.
No imprima el JWT completo, las cookies o la información de pago en los registros.
Comprobación de función de base de datos DEFINIDOR DE SEGURIDAD
|
|
SECURITY DEFINER` La función se ejecuta con permisos de propietario.
search_path debe corregirse, restringirse los permisos de ejecución y revisarse el SQL dinámico.
Vuelva a cambiar los permisos de llamada predeterminados si no es necesario.
El botón oculto del front-end no está autorizado
Las páginas adorables generadas pueden ocultar botones de administración según su función.
Un atacante aún puede llamar a la API directamente.
Todos los permisos deben aplicarse nuevamente en la política de la base de datos o en el lado del servidor.
El juicio de la interfaz de usuario solo mejora la experiencia y no constituye un límite de seguridad.
Realizar pruebas negativas antes de su liberación
Prueba sin acceso de inicio de sesión.
Pruebe los tokens caducados.
Pruebe que los usuarios normales llamen a la interfaz del administrador.
Pruebe los UUID entre inquilinos.
La interfaz del lote de prueba mezcla un registro no autorizado.
Pruebe cargar archivos muy grandes y falsificar tipos MIME.
Pruebe tokens antiguos de cuentas eliminadas.
Sólo cuando pasan todos los casos de uso negativos significa que la póliza no solo cubre el camino normal.
Secuencia de procesamiento después de descubrir el problema
Endurecer la política o suspender las funciones afectadas primero.
Vuelva a rotar las claves filtradas.
Consulte el registro de auditoría para confirmar si ha sido explotado.
Después de arreglar, vuelva a realizar la prueba con dos inquilinos.
Finalmente se relanzó la parte delantera.
No deje simplemente los problemas de seguridad a las nuevas indicaciones en lenguaje natural para “optimizar un poco más”.
Lista de verificación final
-
Se ha exportado el estado RLS de todas las tablas de negocios.
-
Los cuatro tipos de operaciones de bases de datos tienen estrategias claras.
-
La autorización de múltiples inquilinos pasa la verificación de membresía.
-
La clave de rol de servicio no ingresa al cliente ni a Git.
-
Depósito de almacenamiento y política de objetos probados.
-
La función Edge verifica de forma independiente la identidad y el rol.
-
Las funciones DEFINER DE SEGURIDAD se revisan una por una.
-
Las dos pruebas no autorizadas de cuentas cubren lectura, escritura y eliminación.
-
La rotación de claves y las rutas de respuesta a eventos son ejecutables.
El escaneo automatizado es adecuado para encontrar errores de configuración comunes; Las reglas comerciales multiinquilino aún requieren diseño manual y pruebas adversas.
Información de seguridad de Supabase
Utilice SQL para ver las políticas existentes en lugar de simplemente mirar la interfaz
|
|
Después de exportar los resultados, compruébelos tabla por tabla. qual determina qué filas antiguas son visibles, with_check determina si se permite que existan nuevas filas después de la escritura; escribir solo uno de ellos puede causar asimetría en las reglas de lectura y escritura.
Revisar ideas para una estrategia de lectura multiinquilino
|
|
Las estrategias reales también deben combinar roles y necesidades comerciales. Al revisar, asegúrese de que organization_id tenga un índice; de lo contrario, es posible que se analicen las membresías para cada consulta y la política de seguridad se convertirá en un cuello de botella en el rendimiento.
Evitar que los usuarios modifiquen los campos de propiedad
Permitir que el usuario actualice el título no debería permitirle también cambiar owner_id o organization_id a otros valores. Puede restringir las actualizaciones de columnas o exigir que la propiedad siga siendo legal en WITH CHECK.
Las pruebas de API deben enviar explícitamente el campo de propiedad en lugar de depender de que el formulario de interfaz no lo muestre. Un atacante puede construir directamente una solicitud JSON.
Condiciones de carrera en el proceso de invitación
La invitación al equipo contiene al menos un token aleatorio, tiempo de vencimiento, correo electrónico de destino, organización y estado. Verifique y marque el token como utilizado en una transacción de base de datos al aceptar la invitación.
Enviar el mismo enlace de invitación dos veces al mismo tiempo solo puede crear una membresía. Las invitaciones que han sido revocadas o vencidas deben fallar y las comprobaciones no se pueden omitir simplemente porque el usuario haya iniciado sesión.
El almacenamiento realiza una verificación secundaria después de la carga
El Content-Type del cliente se puede falsificar. El servidor o la tarea asincrónica lee el encabezado del archivo, confirma el formato real y establece límites de tamaño independientes para imágenes, PDF y otros tipos.
El depósito público no almacena tarjetas de identificación, contratos ni archivos de exportación de usuarios. La URL firmada del depósito privado tiene un período de validez breve y el registro no registra la URL firmada completa.
El CORS de la función Edge no está autorizado
CORS solo controla si el navegador puede leer respuestas entre dominios y no puede evitar solicitudes curl o del servidor. Las funciones aún necesitan verificar JWT, la membresía de inquilinos y permisos de operación específicos.
Las solicitudes de verificación previa solo devuelven los métodos y encabezados necesarios. No utilice ninguna combinación de origen y credenciales para eliminar errores del navegador.
Las copias de seguridad también contienen datos confidenciales
Las copias de seguridad de Supabase, los volcados de SQL y los archivos torrent locales utilizan el mismo nivel de protección que los datos de producción. Confirme el cifrado del disco y los permisos de acceso antes de descargarlo a la computadora de desarrollo.
Los simulacros de recuperación utilizan elementos de cuarentena. Inmediatamente después de que se completa la recuperación, se rotan los tokens, los secretos de Webhook y las credenciales de terceros que se incluyen con los datos en el entorno de prueba.
Inspección continua después de conectarse
Supervise la cantidad de rechazos de RLS, lecturas de lotes anormales, tráfico de almacenamiento y tasas de error de funciones perimetrales. Un solo rechazo suele ser un error de entrada normal, mientras que atravesar una gran cantidad de UUID en un corto período de tiempo puede ser una detección no autorizada.
La lista de verificación de seguridad se vuelve a ejecutar cada vez que se agrega una nueva tabla, depósito o función. El hecho de que se apruebe la primera auditoría en línea no significa que todas las funciones generadas posteriormente heredarán automáticamente la política correcta.