Comprobador de cabeceras HTTP

¿Qué son las cabeceras HTTP?

Las cabeceras HTTP son metadatos que se envían entre el navegador y el servidor web con cada solicitud y respuesta HTTP. Contienen información esencial sobre seguridad, caché, compresión y cómo debe procesar el navegador el contenido. Con nuestro Comprobador de cabeceras HTTP gratuito puedes analizar todas las cabeceras de cualquier página web y ver al momento los posibles riesgos de seguridad y las oportunidades de optimización.

Las cabeceras son invisibles para los visitantes, pero tienen un papel clave en el funcionamiento de la web moderna. Cada vez que tu navegador solicita una página web, se intercambian decenas de cabeceras. El navegador envía cabeceras de solicitud (como User-Agent, Accept-Language) y el servidor responde con cabeceras de respuesta (como Content-Type, Cache-Control, cabeceras de seguridad). Este intercambio determina cómo se muestra el contenido, cómo se guarda en caché y cómo se protege.

Hay varias categorías de cabeceras: cabeceras de seguridad que protegen contra ataques, cabeceras de caché que mejoran el rendimiento, cabeceras de contenido que indican el tipo y la codificación, y cabeceras CORS que gestionan las solicitudes cross-origin. Un Comprobador de cabeceras HTTP completo te da una visión de todas las categorías y muestra dónde se puede mejorar.

¿Por qué son importantes las cabeceras de seguridad?

Las cabeceras de seguridad son una línea de defensa clave contra los ataques web más habituales. Funcionan como una capa de seguridad adicional por encima del código de tu aplicación y protegen tanto tu página web como a tus visitantes. Incluso con un código perfectamente protegido, la falta de cabeceras de seguridad puede dejarte expuesto a ataques. Nuestro Comprobador de cabeceras HTTP revisa todas las cabeceras de seguridad esenciales y te da recomendaciones concretas.

Las cabeceras de seguridad protegen tu página web y a tus visitantes contra:

• Ataques XSS (Cross-Site Scripting): con Content-Security-Policy (CSP) evitas que se ejecuten scripts maliciosos
• Clickjacking: con X-Frame-Options te proteges de iframes invisibles que interceptan clics
• Ataques man-in-the-middle: con HSTS obligas a usar conexiones HTTPS cifradas
• Ataques de MIME sniffing: con X-Content-Type-Options evitas que los navegadores adivinen el tipo de contenido
• Ataques cross-origin: con las cabeceras COOP y CORP aíslas tu página web de otros orígenes
• Fugas de referrer: con Referrer-Policy controlas qué información se transmite
• Abuso de funciones del navegador: con Permissions-Policy limitas el acceso a API sensibles del navegador

Sin las cabeceras de seguridad adecuadas, tu página web es vulnerable a ataques, aunque el propio código sea seguro. Los investigadores de seguridad y los pentesters siempre revisan primero las cabeceras HTTP para identificar vulnerabilidades. Grandes empresas tecnológicas como Google, Facebook y Microsoft aplican políticas estrictas de cabeceras de seguridad. Con nuestra herramienta haces las mismas comprobaciones que en una auditoría de seguridad profesional.

Las cabeceras de seguridad más importantes

Strict-Transport-Security (HSTS): esta cabecera obliga a los navegadores a conectarse a tu página web solo por HTTPS. Impide que los atacantes rebajen a los usuarios a tráfico HTTP inseguro (ataques de SSL stripping). En cuanto un navegador recibe esta cabecera, durante el periodo indicado convierte automáticamente todas las solicitudes HTTP en HTTPS, aunque el usuario escriba expresamente http://. Configuración recomendada: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. El valor max-age indica cuánto tiempo (en segundos) debe recordarlo el navegador, includeSubDomains lo aplica a todos los subdominios y preload hace que tu página web pueda entrar en la lista de precarga HSTS de los navegadores.

Content-Security-Policy (CSP): la cabecera de seguridad más eficaz contra los ataques XSS. CSP determina qué fuentes (scripts, hojas de estilo, imágenes, tipografías) puede cargar y ejecutar el navegador. Así se impide que se ejecuten scripts maliciosos inyectados, incluso si un atacante consigue inyectar código en tu HTML. Una CSP básica puede ser así: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'. Para la máxima seguridad, evita 'unsafe-inline' y usa nonces o hashes.

