El subdominio de administración no detiene el CSRF: cuatro comprobaciones antes de publicar

Mover la interfaz administrativa a admin.example.com es una mejora real: mantiene las cookies de administración lejos de las páginas públicas, da a las dos aplicaciones cachés separadas y permite dirigir una política de red más estricta a un solo nombre de host. No es un control contra CSRF, y no hace que el código del sitio público sea seguro para dejarlo abierto ante un administrador con sesión iniciada. La separación cambia lo que el navegador considera un límite, no lo que comprueba el servidor, así que haga estas cuatro comprobaciones antes de darlo por terminado.

Lea origen y sitio como dos palabras distintas

Un origen es esquema, host y puerto, así que https://www.example.com y https://admin.example.com son orígenes distintos. Un sitio, en el sentido de SameSite, es esquema más dominio registrable, así que esos dos nombres de host suelen ser el mismo sitio. Esa diferencia es toda la trampa: el atributo SameSite no le ayudará entre subdominios hermanos, porque el navegador no considera la petición entre sitios en absoluto. Dirija la interfaz administrativa a un dominio registrable realmente distinto, como admin-example.net, y la petición sí pasa a ser entre sitios, y ahí es donde SameSite=Lax o Strict empieza a hacer un trabajo en el que puede confiar.

Pruébelo en el navegador en lugar de razonar sobre ello.

Cargue el sitio público, abra las herramientas de desarrollo y mire qué cookies adjunta el navegador a una petición dirigida al host administrativo. Si la cookie no tiene atributo Domain, es solo de host y se queda en su propio nombre; si lleva Domain=example.com, viaja a cada hermano, y el nuevo subdominio no le ha aportado nada para esa cookie.

Separe poder leer la respuesta de poder enviar la petición

La política del mismo origen restringe leer respuestas entre orígenes. No impide que se envíe una petición ni que un formulario lleve credenciales que el navegador ya tiene. Una petición simple, con tipo de contenido de formulario o un GET simple, se entrega sin comprobación previa; CORS decide después si el script que llama puede leer la respuesta. El CSRF vive por completo en el lado del envío.

Por eso el servidor necesita una comprobación explícita para operaciones que cambian estado. Un token de sincronización ligado a la sesión, o una cookie de doble envío comparada en el servidor, cubre el caso; comparar Origin o Referer merece añadirse como segunda puerta pero no como la única, porque no toda petición lleva la cabecera y no todo proxy la conserva. La guía de OWASP para prevenir CSRF trata SameSite como una capa entre varias exactamente por eso.

Decida qué demuestra realmente la puerta de red

Una lista de salidas VPN permitidas delante del host administrativo es un buen control y una afirmación de identidad débil. Demuestra que la petición vino de una dirección que entrega la VPN, que pueden compartir todos los que están en esa salida, y no dice nada sobre qué persona o dispositivo hay detrás. Trátela como un filtro de entrada, no como autenticación.

Manténgala independiente de las comprobaciones a nivel de petición. Si la lista es lo único entre un atacante y un punto final que cambia estado, una ruta mal configurada, un cliente con split-tunnel o un portátil prestado elimina el control por completo.

Registre también los rechazos de fuera de los rangos esperados. Una ráfaga de ellos es la señal más útil de que alguien está sondeando el límite que acaba de construir, y el silencio es la señal de que el filtro no se está alcanzando en absoluto.

Mantenga explícitas las cookies, el inicio de sesión y la autorización

El alcance de la cookie decide la mayor parte del resultado. Una cookie del dominio padre se envía al host administrativo, así que una inyección de script en el sitio público puede actuar con la sesión de un administrador; una cookie solo de host no puede. Prefiera la forma solo de host, añada el atributo Secure y use el prefijo __Host- donde la plataforma lo admita, porque ese prefijo exige Secure, Path=/ y ningún atributo Domain. Lea la cabecera de respuesta en lugar del tarro de cookies: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, sin atributo Domain. El navegador descarta una cookie __Host- que lleve Domain, así que una cookie que aún aparece en hosts hermanos es prueba de que el prefijo nunca se aplicó.

Después mantenga la autorización en el servidor, por petición, en cada punto final administrativo, no solo al iniciar sesión. Una petición de una red permitida todavía tiene que autenticarse y autorizarse para la operación que pide; el nombre de host no es un actor. Si las aplicaciones pública y administrativa comparten un flujo de inicio de sesión o un almacén de sesiones, escriba esa relación, porque es el camino más corto de un fallo en el sitio público a una acción administrativa.

Vuelva a comprobar el límite tras la separación

Ejecute las pruebas negativas, no solo el camino feliz: un formulario entre sitios sin token debe rechazarse, un token de otra sesión debe rechazarse y ningún GET debe cambiar estado. Compruebe los atributos de las cookies en las herramientas de desarrollo, confirme que la comprobación de Origin salta en una petición que no coincide y pruebe el host administrativo desde fuera del rango de la VPN para ver el filtro en acción.

Nada de esto elimina un fallo XSS dentro de la propia aplicación administrativa. Un nombre de host separado es un límite de aislamiento del lado del navegador con valor real, y no sustituye la prevención de ejecución de código inseguro ni la protección de peticiones en el servidor. Tras la separación la lista es más corta de lo que parece: origen distinto, cookies solo de host, un token en cada mutación, un filtro de entrada en el que no confía como identidad y autorización decidida por petición.