Tu web tiene certificado SSL, formularios con protección antispam y copias de seguridad programadas. Pero si no has revisado las cabeceras de seguridad HTTP, sigues expuesto a ataques que el navegador podría bloquear automáticamente: clickjacking, inyección de scripts, fugas de referrer o contenido mixto.
Las cabeceras de seguridad son instrucciones que el servidor envía al navegador en cada respuesta. No las ve el visitante, pero condicionan cómo se carga tu web, qué recursos externos puede ejecutar y qué datos comparte con terceros. En esta guía repasamos las cabeceras imprescindibles para una web de empresa, cómo implementarlas sin romper analytics, mapas o widgets, y cómo auditarlas antes de que un problema real las ponga a prueba.
Qué son las cabeceras de seguridad HTTP y por qué importan
Cada vez que alguien visita tu web, el servidor responde con el HTML, CSS, JavaScript e imágenes… y también con cabeceras HTTP. Algunas son técnicas (Content-Type, Cache-Control), pero otras están diseñadas para reducir la superficie de ataque:
- Protegen al visitante frente a scripts maliciosos, iframes ocultos o redirecciones no deseadas.
- Protegen tu marca evitando que tu dominio se use en ataques de suplantación o en páginas embebidas en sitios fraudulentos.
- Complementan el SSL: HTTPS cifra la conexión; las cabeceras limitan qué puede hacer el contenido una vez descargado.
- Mejoran la confianza en auditorías de seguridad, licitaciones o due diligence de clientes B2B.
No sustituyen un buen desarrollo ni un plan de seguridad web, pero son una capa de defensa barata y efectiva que muchas webs corporativas ignoran.
Señales de que tu web necesita revisar sus cabeceras
- Nunca has auditado las cabeceras desde que se publicó la web.
- Usas Google Tag Manager, mapas, chat en vivo o reCAPTCHA y no sabes si seguirán funcionando con políticas restrictivas.
- Herramientas como Mozilla Observatory o SecurityHeaders.com puntúan tu dominio con F o D.
- Has sufrido intentos de inyección en formularios o contenido generado por usuarios.
- Tu web se embebe en iframes de terceros (intranets, partners) sin control.
- Tras migrar de hosting o CDN, dejaron de aplicarse reglas que tenías en el servidor anterior.
Si te reconoces en dos o más puntos, conviene una revisión antes del próximo pico de tráfico o campaña de captación.
Cabeceras de seguridad imprescindibles en una web de empresa
Strict-Transport-Security (HSTS)
Obliga al navegador a usar siempre HTTPS durante un periodo definido. Evita ataques de downgrade y accesos accidentales por http://. Configúrala solo cuando HTTPS funcione correctamente en todo el dominio y subdominios implicados.
Content-Security-Policy (CSP)
La más potente y la más delicada. Define de qué dominios puede cargarse JavaScript, CSS, imágenes, fuentes o iframes. Una CSP bien ajustada frena XSS, pero una demasiado estricta puede romper el Google Tag Manager, vídeos embebidos o el mapa de contacto.
X-Frame-Options / frame-ancestors
Impide que tu web se cargue dentro de un iframe en otro dominio (clickjacking). En CSP moderna se usa frame-ancestors; mantén coherencia entre ambas.
X-Content-Type-Options: nosniff
Evita que el navegador interprete archivos con un MIME type distinto al declarado. Reduce riesgos cuando se suben PDFs, SVGs o archivos estáticos mal configurados.
Referrer-Policy
Controla qué información de la URL de origen se envía al navegar a enlaces externos. Útil para no filtrar parámetros UTM o rutas internas a terceros.
Permissions-Policy
Limita APIs del navegador (cámara, micrófono, geolocalización, pagos). En webs corporativas estándar suele bloquearse casi todo salvo lo estrictamente necesario.
Cómo implementar cabeceras sin romper tu web
El error más habitual es activar una CSP agresiva en producción sin pruebas. Sigue este orden:
- Audita el estado actual con SecurityHeaders.com, observatory.mozilla.org o las DevTools del navegador (pestaña Network → cabeceras de respuesta).
- Activa primero las cabeceras “seguras”:
X-Content-Type-Options,Referrer-Policy,Permissions-Policyy HSTS (si HTTPS está estable). - Prueba CSP en modo report-only (
Content-Security-Policy-Report-Only) para ver qué recursos bloquearía sin afectar visitantes. - Lista todos los terceros: analytics, publicidad, chat, fuentes, CDN de imágenes, vídeos de YouTube/Vimeo, reCAPTCHA.
- Pasa a CSP enforce con directivas mínimas necesarias:
default-src,script-src,style-src,img-src,font-src,connect-src,frame-src. - Verifica formularios, checkout y área privada tras cada cambio.
Documenta la configuración en el repositorio o en la wiki del proveedor. Si cambias de CDN o plugin, revisa las cabeceras de nuevo.
Dónde configurar las cabeceras según tu stack
- Apache (.htaccess o VirtualHost): directiva
Header setcon mod_headers. - Nginx: bloque
add_headeren server o location. - Cloudflare o CDN: reglas Transform Rules o Workers; útil si no controlas el origen.
- Laravel / framework: middleware personalizado para cabeceras dinámicas por ruta.
- WordPress: plugins de seguridad o configuración del hosting; cuidado con duplicar cabeceras.
Si usas CDN delante del origen, asegúrate de que las cabeceras lleguen al navegador y no las sobrescriba una capa intermedia.
Errores habituales en webs de empresa
- HSTS sin HTTPS estable: bloquea el acceso si hay contenido mixto o certificados mal configurados.
- CSP copiada de un tutorial genérico: rompe GTM, Typekit, HubSpot o el widget de WhatsApp.
- Cabeceras duplicadas o contradictorias entre CDN, proxy y servidor origen.
- No probar en staging antes de producción.
- Confundir seguridad con privacidad: las cabeceras no sustituyen el banner de cookies y RGPD.
- Olvidar subdominios:
www,blog,stagingo landing de campañas pueden quedar desprotegidos.
Cabeceras de seguridad, monitorización y mantenimiento
Las cabeceras no se configuran una vez y olvidan. Cambios en plugins, nuevos scripts de marketing o migraciones pueden invalidar una CSP que funcionaba. Integra la revisión en tu rutina de monitorización y en el plan de mantenimiento web:
- Revisión trimestral de puntuación en herramientas públicas.
- Alerta si desaparece HSTS o CSP tras un despliegue.
- Registro de cambios cuando se añade un nuevo script de terceros.
Una web que cae porque una CSP mal configurada bloquea el JavaScript del menú móvil es tan problemática como un timeout de servidor.
Conclusión
Las cabeceras de seguridad HTTP son la diferencia entre una web que “tiene HTTPS” y una web preparada para resistir ataques automatizados y revisiones exigentes de clientes. Empieza por las cabeceras de bajo riesgo, prueba la CSP en modo report-only y documenta cada excepción para scripts legítimos.
En aatsoft, agencia de desarrollo web en Manresa (Barcelona), auditamos cabeceras, CSP y configuración de servidor en proyectos nuevos y en webs ya publicadas. Si nunca has revisado las cabeceras de tu dominio, es el momento de hacerlo antes de que un incidente te obligue.