X-Frame-Options: impide que tu página web se cargue dentro de un iframe, lo que frena los ataques de clickjacking. En el clickjacking, un atacante coloca tu página web en un iframe invisible sobre una interfaz falsa, de modo que los usuarios realizan acciones en tu página web sin darse cuenta. Usa X-Frame-Options: DENY para bloquear cualquier framing, o X-Frame-Options: SAMEORIGIN para permitir el framing solo desde tu propio dominio. En los navegadores modernos, Content-Security-Policy: frame-ancestors 'none' es una solución más flexible.

X-Content-Type-Options: impide el MIME sniffing indicando al navegador que respete el tipo de contenido declarado. A veces los navegadores intentan «adivinar» el tipo de contenido si no está claro, lo que puede causar problemas de seguridad. Un archivo text/plain, por ejemplo, podría interpretarse como JavaScript si contiene código ejecutable. Usa siempre X-Content-Type-Options: nosniff para evitarlo.

Todas las cabeceras de seguridad de un vistazo

Un resumen completo de todas las cabeceras de seguridad importantes que puedes implementar para obtener la máxima protección. Nuestro Comprobador de cabeceras HTTP revisa todas estas cabeceras:

Content-Security-Policy en detalle

Content-Security-Policy (CSP) es la cabecera de seguridad más compleja, pero también la más eficaz. Una CSP bien configurada puede eliminar casi por completo los ataques XSS. CSP funciona con directivas que determinan qué fuentes se permiten para cada tipo de contenido.

Directivas CSP más importantes:

• default-src: política por defecto para todos los tipos de recursos. Las demás directivas la heredan.
• script-src: determina qué fuentes de JavaScript se pueden cargar y ejecutar. Clave para la protección contra XSS.
• style-src: controla qué hojas de estilo y estilos inline se permiten.
• img-src: determina desde qué fuentes se pueden cargar imágenes.
• font-src: controla las fuentes permitidas para las tipografías.
• connect-src: limita a qué URL se puede acceder mediante fetch, XMLHttpRequest y WebSocket.
• frame-src: determina qué URL se pueden cargar en frames (parecido a X-Frame-Options, pero para contenido incrustado).
• media-src: controla las fuentes de los elementos de audio y vídeo.
• object-src: determina las fuentes permitidas para los elementos <object>, <embed> y <applet>.

Valores de fuente CSP: cada directiva acepta una lista de fuentes permitidas. Puedes usar: 'self' (tu propio dominio), 'none' (nada permitido), dominios concretos como https://cdn.example.com, 'unsafe-inline' (scripts/estilos inline, inseguro), 'unsafe-eval' (la función eval(), inseguro) o nonces/hashes para scripts inline concretos.

Nonces y hashes: para la máxima seguridad, evita 'unsafe-inline' y usa en su lugar nonces o hashes. Un nonce es un valor aleatorio único que generas en cada solicitud y que añades tanto a la cabecera CSP como a la etiqueta script: Content-Security-Policy: script-src 'nonce-abc123' y <script nonce="abc123">. Los hashes son hashes SHA-256/384/512 del contenido exacto del script: script-src 'sha256-xyz...'.

Report-URI y reporting: CSP puede notificar las infracciones a un endpoint: report-uri /csp-report o con la directiva más moderna report-to. Así puedes vigilar si se bloquea contenido legítimo y si hay intentos de ataque. Empieza siempre con Content-Security-Policy-Report-Only para hacer pruebas sin bloquear contenido.

Cabeceras de rendimiento y caché

Además de la seguridad, nuestro Comprobador de cabeceras HTTP también analiza las cabeceras de rendimiento y caché, que son clave para que una página web sea rápida:

