Auditoría de seguridad de tarasovvitalii.com: ocho hallazgos, ocho correcciones

tarasovvitalii.com es más que páginas estáticas. Tiene un chat sobre VITON ID (Firebase Authentication y Firestore), una pequeña API en Node que guarda los mensajes de contacto y envía correos, un servidor nginx en Docker y copias de 15 sitios conceptuales en /demos/. Quien inicia sesión para escribir al fundador confía en todo ello, así que el 28 de septiembre de 2026 revisamos el sitio desde dentro, como revisaríamos el sitio de un cliente antes del lanzamiento.

Para cada parte, la pregunta era la de un atacante: ¿qué puede hacer con ella alguien de fuera y cuánto le costaría al propietario? Un hallazgo solo contaba una vez reproducido, y una corrección solo contaba cuando el mismo ataque fallaba contra ella.

La revisión abarcó cada ruta de la API y la verificación de tokens, las reglas de Firestore con sus 39 pruebas en el emulador, la configuración de nginx y Docker Compose, las dependencias npm del sitio y de la API, la interfaz del chat y el código de las 15 demos. En lugar de sondear el servidor real, ejecutamos los mismos contenedores en local, nginx y la API con la configuración de producción, y probamos allí cada ataque.

El hallazgo más grave estaba en una demo, no en el propio sitio. El concepto de tienda Oriva insertaba en la página como HTML el parámetro ?cat= de la dirección, así que un enlace preparado ejecutaba script en tarasovvitalii.com, el origen donde el chat guarda su sesión de Firebase: un solo clic del propietario podría haber expuesto la bandeja de entrada. Las otras 14 demos solo comparan los parámetros de la dirección con valores conocidos.

Las correcciones, hallazgo por hallazgo. La demo de Oriva ahora solo acepta categorías y órdenes conocidos. /demos/ tiene su propia Content-Security-Policy, y Leaflet, la biblioteca de mapas que 52 páginas de demos cargan desde un CDN, queda fijada con hashes de integridad. La redirección /demos/<id> se reconstruye a partir de un patrón estricto en lugar de repetir la ruta solicitada. Se rechazan las direcciones de correo que podían colar una copia oculta (BCC) o texto en los enlaces Responder del propietario, y se eliminan de los nombres los caracteres que cambian la dirección del texto.

El servidor recibió el resto: un límite diario global de envíos guardados (500 por defecto) además de los límites por dirección IP; la API de mensajes, que funciona con un usuario sin privilegios sobre un sistema de archivos de solo lectura y sin ninguna capacidad de Linux; la versión de nginx, oculta en las respuestas y en la rama estable actual; y HSTS, la cabecera que mantiene a los navegadores en HTTPS, que ahora también se envía en www y se extiende a los subdominios. Nuevas pruebas de la API cubren las direcciones rechazadas, los caracteres eliminados y el límite.

Ocho hallazgos, ocho corregidos: uno de riesgo alto, uno medio y seis bajos. La carga útil que se ejecutaba con el código antiguo de la demo no hace nada con el nuevo, y la petición que antes inyectaba una cabecera Set-Cookie ahora recibe un 404 normal. Las 119 páginas de demos cargan bajo la nueva política con cero infracciones, las pruebas de la API pasan 48 de 48 con las nuevas reglas cubiertas y npm audit no encuentra vulnerabilidades conocidas en las dependencias del sitio ni de la API.

Revisado y sólido: la verificación de los tokens de ID de Firebase (solo RS256, id de clave obligatorio, audiencia, emisor y caducidad comprobados), unas reglas de Firestore que no permiten a nadie leer la conversación de otra persona ni escribir como el propietario, plantillas de correo que escapan cada valor, registros sin tokens, correos ni direcciones IP, y un chat que nunca inserta el texto del visitante como HTML. En el sitio real, el 28 de septiembre de 2026, las cabeceras de respuesta no muestran la versión del servidor, HSTS con subdominios está activo en ambas direcciones y la política de las demos, en /demos/, y la petición de inyección de cabeceras responde 404.

Es nuestro propio sitio, no un trabajo para un cliente. La revisión la hizo el estudio a partir del código fuente; no es una prueba de penetración independiente ni un certificado. Los ataques se probaron en una copia local de los contenedores de producción, no contra el servidor real; en la dirección real solo se volvieron a comprobar las cabeceras de respuesta y la redirección.

El resultado cubre lo que revisamos el 28 de septiembre de 2026: el código nuevo, las dependencias nuevas o las demos nuevas necesitan otra vez la misma revisión. Las demos siguen compartiendo el origen del sitio, así que la nueva política limita lo que podría alcanzar un código inyectado, pero no lo aísla; llevar las demos a un dominio propio las aislaría por completo.

Cómo revisar el portafolio de un estudio web →