Las reglas de acceso viven en Postgres (RLS), no en la pantalla. Cada tabla tiene políticas que dicen qué filas puede ver cada rol, y se evalúan en el motor de la base de datos. Además los permisos son por COLUMNA: una persona no puede cambiar su propio rol ni darse permisos, porque esa columna no es modificable desde la aplicación.

Si el aislamiento viviera en el código de las pantallas, bastaría un filtro olvidado en una consulta —o una dirección adivinada— para que un cliente viera lo de otro. Así, aunque la consulta estuviera mal escrita, la base de datos no devuelve esas filas.

La clave de servicio vive en una variable de entorno del servidor y se usa en un solo archivo. Nunca va en una variable que empiece por `NEXT_PUBLIC_`, porque esas se incrustan en el paquete que se descarga el navegador. El archivo con las claves está en `.gitignore` y el de ejemplo lleva valores falsos.

Esa clave se salta TODAS las políticas de seguridad. Publicada en el navegador, cualquiera podría leer y borrar la base de datos completa. Es el fallo que más veces se ve en proyectos reales y el más fácil de cometer: basta escribir mal el nombre de una variable.

Cada formulario tiene un esquema que define forma, tipo y longitud de cada campo, y se comprueba EN EL SERVIDOR. La validación del navegador está para ser amable con quien escribe; la que decide es la del servidor, porque la del navegador se salta con tres clics. Las consultas siempre van con parámetros: nunca se arma una consulta pegando texto.

Sin validación en servidor, cualquiera puede mandar una petición directa con lo que quiera. Y sin consultas con parámetros, un texto como `' OR 1=1 --` dejaría de ser un texto y pasaría a ser parte de la consulta: es la inyección SQL de siempre.

El conteo vive en la base de datos, no en la memoria del servidor: así sigue valiendo aunque el servidor se levante en varias copias a la vez. Cada formulario tiene su propio límite, y los que más importan —entrar, registrarse— se cierran si el propio control falla, en vez de dejar pasar. Lo que sube un cliente con su sesión se cuenta por cuenta y no por IP, para que el exceso de uno no deje sin pagar a otro que comparte la misma red.

Sin límite, probar las mil contraseñas más usadas contra una cuenta es cuestión de segundos. Con él, lleva más de un día. No hace imposible el ataque: lo hace tan lento que deja de valer la pena.

Se comprueba el tipo y el tamaño, y se mira el contenido real del archivo —sus primeros bytes— en vez de creerse la extensión del nombre. Los comprobantes y los contratos van a un almacenamiento PRIVADO: se leen con un enlace temporal que caduca, no con una dirección pública que se pueda compartir o adivinar.

Renombrar `programa.exe` a `comprobante.jpg` es trivial. Y si los comprobantes estuvieran en una dirección pública, bastaría cambiar un número en la dirección para ver el de otro cliente.

Se mandan en todas las respuestas desde la configuración del proyecto: prohibido meter el sitio en un marco, prohibido adivinar el tipo de contenido, control de qué se envía al salir del sitio, y la política de contenidos. Las páginas privadas llevan además la orden de no guardarse en caché.

Sin la primera, otro sitio puede poner el nuestro en un marco invisible y hacer que quien cree pulsar un botón suyo pulse uno nuestro. Sin la de caché, el panel de alguien puede quedar guardado en el navegador de una computadora compartida.