Seguridad
Cabeceras HTTP de seguridad que tu sitio debería exponer
HSTS, CSP, X-Frame-Options, Referrer-Policy y Permissions-Policy: qué protegen, cómo configurarlas en LiteSpeed o CDN y cómo auditarlas sin romper el front.
12 min de lectura · Actualizado 2026-07-22
El perímetro que ve cualquier navegador
Las cabeceras HTTP de seguridad no sustituyen un WAF ni parchear vulnerabilidades, pero reducen vectores de ataque comunes visibles desde internet: clickjacking, MIME sniffing, downgrade a HTTP y ejecución de scripts inyectados.
Cualquier cliente — navegador, bot de Google, escáner externo — recibe estas directivas antes de renderizar la página. Un sitio corporativo sin HSTS o con CSP ausente delata madurez de seguridad inferior a la de un competidor que sí las implementó.
La configuración vive en el servidor web (LiteSpeed, Nginx), en el CDN (Cloudflare Transform Rules) o en el framework (Next.js headers en next.config). Centraliza la fuente de verdad: cabeceras duplicadas o contradictorias entre capas generan bugs difíciles de diagnosticar.
Escanea la URL de producción con la auditoría de seguridad del Toolbox y Web Checker 360 tras cada cambio. Lo que funciona en staging con dominio distinto puede no aplicar en el canónico.
HSTS y la eliminación del downgrade HTTP
Strict-Transport-Security obliga al navegador a usar solo HTTPS durante el max-age definido (recomendado: 31536000 segundos = 1 año). Protege contra ataques man-in-the-middle que intentan bajar la conexión a HTTP en redes públicas.
Activa HSTS solo cuando todo el sitio sirve correctamente por HTTPS, incluyendo subdominios si usas includeSubDomains. Un subdominio legacy en HTTP quedará inaccesible hasta que lo corrijas o expire el max-age.
Considera preload solo si controlas el dominio raíz y todos los subdominios críticos a largo plazo. Entrar en la HSTS preload list es difícil de revertir; un error de certificado en un subdominio olvidado bloquea acceso global.
Ejemplo mínimo en LiteSpeed o Nginx: «Strict-Transport-Security: max-age=31536000; includeSubDomains». Verifica con curl -I https://tudominio.com que la cabecera aparece en respuestas 200, no solo en redirects.
CSP: el equilibrio entre seguridad y funcionalidad
Content-Security-Policy define de dónde puede cargar el navegador scripts, estilos, imágenes y conexiones. Un CSP estricto bloquea XSS reflejado y scripts maliciosos inyectados, pero mal configurado rompe Google Analytics, chat widgets o fuentes externas.
Empieza en modo report-only (Content-Security-Policy-Report-Only) durante una o dos semanas. Recoge violaciones en endpoint o consola antes de enforce. Documenta cada dominio permitido en script-src y connect-src con justificación de negocio.
Para sitios Next.js o WordPress con plugins de terceros, un CSP «default-src 'self'» puro suele ser inviable. Usa nonces o hashes para scripts inline propios y whitelist explícita para CDNs conocidos (jsdelivr, Google Fonts).
X-Frame-Options (DENY o SAMEORIGIN) o frame-ancestors en CSP evita que tu login corporativo se embeba en un iframe de phishing. Referrer-Policy strict-origin-when-cross-origin limita filtración de URLs internas a analytics externos.
Cabeceras complementarias frecuentemente olvidadas
X-Content-Type-Options: nosniff impide que el navegador interprete un archivo subido como imagen pero servido como script. Crítico en portales con upload de usuarios o CMS con media library.
Permissions-Policy (antes Feature-Policy) deshabilita APIs del navegador que tu sitio no usa: cámara, micrófono, geolocalización, payment. Un sitio informativo no necesita permisos amplios por defecto.
Cross-Origin-Opener-Policy y Cross-Origin-Embedder-Policy entran en juego si usas SharedArrayBuffer o aislamiento estricto; para sitios corporativos estándar, COOP same-origin es un buen baseline.
Elimina cabeceras que filtran información: X-Powered-By: PHP/8.2 o Server con versión exacta ayudan al atacante a elegir exploits. Configura el servidor para omitirlas o sobrescribirlas.
Runbook de despliegue y regresión
Antes de producción: lista todas las URLs críticas (home, checkout, login, formularios con Turnstile/reCAPTCHA, embeds de video). Prueba cada una tras aplicar CSP enforce.
Automatiza la verificación en CI: un job que curl las cabeceras esperadas y falle el deploy si falta HSTS o si CSP desapareció. Web Checker 360 puede ser el smoke test manual post-deploy.
Documenta excepciones temporales con ticket y fecha de revisión. «Permitimos unsafe-inline en checkout hasta migrar widget X» sin fecha es deuda permanente.
Si el escaneo muestra cabeceras críticas ausentes o TLS débil en producción, Conecta puede remediar en capa servidor, CDN o aplicación como parte de auditoría técnica o administración DevOps del entorno.
Ponlo en práctica ahora
Usa las herramientas gratuitas del Toolbox para validar tu configuración en minutos.
¿Necesitas que lo resolvamos contigo?
Un ingeniero de Conecta puede aplicar esto en tu operación: servicio relacionado o conversación directa.