Verificador de Cabeceras HTTP
Inspecciona cabeceras HTTP y postura de seguridad de cualquier URL.
🌐 sitekits fetches the URL server-side (private/internal addresses are blocked). Response body is not retrieved.
Descripción general
Las cabeceras de respuesta son donde de verdad se configura la mayor parte del comportamiento de un sitio —caché, compresión, política de seguridad, CORS, redirecciones— y son justo la parte que no puedes ver en el navegador sin abrir DevTools sobre la petición correcta.
Esta herramienta pide una URL desde el servidor y devuelve las cabeceras de respuesta, más la cadena completa de redirecciones que llevó hasta ahí. Como el propio modelo de seguridad del navegador oculta a JavaScript las cabeceras de respuesta de otros orígenes, esta es una de las pocas herramientas de aquí que no puede ejecutarse por completo en tu página.
Cómo se usa
- Escribe una URL. El esquema es opcional:
example.comse trata comohttps://example.com. - Lee primero la cadena de redirecciones. Cada salto muestra su URL y su código de estado.
- Lee las cabeceras de la respuesta final.
Las cadenas de redirecciones suelen ser la respuesta
Cuando algo va lento o una URL canónica está mal, la cadena es donde se ve. Cada salto es un viaje de ida y vuelta completo, y los patrones habituales son todos evitables:
http://example.com→https://example.com→https://www.example.comson dos redirecciones donde bastaría con una. Redirige directamente al host y al esquema finales en un único salto.- Un
301que aterriza en otro301después de migrar un sitio significa que dos generaciones de reglas siguen activas a la vez. - Una redirección hacia una URL que redirige de vuelta es un bucle; la herramienta se detiene tras cinco saltos en lugar de seguirlo.
- Un
302donde querías un301les dice a los rastreadores que la mudanza es temporal, así que la URL antigua conserva su posicionamiento y la nueva no acumula ninguno.
La diferencia entre 301/302 y 307/308 es el método de la petición.
Históricamente los clientes convertían un POST en un GET al seguir un 301 o
un 302; 307 y 308 preservan el método. Si el envío de un formulario se
comporta de forma extraña detrás de una redirección, eso es lo primero que hay
que mirar.
Cabeceras que merece la pena leer con atención
| Cabecera | Qué buscar |
|---|---|
cache-control | no-store en un recurso estático desperdicia ancho de banda; un max-age largo en el HTML hace invisibles los despliegues |
etag / last-modified | Que falten significa que cada revalidación vuelve a transferir el cuerpo entero |
content-encoding | Que falte gzip o br en respuestas de texto es la mejora de rendimiento más barata que existe |
vary | Vary: User-Agent fragmenta cada caché de CDN en cientos de copias |
strict-transport-security | Un max-age corto, o un includeSubDomains ausente, deja la primera petición degradable |
content-security-policy | Consulta el constructor de CSP para saber qué significan las directivas |
x-content-type-options | Sin nosniff, un content-type mal puesto se puede reinterpretar como script |
access-control-allow-origin | La razón por la que falla tu fetch está casi siempre aquí, o en su ausencia |
set-cookie | Comprueba Secure, HttpOnly y SameSite en todo lo que lleve una sesión |
server y x-powered-by merecen atención por el motivo contrario: revelan
versiones de software y nada más. Quitarlos no es un control de seguridad, pero
no hay ningún argumento para conservarlos.
Qué no hace la herramienta a propósito
El manejador valida la URL contra una lista de bloqueo de rangos de direcciones
privadas, de bucle local, de enlace local y reservadas antes de conectar, y repite
esa comprobación en cada salto de redirección. Sin la comprobación por salto, un
nombre de host público podría redirigir a 127.0.0.1 o a una dirección de
metadatos de la nube y la petición la seguiría, que es exactamente cómo un
servicio de comprobación de cabeceras se convierte en una forma de sondear desde
fuera la red interna de otra persona.
Tampoco reenvía nunca el cuerpo de la respuesta. La conexión se lee para las cabeceras y se descarta. Un servicio que devuelve cuerpos arbitrarios es un proxy abierto, con independencia de que esa fuera la intención.
Las credenciales incrustadas en una URL (https://user:pass@host/) se eliminan
antes de hacer la petición, así que ni se envían al destino ni se reflejan de
vuelta en la cadena de redirecciones.
Ejemplos
- Un error de CORS que no consigues reproducir. Compara
access-control-allow-originen el endpoint real con lo que espera tu código. Una cabecera ausente y una cabecera equivocada producen el mismo mensaje en el navegador. - Un despliegue que no aparece. Mira
cache-controlyageen el HTML. Un CDN sirviendo un documento cacheado lo explica más veces que la compilación. - Auditar el despliegue de cabeceras de seguridad. Comprueba
strict-transport-security,content-security-policyyx-content-type-optionsen el host en producción y no en tu configuración, porque un CDN o un WAF pueden añadir, quitar o sobrescribir cualquiera de ellas. - Verificar una redirección canónica. Confirma que la cadena termina en exactamente un salto, en el host y el esquema que pretendes.
Notas
Las peticiones usan un User-Agent fijo que identifica a esta herramienta y
tienen un tiempo límite de cinco segundos. Un sitio que bloquea agentes
desconocidos responderá con un 403, y eso es una respuesta real sobre la
configuración de ese sitio, no un fallo de aquí.
Los nombres de las cabeceras se muestran tal como los envió el servidor. HTTP/2
exige nombres en minúscula en el cable, así que una respuesta por HTTP/2 mostrará
content-type donde una respuesta HTTP/1.1 podría mostrar Content-Type. En
cualquier caso, los nombres no distinguen mayúsculas de minúsculas.
Si necesitas enviar cabeceras personalizadas, un método concreto o un cuerpo de petición, usa el probador de API REST: se ejecuta desde tu propio navegador y por eso puede hacer cosas que un servicio compartido no debe hacer.