Cabeceras HTTP

Cada cabecera de seguridad HTTP cumple un rol defensivo específico contra vectores de ataque bien documentados: • Strict-Transport-Security (HSTS) — Instruye al navegador a conectarse exclusivamente por HTTPS durante el periodo definido en max-age (RFC 6797). Sin HSTS, la primera conexión puede ocurrir por HTTP plano, habilitando ataques de SSL stripping como los demostrados por Moxie Marlinspike en 2009. La directiva includeSubDomains protege todos los subdominios, y preload permite la inclusión en la lista HSTS preload embebida en navegadores Chromium, Firefox y Safari. El valor mínimo recomendado por OWASP es max-age=31536000 (1 año). • Content-Security-Policy (CSP) — Define una lista blanca de origenes permitidos para scripts, estilos, imagenes, fonts, frames y otros recursos (CSP Level 3, W3C). Es la defensa principal contra Cross-Site Scripting (XSS). Una política como default-src 'self'; script-src 'self' bloquea la ejecución de scripts inline e inyecciones de terceros. Las directivas clave incluyen script-src, style-src, img-src, frame-ancestors (reemplazo moderno de X-Frame-Options), connect-src y upgrade-insecure-requests. • X-Frame-Options — Controla si la página puede ser embebida en un iframe (RFC 7034). Los valores DENY y SAMEORIGIN previenen ataques de clickjacking. Aunque frame-ancestors en CSP es su sucesor, X-Frame-Options sigue siendo necesario para navegadores legacy y como capa de defensa en profundidad. • X-Content-Type-Options — Con el valor nosniff, previene que los navegadores realicen MIME sniffing y reinterpreten el Content-Type del recurso. Sin esta cabecera, un archivo subido como text/plain podría ser interpretado como text/html y ejecutar JavaScript malicioso. • Referrer-Policy — Controla que información del URL de origen se envía en la cabecera Referer al navegar a otro sitio. strict-origin-when-cross-origin es el valor recomendado: envía solo el origen (sin path ni query) en peticiones cross-origin, evitando filtrar tokens, IDs de sesión o parámetros sensibles presentes en la URL. • Permissions-Policy (antes Feature-Policy) — Restringe el acceso a APIs del navegador como camara, microfono, geolocalización, autoplay, payment y USB. Una configuración como geolocation=(), camera=(), microphone=() deshabilita estas funciones para la página y cualquier iframe embebido, reduciendo la superficie de ataque en caso de XSS.

Las auditorías de seguridad revelan errores recurrentes en la implementación de cabeceras HTTP: • CSP demasiado permisivo — Politicas con unsafe-inline o unsafe-eval en script-src anulan la protección contra XSS. El uso de wildcards (*.example.com) o CDNs públicos como origenes permitidos introduce riesgos de bypass, ya que un atacante puede subir código malicioso a esos dominios. La solución es usar nonces (script-src 'nonce-<random>') o hashes (script-src 'sha256-<hash>') para scripts inline. • HSTS sin includeSubDomains — Protege el dominio principal pero deja los subdominios vulnerables a SSL stripping. Un atacante puede interceptar conexiones a sub.example.com y redirigir al usuario a un sitio de phishing. Además, sin includeSubDomains no es posible agregar el dominio a la lista preload de navegadores. • Ausencia total de cabeceras — Muchos frameworks y servidores no incluyen cabeceras de seguridad por defecto. Un servidor Nginx o Apache con configuración vanilla no envía HSTS, CSP ni X-Frame-Options. Cada cabecera ausente es un vector de ataque habilitado. • Divulgación de información — Cabeceras como Server: Apache/2.4.51 (Ubuntu) o X-Powered-By: PHP/8.1.0 revelan versiones exactas del software, facilitando la busqueda de exploits específicos en bases de datos como CVE y Exploit-DB. La recomendación es eliminar o generalizar estas cabeceras. • X-Frame-Options ALLOW-FROM — Este valor no fue estandarizado y no funciona en navegadores modernos basados en Chromium. Se debe usar frame-ancestors en CSP como reemplazo. • Cache-Control mal configurado — Paginas con datos sensibles (dashboards, perfiles) que no incluyen Cache-Control: no-store pueden quedar almacenadas en caches intermedios o en el historial del navegador, exponiendo información tras el cierre de sesión.

La configuración de cabeceras de seguridad varia según la infraestructura. Ejemplos practicos para los entornos más comunes: • Nginx — Las cabeceras se agregan en el bloque server o location con la directiva add_header. Es importante usar el flag always para que se apliquen incluso en respuestas de error (4xx, 5xx). Ejemplo: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; add_header X-Content-Type-Options "nosniff" always;. Nota: add_header en un bloque location sobreescribe las cabeceras del bloque server padre; se deben repetir todas las cabeceras necesarias. • Apache — Se utiliza el módulo mod_headers con la directiva Header set o Header always set. Ejemplo: Header always set X-Frame-Options "DENY". La configuración puede ir en httpd.conf, en archivos de virtual host, o en .htaccess (con AllowOverride habilitado). El módulo mod_headers debe estar cargado (a]2enmod headers en Debian/Ubuntu). • Cloudflare — Ofrece HSTS gestionado desde el panel (SSL/TLS > Edge Certificates > HSTS). Para cabeceras personalizadas se utilizan Transform Rules o Workers. Un Worker permite inyectar todas las cabeceras de seguridad en la respuesta con response.headers.set() sin modificar el servidor origen. • Vercel / Next.js — Las cabeceras se definen en next.config.js dentro del array headers(), aplicando patrones de ruta. Ejemplo: { source: '/(.*)', headers: [{ key: 'X-Frame-Options', value: 'DENY' }] }. Vercel aplica estas cabeceras a nivel CDN. • AWS CloudFront — Se utilizan Response Headers Policies para definir cabeceras de seguridad a nivel de distribución. AWS provee una política predefinida llamada SecurityHeadersPolicy que incluye HSTS, X-Content-Type-Options, X-Frame-Options y Referrer-Policy con valores recomendados.