Checklist de seguridad para sitios institucionales (15 puntos)

Hay una diferencia importante entre "mi sitio nunca fue atacado" y "mi sitio es seguro". La primera es suerte, o falta de atención de quien busca. La segunda exige revisión activa. Este checklist reúne los puntos que más aparecen en análisis de seguridad de sitios institucionales reales — no es teoría, es lo que suele faltar en la práctica.

Lo organicé por prioridad: qué resolver primero, qué viene después.

Prioridad alta

1. HTTPS en todo el sitio, sin excepción No solo en la página de login o contacto — en todo. Y el HTTP debe redirigir a HTTPS automáticamente, nunca servir contenido en texto plano.

2. Certificado SSL/TLS válido y con renovación automática Un certificado vencido es la forma más rápida de perder la confianza de quien visita el sitio (y de caer en Google, que penaliza esto). Prefiera renovación automática antes que un recordatorio manual de calendario.

3. Content-Security-Policy (CSP) Cubrimos esto en detalle en otro artículo — es la principal defensa contra XSS.

4. Ningún secreto expuesto públicamente Archivo .env, clave de API, credencial de base de datos accesible vía URL directa. Parece obvio, pero es uno de los hallazgos más comunes en análisis — generalmente por un despliegue mal configurado, no por decisión consciente.

Prioridad media

5. HSTS (Strict-Transport-Security) con includeSubDomains Garantiza que el navegador nunca intente cargar el sitio por HTTP de nuevo, ni en subdominios.

6. X-Frame-Options o frame-ancestors Impide que el sitio se cargue dentro de un iframe invisible en otra página (clickjacking).

7. X-Content-Type-Options: nosniff Impide que el navegador intente "adivinar" el tipo de un archivo y ejecute algo peligroso disfrazado de imagen o documento.

8. DMARC, SPF y DKIM configurados en el DNS Sin esto, cualquiera puede enviar correo suplantando su dominio. Vale la pena empezar en modo monitoreo (p=none) y evolucionar gradualmente hacia el bloqueo (p=reject).

9. Registro CAA en el DNS Define qué autoridades certificadoras pueden emitir certificado para su dominio — sin esto, cualquier CA puede emitir uno, incluso por error o fraude.

10. Cookies con los atributos correctos Secure, HttpOnly y SameSite bien configurados evitan que las cookies de sesión sean robadas o usadas en ataques cross-site.

Prioridad baja (pero aún vale la pena)

11. Permissions-Policy Restringe qué APIs del navegador (cámara, micrófono, geolocalización) pueden usar el sitio y los scripts de terceros — aunque no use ninguna, vale la pena bloquearlas explícitamente.

12. Referrer-Policy Controla cuánta información de la URL de origen se filtra hacia sitios externos cuando alguien hace clic en un enlace de salida.

13. security.txt Un archivo simple en /.well-known/security.txt con un contacto para reportar vulnerabilidades. Bajo costo, señala que hay alguien del otro lado cuidando esto.

14. DNSSEC Protege contra el envenenamiento de caché DNS. Depende del soporte de su proveedor de DNS — vale la pena confirmar antes de intentar habilitarlo.

15. Sin exposición innecesaria de tecnología Header X-Powered-By, versiones exactas de frameworks en el HTML, archivos de configuración de despliegue accesibles públicamente — nada de esto es una vulnerabilidad por sí sola, pero facilita el trabajo de quien está mapeando objetivos.

Cómo usar este checklist

No se puede revisar todo esto de memoria, y no se puede confiar solo en la sensación de "creo que está todo bien". El camino más rápido es ejecutar un análisis automatizado que confirme cada ítem con evidencia real — qué está presente, qué falta, y qué necesita más contexto (como un pentest autenticado) para confirmar.

Después de la primera corrección, vale la pena saber cómo leer el informe de resultado sin perderse en la cantidad de ítems.