HTTP security headers scanner

O HTTP/1.0 de 1996 não tinha nenhum cabeçalho de segurança — a web era um conjunto de documentos estáticos compartilhados entre universidades, e a ideia de ataques na camada de aplicação mal existia como conceito. O primeiro cabeçalho de segurança amplamente adotado foi o `X-Frame-Options`, introduzido pela Microsoft no Internet Explorer 8 em 2009 como resposta direta ao clickjacking — técnica onde uma página maliciosa incorpora outra em um iframe invisível e engana o usuário para clicar em elementos da página original. O `Strict-Transport-Security` (HSTS) chegou no RFC 6797 em 2012, forçando o navegador a nunca mais acessar um domínio por HTTP mesmo que o usuário digite `http://`. O Content Security Policy, especificado pelo W3C também em 2012, foi a resposta mais abrangente ao XSS: uma whitelist declarativa de fontes confiáveis para scripts, estilos, imagens e outros recursos. Ataques como BEAST (2011) e Heartbleed (2014) aceleraram a adoção de HTTPS e, junto com ele, dos cabeçalhos de segurança que só fazem sentido num contexto encriptado.

Cada cabeçalho resolve uma classe específica de ataque. O `Strict-Transport-Security` com `includeSubDomains` e `preload` coloca o domínio na lista hardcoded dos navegadores — uma vez nessa lista, nem mesmo um certificado comprometido permite conexão HTTP. O `Content-Security-Policy` é o mais poderoso e o mais difícil de implementar: bloqueia execução de scripts inline e recursos de origens não autorizadas, eliminando a superfície de ataque de XSS — mas qualquer extensão de browser ou CDN de terceiro não listado quebra a funcionalidade. O `X-Content-Type-Options: nosniff` impede que navegadores antigos adivinhem o tipo de um arquivo ignorando o `Content-Type` — uma técnica chamada MIME sniffing que permitia transformar um upload de imagem em script executável. O `Referrer-Policy` controla quanto do URL atual é enviado como referência em requisições cross-origin. O `Permissions-Policy` (anteriormente `Feature-Policy`) restringe o acesso a APIs sensíveis do navegador — câmera, microfone, geolocalização — que uma página ou seus iframes podem usar.

Esta ferramenta analisa o bloco de cabeçalhos que você cola — obtido com `curl -I https://seusite.com` ou copiado do painel Network do DevTools — e identifica quais cabeçalhos de segurança estão ausentes e o impacto de cada ausência. Um site sem HSTS está vulnerável a ataques de downgrade; sem CSP, a XSS armazenado em CDNs; sem `X-Frame-Options`, a clickjacking. O serviço securityheaders.com de Scott Helme popularizou uma nota de A a F para sites baseada nesses cabeçalhos, criando um benchmark público que incentivou muitas equipes a implementá-los. Uma dica de implementação progressiva: o CSP aceita o modo `Content-Security-Policy-Report-Only`, que registra violações sem bloquear nada — permite descobrir o que quebraria antes de aplicar a política em modo de enforcement real. Começar com `default-src 'self'` e iterar com base nos relatórios é a abordagem mais prática para sites com dependências de terceiros.

HTTP/1.0 of 1996 had no security headers at all — the web was a collection of static documents shared among universities, and the concept of application-layer attacks barely existed. The first widely adopted security header was `X-Frame-Options`, introduced by Microsoft in Internet Explorer 8 in 2009 as a direct response to clickjacking — a technique where a malicious page embeds another in an invisible iframe and tricks the user into clicking elements of the original page. `Strict-Transport-Security` (HSTS) arrived in RFC 6797 in 2012, forcing the browser to never access a domain over HTTP even if the user types `http://`. Content Security Policy, also specified by the W3C in 2012, was the most comprehensive answer to XSS: a declarative whitelist of trusted sources for scripts, styles, images, and other resources. Attacks like BEAST (2011) and Heartbleed (2014) accelerated the adoption of HTTPS and, along with it, the security headers that only make sense in an encrypted context.

