Endurecimiento y seguridad

Qué es

Cogemos una web o una aplicación que ya está en producción y le ponemos las defensas, con una medición antes y otra después. Te llevas una nota de partida, la lista de lo que falta, el trabajo hecho y una segunda medición al cerrar.

Una web no necesita estar hackeada para suspender una revisión de seguridad. En un encargo el disparador no fue un incidente, fue comercial: el filtro DNS corporativo de uno de sus clientes rechazaba el dominio de nuestro cliente, y eso le impedía operar como proveedor. Entregamos en una semana el informe de seguridad, SSL y reputación con herramientas públicas de referencia. La web no estaba comprometida ni en listas negras. El TLS ya estaba bien antes de empezar: certificado válido, TLS 1.3, sin cifrados débiles, cadena válida, forward secrecy y una A en el test público de SSL. Lo que disparaba la clasificación automática de "postura de seguridad baja" eran otras tres cosas: cabeceras HTTP de seguridad ausentes, un certificado de respaldo caducado y no coincidente que exponía el alojamiento compartido, y las huellas del servidor a la vista (versión del intérprete, firma del panel y cabecera de tecnología).

Sobre qué trabajamos

El perímetro

Las cabeceras son la defensa más barata que existe y lo primero que lee un filtro corporativo. Lo que faltaba al empezar aquel encargo: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy y Permissions-Policy. Lo que se servía de verdad al terminar: HSTS con includeSubdomains, política de contenido, nosniff, X-Frame-Options SAMEORIGIN, Referrer-Policy estricta, Permissions-Policy con las APIs sensibles del navegador desactivadas y cabecera de servidor sin versión. La nota de cabeceras pasó de F a A+, medida sobre preproducción antes del cambio de DNS.

También leemos la versión de TLS y sus cifrados, la cadena de certificados, cualquier segundo certificado que el alojamiento exponga en la misma dirección y los flags de las cookies (Secure, HttpOnly, SameSite).

La aplicación

Ocultar las huellas del servidor, protección contra fuerza bruta en el acceso, cortafuegos de capa de aplicación con bloqueo automático de IP, apagar los endpoints de descubrimiento y los protocolos remotos heredados, e inventariar dependencias y extensiones anotando la versión de cada una. Los rastreadores de IA se dejan permitidos a propósito: endurecer no puede costarte la visibilidad en buscadores ni en los motores de respuesta.

El aislamiento por inquilino

Cuando una base de datos guarda datos de varios clientes, el aislamiento no es un ajuste, es una prueba. Seguridad a nivel de fila en cada tabla con columna de inquilino, y un guardián que descubre las tablas en vez de enumerarlas a mano, para que una tabla nueva no se quede fuera. En nuestra propia plataforma multiempresa ese guardián vigilaba 81 tablas con identificador de inquilino en agosto de 2026, se ejecuta en cada build de integración continua, y su prueba entre dos inquilinos reales no encontró lectura cruzada. En otra plataforma que endurecimos, los avisos del analizador de seguridad de la base de datos pasaron de 4 a 0 y las políticas de fila con problema de rendimiento, de 51 a 0.

Mover el sitio cuando no hay otra vía

En aquel encargo el único acceso disponible era el panel de administración del gestor de contenidos. Sin acceso al alojamiento, endurecer a nivel de servidor no era aplicable sobre la infraestructura original. El proveedor original recibió el listado de correcciones y respondió formalmente que quedaba fuera de su alcance, y se perdieron unos tres meses en esa negociación antes de que el cliente cambiara de proveedor.

Calculamos que rehacer la web en código eran de tres a seis semanas, con el dominio bloqueado todo ese tiempo. Migrar el gestor a un alojamiento bajo control del cliente y endurecerlo allí era reversible y ponía las correcciones en vivo mucho antes, así que fue el camino elegido. La reconstrucción quedó como fase diferida.

Lo que afirmamos termina donde termina nuestro trabajo. Si el filtro de aquel fabricante se levantó después es decisión suya, no tenemos ninguna medición de ello y no lo presentamos como resultado.

El DNS se mueve con cadena de custodia: bajada del TTL con 24 a 48 horas de antelación, cambio del registro A y registros de correo (MX, SPF, DKIM y DMARC) intactos, para no romper el correo corporativo del dominio.

Nada está hecho hasta que se comprueba en vivo

Tras el cambio de DNS hicimos una auditoría de enlaces página a página sobre 24 páginas, 12 en cada idioma. Ahí apareció que el reemplazo masivo de URLs inicial había sido incompleto: quedaban referencias a preproducción en el pie global, en los CTA del maquetador, en los enlaces de consentimiento de los formularios, en varios PDF, en textos legales y en una fuente de iconos del tema que devolvía error. El reemplazo se había ejecutado en simulación y se había dado por hecho. Un cambio no está hecho hasta que lo confirma una petición real contra el sitio en vivo.

Cuánto vale una nota

Un A+ es la foto de un host en una fecha, no una propiedad del sistema. Lo mismo vale para una prueba de aislamiento limpia: es cierta como resultado de una comprobación fechada, no como garantía permanente. Por eso cada medición del informe lleva su host, su fecha y su herramienta, y el escaneo que cuenta es el del dominio en producción después del cambio, no el de preproducción.

No prometemos una web segura. Prometemos carencias medibles, medidas, cerradas y vueltas a medir.

Qué te llevas al cerrar

Un informe de entrega en PDF con el antes y el después, la auditoría de enlaces y una garantía técnica de 30 días sobre el trabajo. Si en vez de una revisión puntual quieres mantener la postura, continúa como mantenimiento mensual.