• Content-Encoding: comprueba si la compresión está activa. Las páginas web modernas usan compresión gzip o Brotli para reducir los archivos de texto (HTML, CSS, JavaScript) entre un 70 y un 80 %. Content-Encoding: br (Brotli) comprime mejor que gzip, pero no todos los navegadores lo admiten. Content-Encoding: gzip es la opción segura que funciona en todas partes. Sin compresión, las páginas cargan mucho más despacio, sobre todo en conexiones móviles.
• Cache-Control: analiza la configuración de caché para obtener un rendimiento óptimo. Esta cabecera determina cuánto tiempo pueden guardar en caché el contenido los navegadores y las CDN. Para los recursos estáticos (CSS, JS, imágenes), usa Cache-Control: public, max-age=31536000, immutable para guardarlos en caché durante un año. Para el contenido dinámico, usa Cache-Control: private, max-age=0, must-revalidate. Una buena estrategia de caché puede reducir la carga de tu servidor en un 90 % y mejorar mucho los tiempos de carga.
• ETag: comprueba si la validación de caché está activada. Un ETag es un identificador único de una versión concreta de un recurso. Si un navegador tiene contenido en caché, envía el ETag en una cabecera If-None-Match. Si el contenido no ha cambiado, el servidor responde con 304 Not Modified sin enviar el contenido completo, lo que ahorra ancho de banda.
• Vary: muestra qué cabeceras de solicitud influyen en la caché. Vary: Accept-Encoding indica a las cachés que guarden tanto la versión comprimida como la no comprimida. Vary: User-Agent guarda en caché versiones distintas por tipo de navegador (a menudo innecesario e ineficiente). Para las páginas web responsive modernas, Vary: Accept-Encoding suele ser suficiente.
• Last-Modified: indica cuándo se modificó el contenido por última vez y funciona junto con If-Modified-Since para la validación de caché.

Unas cabeceras de caché correctas pueden hacer tu página web bastante más rápida, reducir la carga del servidor y bajar mucho los costes de ancho de banda. Para el hosting WordPress u otras plataformas CMS, unas buenas cabeceras de caché son esenciales para el rendimiento.

¿Cómo mejoras tu puntuación de seguridad?

Después de usar el Comprobador de cabeceras HTTP, nuestra herramienta da una puntuación por categoría y recomendaciones concretas. Puedes implementar las cabeceras de seguridad de varias formas:

1. Configuración del servidor web: el método más eficiente es definir las cabeceras a nivel de servidor web. En Apache (.htaccess), Nginx o IIS puedes añadir cabeceras que se aplican a todas las solicitudes. Es más rápido que las cabeceras a nivel de aplicación, porque el servidor web las añade directamente sin ejecutar PHP ni otro código de aplicación. Con un hosting VPS tienes control total sobre la configuración del servidor web.

2. Código de la aplicación: en PHP, Node.js, Python u otros lenguajes puedes añadir cabeceras mediante programación. Esto da más flexibilidad (por ejemplo, políticas CSP distintas por página), pero es algo más lento. En las páginas web con WordPress puedes añadir cabeceras mediante functions.php o plugins de seguridad.

3. Nivel de CDN/proxy: servicios como Cloudflare, AWS CloudFront u otras CDN pueden añadir o modificar cabeceras. Es ideal para las páginas web que ya usan una CDN. Cloudflare, por ejemplo, tiene «Transform Rules» sencillas para añadir cabeceras.

4. Plugins del CMS: para WordPress hay muy buenos plugins de seguridad que configuran las cabeceras automáticamente, como Really Simple SSL, Security Headers o All In One WP Security. Estos plugins ofrecen una interfaz fácil de usar, sin que tengas que editar archivos de configuración.

Empieza por las cabeceras esenciales (HSTS, CSP, X-Frame-Options, X-Content-Type-Options) y después añade otras cabeceras de seguridad como Referrer-Policy y Permissions-Policy. Prueba siempre a fondo después de añadir cabeceras; sobre todo CSP puede bloquear funciones legítimas si está configurada de forma demasiado estricta.

Cabeceras HTTP para WordPress

Las páginas web con WordPress tienen puntos específicos a tener en cuenta en cuanto a cabeceras HTTP. Por defecto, WordPress envía muy pocas cabeceras de seguridad, así que tienes que añadirlas tú. Hay tres métodos para añadir cabeceras a WordPress:

