Comprobador de cabeceras HTTP
Seguridad, compresión y caché
Este comprobador de cabeceras HTTP lee la respuesta de cualquier página y la evalúa de una vez: las ocho cabeceras de seguridad, la compresión, la caché y lo que revela el servidor. Luego escribe las líneas que corrigen cada fallo, para Apache, Nginx o un archivo de cabeceras.
- GratisPrecio
- 23Comprobaciones
- IncluidaCorrección
- NadaSe guarda
Comprobador de cabeceras HTTP
Ocho cabeceras de seguridad, compresión y caché, evaluadas de una vez
- Puntuación
- —
- Correctas
- 0
- Avisos
- 0
- Fallos
- 0
- Primer byte
- —
| Cabecera | Valor | Veredicto | Qué significa |
|---|---|---|---|
| Pega una dirección arriba y la respuesta aparecerá aquí. | |||
La puntuación es nuestra propia ponderación de las filas de arriba, no una nota del sector. HTTPS, la política y la compresión pesan más; lo marcado como información no pesa nada.
Líneas listas para cada cabecera de arriba que falló o dio aviso. Elige tu servidor, pega las líneas y vuelve a comprobar.
Listo. Pega cualquier dirección pública y este servidor abre dos conexiones con ella.
Lo que deciden las cabeceras de respuesta
Cada página llega con unas líneas que el visitante nunca ve. Esas líneas son las cabeceras de respuesta.
Le dicen al navegador cómo tratar la página: qué scripts pueden ejecutarse, si puede ir dentro de un marco, cuánto tiempo puede guardarse y si llegó comprimida.
Así que dos páginas con el mismo contenido pueden ser muy distintas en velocidad y seguridad. La diferencia está por completo en las cabeceras.
Este comprobador las lee de una dirección real, evalúa cada una y después te da la configuración que corregiría las débiles.
Las ocho cabeceras de seguridad
Strict-Transport-Security mantiene los navegadores en HTTPS. Content-Security-Policy decide qué scripts pueden ejecutarse, lo que es la principal defensa contra el código inyectado.
X-Content-Type-Options obliga al navegador a respetar el tipo de archivo declarado, sin hacer suposiciones. La protección de marcos, con X-Frame-Options o frame-ancestors, evita que otros sitios metan el tuyo en un marco para robar clics.
Referrer-Policy limita lo que tu dirección revela a otros sitios. Además, Permissions-Policy apaga la cámara, el micrófono y la ubicación salvo que una página los pida.
Por último, las dos políticas cross-origin impiden que otras ventanas y otros sitios accedan a la página. Juntas, estas ocho cierran la mayoría de las puertas que un atacante prueba primero.
Por qué la compresión se comprueba aparte
Un servidor solo comprime cuando el navegador lo pide. Por eso esta herramienta abre una segunda conexión que ofrece gzip y brotli, e informa de lo que vuelve.
La compresión suele reducir una página HTML en torno a un setenta por ciento. Por esa razón es una de las mejoras de velocidad más baratas, y también una de las que más a menudo falta.
La cabecera Vary se revisa con ella, ya que una página comprimida sin Vary: Accept-Encoding puede servirse al navegador equivocado desde una caché compartida.
La caché en palabras sencillas
Cache-Control marca durante cuánto tiempo sirve una copia guardada. Sin ella, cada navegador y cada proxy inventa su propia regla, y rara vez coinciden.
ETag y Last-Modified permiten que un navegador que vuelve pregunte si su copia sigue vigente. Como resultado, puede recibir una respuesta mínima de "no modificado" en lugar de toda la página otra vez.
Lo que revela el servidor
Las cabeceras Server y X-Powered-By suelen nombrar el software y la versión exactos. Eso no ayuda a ningún visitante, aunque sí le ahorra un paso a un atacante.
También se revisan las cookies. Cada una debería llevar Secure, HttpOnly y SameSite; si no, puede viajar sin cifrar o leerse desde un script.
La línea exacta que arregla cada fallo
Para cada fila fallida que una línea de configuración puede arreglar, la herramienta escribe esa línea. Eliges Apache, Nginx o un archivo _headers, y el bloque cambia en consecuencia.
La línea de Content-Security-Policy se escribe como Report-Only a propósito. Una política genérica activada de golpe puede bloquear los propios scripts de un sitio, mientras que el modo informe muestra primero lo que se rompería.
Algunas cosas no son problemas de cabeceras, como un primer byte lento. Por eso se listan, pero quedan fuera del bloque, así nada en él finge arreglar lo que no puede.
Sobre la puntuación
La puntuación es nuestra propia ponderación, no un estándar del sector. HTTPS, la política de contenido y la compresión cuentan más, mientras que las filas informativas no cuentan nada.
En esta página
- La herramienta
- Lo que deciden las cabeceras de respuesta
- Cómo usar el comprobador de cabeceras HTTP
- Qué hace diferente a este comprobador de cabeceras
- Reglas para configurar las cabeceras de respuesta
- Seis errores de cabeceras que siguen ocultos
- Preguntas frecuentes sobre cabeceras HTTP
- Herramientas para revisar un servidor
Sigue leyendo
Cómo usar el comprobador de cabeceras HTTP
Una dirección entra; sale una respuesta evaluada y una corrección lista.
- 1
Pon la URL que quieres revisar
Sirve cualquier página pública, y las redirecciones se siguen hasta la respuesta final.
- 2
Lee la puntuación y la lista
Los fallos van primero dentro de cada grupo. Cada fila dice qué encontró y por qué importa.
- 3
Elige tu servidor
Elige Apache, Nginx o un archivo _headers, y el bloque de corrección se reescribe para ese servidor.
- 4
Pega la línea, recarga y pasa la prueba otra vez
Añade las líneas, recarga el servidor y luego repite la revisión para ver cómo las filas se ponen en verde.
Qué hace diferente a este comprobador de cabeceras
La mayoría de herramientas imprimen la lista sin procesar y se detienen. Esta, en cambio, la explica y la corrige.
Seguridad, velocidad y caché juntas
Veintitrés comprobaciones en cinco grupos, en lugar de tres herramientas separadas que ven cada una solo una parte.
La corrección, escrita para ti
Líneas listas para Apache, Nginx o un archivo _headers, solo para las filas que las necesitan.
Compresión probada de verdad
Una segunda conexión pide gzip y brotli, así que la respuesta refleja lo que recibe un navegador real.
Valores seguros por defecto
La política de contenido llega primero en modo informe, así que probar la corrección no puede romper el sitio.
Cabeceras sin procesar a un toque
La lista sin editar tiene su propia pestaña para quien quiera leer cada línea.
No se guarda nada
La dirección sirve para una comprobación y luego desaparece. Además, este servidor no escribe ningún registro de ella.
Reglas para configurar las cabeceras de respuesta
Ocho hábitos que mantienen bien las cabeceras después de la primera corrección.
- Arregla HTTPS antes que nada. Toda cabecera de seguridad supone una conexión cifrada. Sobre HTTP sin cifrar, la mayoría no hace nada.
- Introduce la política de contenido poco a poco. Empieza en modo informe, lee lo que bloquearía y actívala cuando los informes estén tranquilos.
- Sube HSTS por etapas. Empieza con un max-age corto, confirma que todos los subdominios sirven HTTPS y luego pasa a un año completo.
- Comprime texto, no imágenes. HTML, CSS, JavaScript y SVG se reducen mucho. En cambio, JPEG y WebP ya están comprimidos, así que gzip no gana nada ahí.
- Di algo sobre la caché. Incluso no-store es mejor que el silencio, porque el silencio deja que cada caché adivine de forma distinta.
- Oculta los números de versión. Desactiva los server tokens y X-Powered-By. Solo ayudan a los atacantes.
- Marca cada cookie. Secure, HttpOnly y SameSite en cada una, incluidas las cookies que ponen los plugins.
- Repite la prueba después de cada subida a producción. Un servidor nuevo, un CDN o un plugin pueden quitar cabeceras sin avisar, así que repite la revisión cada vez que cambie el sistema.
Seis errores de cabeceras que siguen ocultos
Ninguno se ve en la página, y justamente por eso duran años.
Una política con unsafe-inline
Parece una política de contenido, aunque deja ejecutar scripts inyectados. En su lugar, usa un nonce o un hash.
Mandar HSTS por una conexión sin HTTPS
Ahí los navegadores lo ignoran. Solo cuenta cuando llega en una respuesta HTTPS.
Cabeceras solo en la portada
Las cabeceras de seguridad puestas en una plantilla no llegan al resto de páginas. Por eso conviene ponerlas en el servidor.
Compresión desactivada por un proxy
Un CDN o un cortafuegos delante del sitio puede deshacer lo que puso el origen. Así que revisa la dirección que usan los visitantes.
Cabeceras duplicadas
Dos valores distintos para la misma cabecera, uno de la aplicación y otro del servidor, dejan que el navegador elija.
Feature-Policy en lugar de Permissions-Policy
El nombre antiguo se retiró hace años. Los navegadores actuales solo leen el nuevo.
Preguntas frecuentes sobre cabeceras HTTP
¿Para qué sirven las cabeceras HTTP?
Son líneas cortas que viajan con cada respuesta, antes de la página. Le dicen al navegador cómo tratar lo que viene después.
¿Qué cabeceras de seguridad no deberían faltar en ninguna web?
Como mínimo Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, la protección de marcos, Referrer-Policy y Permissions-Policy. Además, las dos políticas cross-origin añaden más protección.
¿Suben en Google las webs con HSTS y CSP?
No directamente. Sin embargo, HTTPS es una señal de posicionamiento, y la compresión y la caché hacen las páginas más rápidas, lo que sí cuenta.
¿Dónde pego la corrección?
En Apache, en .htaccess con mod_headers activado. Si usas Nginx, va en el bloque server. En Netlify o Cloudflare Pages, en un archivo _headers en la raíz del sitio.
¿La política de contenido romperá mi sitio?
La que se escribe aquí no, porque es Report-Only. No bloquea nada y, en cambio, lista lo que bloquearía una política activa.
¿Por qué mi puntuación es distinta en otras herramientas?
Cada herramienta pondera las filas a su manera. Además, esta cuenta la compresión y la caché, que los escáneres de seguridad puros ignoran.
Uso WordPress. ¿De dónde salen las cabeceras?
Normalmente del servidor o de un plugin. Por eso las líneas de .htaccess funcionan en la mayoría de alojamientos WordPress con Apache.
¿Por qué no se mide la compresión?
La segunda conexión, la que pide gzip, no terminó. Entonces la fila queda sin juzgar en lugar de adivinarse.
¿En qué se diferencia del comprobador de códigos de estado?
El comprobador de códigos de estado muestra qué responde una dirección y adónde redirige. En cambio, este evalúa las cabeceras de esa respuesta y escribe la corrección.
¿Se guarda la dirección que reviso?
No. Sirve para una sola comprobación y luego desaparece, y no se registra nada.
Herramientas para revisar un servidor
Las cabeceras son una capa de la respuesta. Estas tres revisan las demás.
Mira qué código devuelve cada URL
El estado que devuelve una dirección y cada salto por el camino.
Abrir herramienta →Comprobador SSL
Caducidad del certificado, nombres cubiertos y si los navegadores confían en él.
Abrir herramienta →Rastrea cada 301 y 302 hasta la URL final
Todos los 301 y 302 desde la URL inicial hasta la definitiva.
Abrir herramienta →
¿Listo para revisar tus cabeceras?
Pega una dirección, lee la nota y copia la corrección para tu servidor. El comprobador de cabeceras HTTP es gratis, no necesita cuenta y no guarda ningún registro.