Checklist de seguridad para lanzar una web: ocho comprobaciones antes de publicarla

1. La checklist previa al lanzamiento, de un vistazo

Comprueba cada nombre público que sirves, normalmente el dominio sin www y www, tanto por http:// como por https://. Antes de cambiar el DNS, puedes probar el servidor nuevo con el nombre real usando curl -sI --resolve example.com:443:203.0.113.10 https://example.com/, con la dirección IP del servidor nuevo en lugar de la del ejemplo.

Las ocho filas siguen las ocho comprobaciones pasivas del snapshot gratuito de Sitelemetry, que revisa un origen público sin cuenta. Los pasos manuales de abajo llegan más lejos de lo que puede llegar una sola pasada sobre un origen: cubren todos los nombres de host, los dos esquemas, las páginas de error, DKIM y la configuración de tu registrador.

2. Resolución DNS: todos los nombres apuntan al host nuevo

Por qué importa. Una migración a medias pasa desapercibida con facilidad: el dominio sin www ya está en el servidor nuevo, pero www sigue siendo un CNAME a la plataforma anterior. Los registros olvidados también son un problema de seguridad. La OWASP Subdomain Takeover Prevention Cheat Sheet explica cómo un CNAME que apunta a un recurso en la nube ya eliminado puede permitir que otra persona se quede con el subdominio, y cómo un registro MX colgante puede dejar que un atacante reciba su correo e incluso obtenga certificados mediante la validación por correo electrónico.

Cómo comprobarlo.

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short NS example.com

Repite las consultas contra un resolutor público (dig @1.1.1.1 …) por si tu red tiene una respuesta en caché, y después revisa la exportación completa de la zona en tu proveedor de DNS.

Buen resultado. Cada nombre público resuelve al host que esperas, los registros AAAA solo existen si el host sirve de verdad el sitio por IPv6, responden al menos dos servidores de nombres (el mínimo que fija el RFC 1034) y cada registro tiene un propósito y un responsable conocidos.

Corrección habitual. Corrige o elimina los registros obsoletos. Cuando retires un servicio, sigue el orden que recomienda OWASP: actualiza o elimina el registro DNS, espera al menos un TTL y solo entonces borra el recurso en la nube. Antes de una migración, baja el TTL con antelación suficiente para que el TTL anterior, más largo, haya caducado cuando hagas el cambio, y vuelve a subirlo cuando todo esté estable.

3. SPF, DMARC y CAA: los registros que hablan en nombre de tu dominio

Por qué importa. Cualquiera puede poner tu dominio en la línea From de un correo. SPF lista los servidores que pueden enviar correo en su nombre, DKIM firma los mensajes y DMARC indica a los receptores qué hacer cuando ni SPF ni DKIM pasan alineados con el dominio From visible. Gmail, Yahoo y Outlook.com exigen los tres a los remitentes masivos. CAA nombra las autoridades certificadoras que pueden emitir certificados para tus nombres, y las autoridades públicas tienen que consultarlo antes de emitir.

Cómo comprobarlo. Consulta el dominio que usas en las direcciones From, normalmente el dominio registrado y no www:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

Buen resultado.

• SPF: exactamente un registro v=spf1, dentro del límite del RFC 7208 de 10 términos con consulta DNS (los include anidados cuentan), terminado en ~all o -all, nunca en +all.
• DMARC: un registro como v=DMARC1; p=none; rua=mailto:dmarc@example.com, para que lleguen informes antes de endurecer la política. El estándar actual, el RFC 9989 (mayo de 2026), dice que los dominios cuyos usuarios puedan escribir en listas de correo no deberían publicar p=reject; los que aun así lo quieran deberían pasar antes al menos un mes en p=none y otro tanto en quarantine, comparando los informes.
• DKIM: cada servicio que envía en tu nombre firma con tu dominio. Las claves públicas están en selector._domainkey.example.com, así que necesitas cada selector para consultarlas; aparece en la etiqueta s= de la cabecera DKIM-Signature de un mensaje enviado por ese servicio.
• CAA: un registro como 0 issue "letsencrypt.org" por cada autoridad certificadora que uses, incluida la de tu CDN. No tener ningún registro CAA está permitido, y CAA no impide que una autoridad autorizada emita por error.