Método 1: con .htaccess (Apache): si tu página web funciona con Apache (la mayoría de los planes de hosting web), añade estas reglas al archivo .htaccess en la raíz de WordPress:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"
</IfModule>

Atención: esta CSP es bastante permisiva con 'unsafe-inline' y 'unsafe-eval', porque WordPress y muchos plugins usan scripts inline. Para una CSP más estricta, puede que tengas que adaptar el código de los plugins.

Método 2: con wp-config.php: puedes añadir cabeceras en wp-config.php (añádelo antes de la línea «That's all, stop editing!»):

header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
header('X-Frame-Options: SAMEORIGIN');
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');

Método 3: con functions.php: añade esta función en el archivo functions.php de tu tema (o en un plugin propio):

function add_security_headers() {
  header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
  header('X-Frame-Options: SAMEORIGIN');
  header('X-Content-Type-Options: nosniff');
}
add_action('send_headers', 'add_security_headers');

Plugins de WordPress: para una configuración más sencilla puedes usar plugins como «HTTP Headers» (de Dimitar Ivanov) o «Security Headers», que ofrecen una interfaz gráfica para configurar las cabeceras. Really Simple SSL también añade automáticamente algunas cabeceras de seguridad tras activarlo. Con el hosting WordPress de Theory7 también puedes contactar con soporte para que te ayudemos a configurar las cabeceras.

Cabeceras HTTP para Apache y Nginx

La configuración de las cabeceras HTTP es distinta en los servidores web Apache y Nginx. Los dos son buenas opciones, pero la sintaxis es diferente.

Configuración de Apache (.htaccess o httpd.conf):

En Apache se usa el módulo mod_headers. Añade lo siguiente en .htaccess o en la configuración de tu virtual host:

<IfModule mod_headers.c>
  # Security headers
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'"

  # Performance headers
  Header always set Cache-Control "public, max-age=31536000, immutable" "expr=%{REQUEST_URI} =~ m#\.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$#"
  Header always set Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#\.(html|php)$#"
</IfModule>

Asegúrate de que mod_headers está activado: a2enmod headers, y reinicia Apache.

Configuración de Nginx (nginx.conf o bloque server):

En Nginx, añade las cabeceras en tu bloque server o en el contexto location:

server {
  # Security headers
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
  add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'" always;

  # Static assets caching
  location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    expires 1y;
  }

  # Dynamic content
  location ~* \.(html|php)$ {
    add_header Cache-Control "no-cache, no-store, must-revalidate";
  }
}

Después de hacer cambios, prueba la configuración con nginx -t y recárgala con nginx -s reload. La palabra clave always hace que las cabeceras se añadan también en las respuestas de error (4xx, 5xx).

En ambos servidores web: después de añadir cabeceras, prueba a fondo con nuestro Comprobador de cabeceras HTTP y comprueba que tu página web sigue funcionando correctamente.

Códigos de estado HTTP

Los códigos de estado HTTP se envían en las cabeceras e indican si una solicitud se ha realizado correctamente. Nuestra herramienta muestra el código de estado en cada comprobación. Códigos habituales:

El código de estado está en la primera línea de las cabeceras de respuesta, por ejemplo HTTP/1.1 200 OK. En las redirecciones (301/302), la nueva dirección se indica en la cabecera Location. En caso de error, los servidores suelen enviar una cabecera Content-Type: text/html con una página de error. Los códigos de estado correctos son clave para el SEO: usa 301 para las redirecciones permanentes y asegúrate de que las páginas eliminadas devuelven 404 (no 200).

Las cabeceras CORS

Las cabeceras CORS (Cross-Origin Resource Sharing) determinan si una página web puede cargar recursos de otro dominio. Por defecto, los navegadores bloquean las solicitudes cross-origin por motivos de seguridad. Las cabeceras CORS dan un permiso explícito.

Access-Control-Allow-Origin: la cabecera CORS más importante. Determina qué orígenes tienen acceso a tus recursos. Access-Control-Allow-Origin: * permite todos los orígenes (peligroso para API sensibles), Access-Control-Allow-Origin: https://example.com solo permite ese dominio concreto. En las API que se llaman desde el navegador (por ejemplo, solicitudes AJAX), esta cabecera tiene que estar bien configurada.