Each header addresses a specific class of attack. `Strict-Transport-Security` with `includeSubDomains` and `preload` places the domain on browsers' hardcoded list — once on that list, not even a compromised certificate allows an HTTP connection. `Content-Security-Policy` is the most powerful and the hardest to implement: it blocks inline script execution and resources from unauthorized origins, eliminating the XSS attack surface — but any browser extension or unlisted third-party CDN will break functionality. `X-Content-Type-Options: nosniff` prevents older browsers from guessing a file's type by ignoring the `Content-Type` — a technique called MIME sniffing that could turn an image upload into an executable script. `Referrer-Policy` controls how much of the current URL is sent as a referrer in cross-origin requests. `Permissions-Policy` (formerly `Feature-Policy`) restricts access to sensitive browser APIs — camera, microphone, geolocation — that a page or its iframes can use.

This tool analyzes the header block you paste — obtained with `curl -I https://yoursite.com` or copied from the Network panel in DevTools — and identifies which security headers are missing and the impact of each absence. A site without HSTS is vulnerable to downgrade attacks; without CSP, to stored XSS via CDNs; without `X-Frame-Options`, to clickjacking. Scott Helme's securityheaders.com service popularized an A-to-F grade for sites based on these headers, creating a public benchmark that motivated many teams to implement them. A practical tip for progressive implementation: CSP accepts a `Content-Security-Policy-Report-Only` mode that logs violations without blocking anything — letting you discover what would break before applying the policy in full enforcement mode. Starting with `default-src 'self'` and iterating based on the reports is the most practical approach for sites with third-party dependencies.

El HTTP/1.0 de 1996 no tenía ningún header de seguridad — la web era un conjunto de documentos estáticos compartidos entre universidades, y el concepto de ataques en la capa de aplicación apenas existía. El primer header de seguridad ampliamente adoptado fue `X-Frame-Options`, introducido por Microsoft en Internet Explorer 8 en 2009 como respuesta directa al clickjacking — una técnica en la que una página maliciosa incrusta otra en un iframe invisible y engaña al usuario para que haga clic en elementos de la página original. `Strict-Transport-Security` (HSTS) llegó con el RFC 6797 en 2012, obligando al navegador a no acceder nunca a un dominio por HTTP aunque el usuario escriba `http://`. Content Security Policy, especificada también por el W3C en 2012, fue la respuesta más completa al XSS: una lista blanca declarativa de fuentes confiables para scripts, estilos, imágenes y otros recursos. Ataques como BEAST (2011) y Heartbleed (2014) aceleraron la adopción de HTTPS y, con ella, de los headers de seguridad que solo tienen sentido en un contexto cifrado.

Cada header resuelve una clase específica de ataque. `Strict-Transport-Security` con `includeSubDomains` y `preload` coloca el dominio en la lista codificada de los navegadores — una vez en esa lista, ni siquiera un certificado comprometido permite una conexión HTTP. `Content-Security-Policy` es el más potente y el más difícil de implementar: bloquea la ejecución de scripts inline y recursos de orígenes no autorizados, eliminando la superficie de ataque de XSS — pero cualquier extensión del navegador o CDN de terceros no listada romperá la funcionalidad. `X-Content-Type-Options: nosniff` impide que navegadores antiguos adivinen el tipo de un archivo ignorando el `Content-Type` — una técnica llamada MIME sniffing que podía convertir una subida de imagen en un script ejecutable. `Referrer-Policy` controla cuánto del URL actual se envía como referencia en solicitudes cross-origin. `Permissions-Policy` (antes `Feature-Policy`) restringe el acceso a APIs sensibles del navegador — cámara, micrófono, geolocalización — que una página o sus iframes pueden usar.

Esta herramienta analiza el bloque de headers que pegues — obtenido con `curl -I https://tusitio.com` o copiado del panel Network de DevTools — e identifica qué headers de seguridad faltan y el impacto de cada ausencia. Un sitio sin HSTS es vulnerable a ataques de degradación; sin CSP, a XSS almacenado en CDNs; sin `X-Frame-Options`, al clickjacking. El servicio securityheaders.com de Scott Helme popularizó una nota de A a F para sitios basada en estos headers, creando un benchmark público que motivó a muchos equipos a implementarlos. Un consejo para una implementación progresiva: el CSP acepta el modo `Content-Security-Policy-Report-Only`, que registra las violaciones sin bloquear nada — lo que permite descubrir qué se rompería antes de aplicar la política en modo de cumplimiento real. Empezar con `default-src 'self'` e iterar a partir de los informes es el enfoque más práctico para sitios con dependencias de terceros.