Corrección habitual. Fusiona los registros SPF duplicados, quita los include de servicios retirados y empieza DMARC en p=none con informes. Un fallo estricto no es automáticamente más seguro: el RFC 9989 advierte que, con -all, el correo se puede rechazar por el resultado de SPF antes de evaluar DMARC, aunque una firma DKIM alineada lo habría hecho pasar, y esos rechazos nunca aparecen en los informes DMARC. Los receptores que no encuentran un registro DMARC en un subdominio suben por el árbol DNS hasta la política del dominio principal, y una autoridad certificadora usa el registro CAA más cercano en el nombre que va a certificar o por encima de él, como explica la página de CAA de Let's Encrypt. Por tanto, que falte un registro _dmarc o CAA en www no es, por sí solo, un hueco. La guía para comprobar SPF y DMARC explica cómo leer y corregir estos registros.

4. Certificado TLS: válido, con los nombres correctos y con alguien que lo renueve

Por qué importa. Un certificado caducado o que no corresponde al nombre detiene a los visitantes en un aviso del navegador, y en un host con HSTS no pueden saltárselo. Además, las renovaciones son cada vez más frecuentes: según la votación SC081v3 del CA/Browser Forum, los certificados de confianza pública emitidos desde el 15 de marzo de 2026 tienen una validez máxima de 200 días, que baja a 100 días desde marzo de 2027 y a 47 días desde marzo de 2029. Let's Encrypt dejó de enviar correos de aviso de caducidad el 4 de junio de 2025.

Cómo comprobarlo. Para cada nombre de host:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

Ejecuta también s_client por separado: la salida debería incluir Verify return code: 0 (ok) y mostrar el protocolo negociado.

Buen resultado. La cadena se verifica con los certificados intermedios que envía el servidor, el certificado cubre todos los nombres que sirves, la conexión usa TLS 1.3 o 1.2, la renovación está automatizada y el procedimiento indica quién es el responsable. Existe una alerta de caducidad que no depende de la autoridad certificadora.

Corrección habitual. Automatiza la renovación con ACME. Let's Encrypt recomienda ACME Renewal Information (ARI) o renovar hacia los dos tercios de la vida del certificado, y advierte de que un intervalo fijo de renovación de 60 días dejará de bastar cuando los certificados duren 45 días. Después de una migración, confirma que la plataforma nueva renueva de verdad. Un solo handshake muestra únicamente el protocolo negociado, así que usa un escáner que liste todas las versiones admitidas para confirmar que TLS 1.0 y 1.1 están desactivados.

Cómo encajan el certificado, HSTS y las demás protecciones del navegador en una visita por HTTPS se explica en la guía sobre el certificado SSL/TLS y HTTPS.

5. Redirección HTTPS: un salto a HTTPS, un host canónico y después HSTS

Por qué importa. Los enlaces antiguos, los marcadores, los scripts y los clientes más viejos siguen pidiendo direcciones http://. Una redirección los lleva a HTTPS, pero, como señala hstspreload.org, un atacante situado entre el visitante y el servidor puede interceptar y reescribir esa redirección. HSTS cierra ese hueco en todas las visitas posteriores a la primera conexión segura.

Cómo comprobarlo.

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sIL "http://example.com/page?x=1" | grep -iE '^(HTTP|location)'

Buen resultado.

• Una redirección permanente (301, o 308 para conservar el método de la petición) a la misma ruta en HTTPS y en el mismo host, como aconseja la guía de TLS de MDN, y como mucho un salto más hasta el host canónico. La ruta y los parámetros de consulta se conservan.
• La respuesta HTTPS envía Strict-Transport-Security. Los navegadores ignoran la cabecera por HTTP, así que la redirección en sí no la necesita.
• Sin contenido mixto: los navegadores bloquean los scripts cargados por http:// en páginas HTTPS.