Access-Control-Allow-Methods: indica qué métodos HTTP se permiten: Access-Control-Allow-Methods: GET, POST, PUT, DELETE. Por defecto, en las solicitudes simples solo se permiten GET y POST.

Access-Control-Allow-Headers: define qué cabeceras de solicitud puede enviar el cliente: Access-Control-Allow-Headers: Content-Type, Authorization. Necesaria para cabeceras personalizadas o tokens de autenticación.

Access-Control-Allow-Credentials: determina si se pueden enviar cookies y cabeceras de autenticación: Access-Control-Allow-Credentials: true. Si el valor es true, Access-Control-Allow-Origin no puede ser *.

Solicitudes preflight: en las solicitudes «no simples» (por ejemplo, PUT, DELETE o cabeceras personalizadas), el navegador envía primero una solicitud OPTIONS (preflight) para comprobar si la solicitud está permitida. El servidor tiene que responder entonces con las cabeceras CORS correctas. Una respuesta preflight tiene este aspecto:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

La cabecera Access-Control-Max-Age indica cuánto tiempo (en segundos) se puede guardar en caché la respuesta preflight, lo que mejora el rendimiento. Para las API web y los endpoints protegidos con SSL, unas cabeceras CORS correctas son esenciales.

Cabeceras en HTTP/2 y HTTP/3

Los protocolos modernos HTTP/2 y HTTP/3 gestionan las cabeceras de forma más eficiente que HTTP/1.1, pero los nombres y valores de las cabeceras siguen siendo en gran parte los mismos. Nuestro Comprobador de cabeceras HTTP funciona con todas las versiones de HTTP.

Mejoras de HTTP/2: HTTP/2 introduce la compresión de cabeceras HPACK, que reduce mucho el tamaño de las cabeceras. Las cabeceras se codifican con codificación Huffman y una tabla estática/dinámica de cabeceras frecuentes. Esto ahorra ancho de banda porque, por ejemplo, Content-Type: text/html se codifica como un solo byte en lugar de 24 bytes. HTTP/2 también admite multiplexación, de modo que varias solicitudes comparten la misma conexión y la sobrecarga de las cabeceras se reduce aún más.

Pseudocabeceras en HTTP/2: HTTP/2 usa pseudocabeceras especiales que empiezan por dos puntos: :method, :path, :scheme, :authority. Sustituyen a la primera línea de las solicitudes HTTP/1.1 (GET /path HTTP/1.1). Para los desarrolladores suelen ser invisibles, porque las bibliotecas se encargan de ello automáticamente.

HTTP/3 y QUIC: HTTP/3 se basa en HTTP/2, pero usa QUIC en lugar de TCP como protocolo de transporte. Las cabeceras funcionan igual que en HTTP/2, pero QPACK (una versión mejorada de HPACK) ofrece una compresión aún mejor y resiste mejor la pérdida de paquetes. HTTP/3 usa UDP en lugar de TCP, lo que reduce la latencia porque no hace falta un handshake TCP.

Server Push (HTTP/2): HTTP/2 admite Server Push: el servidor envía recursos de forma proactiva antes de que el navegador los pida. Funciona con la cabecera Link con rel=preload: Link: </style.css>; rel=preload; as=style. Server Push es experimental y no todas las CDN lo admiten. HTTP/3 ha eliminado push en favor de Early Hints (HTTP 103).

Consideraciones para la migración: si migras a HTTP/2 o HTTP/3, tus cabeceras de seguridad, de caché y CORS siguen funcionando exactamente igual. Los protocolos son compatibles con versiones anteriores a nivel de cabeceras. Eso sí, tienes que configurar correctamente tus certificados SSL/TLS, porque HTTP/2 y HTTP/3 requieren HTTPS. En un VPS o en servidores dedicados necesitas nginx 1.9.5+ o Apache 2.4.17+ para que HTTP/2 funcione.

Comprueba con nuestra herramienta qué protocolo usa tu página web: la versión de HTTP aparece en las cabeceras de respuesta. HTTP/2 y HTTP/3 pueden mejorar los tiempos de carga entre un 20 y un 50 %, sobre todo en páginas web con muchos recursos pequeños.