Corrección habitual. Redirige en el servidor o en la CDN, no con JavaScript. Sube el max-age de HSTS por etapas hasta un valor largo como 31536000 (un año) y añade includeSubDomains solo cuando todos los subdominios sirvan HTTPS. hstspreload.org recomienda hoy HSTS, pero no la precarga. Si los certificados usan el desafío HTTP-01 de ACME, mantén accesible el puerto 80. Para probar este punto con el snapshot gratuito, escribe la dirección http://; con un dominio sin esquema o una dirección https://, el snapshot revisa en su lugar el max-age de HSTS y el contenido mixto.

6. Cabeceras de seguridad: revisa la respuesta final y las páginas de error

Por qué importa. Las cabeceras de seguridad le dicen al navegador qué puede cargar una página, quién puede incrustarla en un marco y cómo tratar los tipos de contenido. Suelen estar en la configuración del servidor o de la CDN, así que un cambio de hosting puede hacerlas desaparecer. Limitan el daño de errores como el cross-site scripting (XSS); no corrigen esos errores.

Cómo comprobarlo.

curl -sIL https://example.com/
curl -sI https://example.com/no-existe

Revisa también la página de error: sin el parámetro always, nginx solo envía los valores de add_header con determinados códigos de estado, como señala la OWASP HTTP Headers Cheat Sheet.

Buen resultado. Un conjunto inicial razonable para un sitio sencillo:

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

• Despliega primero la CSP como Content-Security-Policy-Report-Only. Tiene que permitir todo lo que tus páginas cargan legítimamente, y 'unsafe-inline' anula buena parte de su utilidad.
• frame-ancestors no hereda de default-src y se ignora dentro de una etiqueta <meta>; X-Frame-Options: DENY es el respaldo antiguo.
• Las cookies de sesión llevan Secure, HttpOnly y un SameSite explícito (consulta MDN sobre Set-Cookie). HttpOnly impide que los scripts de la página lean la cookie (por ejemplo, mediante document.cookie), pero el navegador la sigue enviando con las peticiones que corresponden; así limita el robo de cookies mediante XSS, sin evitar el XSS en sí.
• Sin cabecera X-XSS-Protection, o con el valor 0.

Corrección habitual. Define las cabeceras en una sola capa (servidor, aplicación o CDN) para que cada respuesta, incluidas las de error, reciba cada cabecera exactamente una vez. La guía de cabeceras de seguridad HTTP explica cada una en detalle, con ejemplos para nginx, Apache (.htaccess) y hostings estáticos.

7. Tecnología visible, caché y compresión

Tecnología visible

Por qué importa. Server, X-Powered-By y las etiquetas generator le dicen a cualquiera qué software usas, y MDN señala que los números de versión detallados pueden facilitar la búsqueda de vulnerabilidades conocidas. Ocultarlos es higiene, no protección: la guía de pruebas de OWASP lo llama seguridad por oscuridad, y MDN considera más sólido mantener el software actualizado.

Cómo comprobarlo. Ejecuta curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):' y busca después en el código fuente de la página generator y nombres de archivos de script que incluyan números de versión.

Buen resultado. Server: nginx sin número de versión y sin X-Powered-By.

Corrección habitual. server_tokens off; en nginx, expose_php = Off en php.ini, app.disable('x-powered-by') en Express. Si una página revela una biblioteca desactualizada, actualízala en lugar de ocultarla.

Caché, compresión y CDN

Por qué importa. Las reglas de caché deciden quién recibe una copia guardada de una respuesta. Una página personal guardada por una CDN puede servirse al siguiente visitante; por eso MDN dice que las respuestas personalizadas necesitan Cache-Control: private.

Cómo comprobarlo. Ejecuta curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/; después inicia sesión, abre una página de tu cuenta y lee sus cabeceras de respuesta en las herramientas para desarrolladores del navegador.

Buen resultado. HTML servido con Content-Encoding: br o gzip; un Cache-Control explícito en cada respuesta; un max-age largo más immutable solo en archivos estáticos con versión; private o no-store en las páginas con datos de usuario (no-cache sigue permitiendo guardarlas).

Corrección habitual. Define Cache-Control por tipo de ruta, deja las rutas con sesión iniciada fuera de la caché de la CDN y comprime el texto en el servidor o en la CDN. No tener CDN no es un riesgo en sí; la guía de rendimiento web trata la velocidad.

8. Registro del dominio: caducidad, bloqueo y contactos

Por qué importa. Cuando caduca un dominio bajo un dominio genérico de nivel superior como .com, la Expired Registration Recovery Policy de la ICANN obliga al registrador a interrumpir su resolución DNS durante un tiempo, así que el sitio y el correo dejan de funcionar a la vez. Los avisos de renovación van al contacto registrado, que puede ser alguien que ya no trabaja en la empresa o un buzón del propio dominio que está caducando.

Cómo comprobarlo. Usa la herramienta de consulta de la ICANN. Desde el 28 de enero de 2025, RDAP es la fuente de referencia de los datos de registro de los dominios genéricos; WHOIS solo sigue siendo obligatorio para .com, .name y .post. Para los dominios de país, usa la consulta del propio registro o de tu registrador: los .es los gestiona Red.es a través de dominios.es, y cada dominio de país latinoamericano (.mx, .ar, .co, .cl…) tiene su propio registro. Después entra en la cuenta del registrador y revisa su configuración.

Buen resultado.

• Faltan meses para la caducidad, la renovación automática está activada y el medio de pago seguirá siendo válido en la fecha de renovación.
• clientTransferProhibited activado, más los bloqueos de actualización y de eliminación si el registrador los ofrece; sin clientHold ni serverHold, que dejan el dominio fuera del DNS.
• Contactos que llegan a más de una persona, con al menos una dirección que no esté en el propio dominio, y autenticación multifactor en la cuenta del registrador.

Corrección habitual. Activa la renovación automática, renueva por varios años, pide al registrador que active los estados de bloqueo (la guía de códigos de estado EPP de la ICANN explica cada uno) y actualiza los contactos.

9. Lo que esta checklist no cubre

Estos ocho puntos describen la configuración pública que rodea a tu sitio. Un sitio puede superarlos todos y seguir siendo fácil de atacar, porque ninguno mira la aplicación ni cómo se opera. Revisa esto por separado:

• Vulnerabilidades de la aplicación: inyección, cross-site scripting en tus plantillas, subidas de archivos inseguras, acceso entre cuentas.
• Autenticación y sesiones: inicio de sesión, restablecimiento de contraseña, autenticación multifactor, paneles de administración.
• Dependencias y servidores: plugins del CMS, paquetes, parches del sistema operativo.
• Secretos y accesos: claves en repositorios o en el código del front-end, y quién puede entrar en producción, en el proveedor de DNS y en el registrador.
• Copias de seguridad: una restauración que hayas probado de verdad.

La guía de auditoría de seguridad web recorre el inicio de sesión, los permisos y otras comprobaciones del lado de la aplicación, y la OWASP Web Security Testing Guide ofrece casos de prueba detallados.

Una primera pasada rápida sobre un origen. El snapshot gratuito de Sitelemetry no necesita cuenta. Sobre un origen público, lee el DNS público, los registros DNS del correo, los datos de registro del dominio, el handshake TLS y la respuesta HTTP de la página de inicio, y no envía exploits, escaneos de puertos, intentos de inicio de sesión ni carga. Obtienes una puntuación, una calificación de Refuerzo, el número de señales de riesgo y de controles aprobados, y hasta tres señales que revisar primero. No es un pentest: una buena puntuación significa que estas señales públicas se veían bien en ese momento. El plan Free cubre solo comprobaciones de seguridad; las seis áreas de auditoría (seguridad, SEO técnico, visibilidad en IA, accesibilidad, rendimiento e integraciones) empiezan en 49 USD al mes con el plan Starter.