Verificar cabeçalhos de segurança
Escreva um endereço. Saem os seis cabeçalhos que importam, cada um com o que o seu valor consegue mesmo — e os que lá estão sem fazer nada são apontados.
Porque é que «estar» não é uma nota
Todos os outros verificadores pontuam pela presença: o cabeçalho está lá, verde. Mas um cabeçalho pode estar e não fazer absolutamente nada — max-age=0 é a forma documentada de desligar o HSTS, uma política em modo Report-Only comunica e não bloqueia, e o frame-ancestors faz com que o navegador ignore por completo o seu X-Frame-Options. Os três leem-se como feitos. E isso é pior do que faltarem, porque um cabeçalho que se vê é um cabeçalho que se deixa de olhar.
O que isto não lhe diz
Se o seu sítio é seguro. Estes cabeçalhos limitam o que um ataque pode fazer depois de alguma coisa já ter corrido mal; contra a falha que o deixou entrar não fazem nada. Um seis perfeito aqui convive muito bem com um gestor de conteúdos nunca atualizado.
Se está aqui, isto costuma ser o passo seguinte
Uma fotografia, ou o filme inteiro
Isto é como o sítio está neste momento. A vigilância olha para ele — o certificado, o DNS, a disponibilidade — e avisa-o no dia em que algo mudar, que costuma ser o dia em que alguém pôs em campo uma configuração que não leu.
Perguntas frequentes
- Diz que o meu cabeçalho não faz nada. Mas eu vejo-o na resposta.
- Nós também o vemos — e é esse o ponto. Três destes aparecem constantemente postos e inertes: o HSTS com max-age=0 (que é a ordem para o esquecer), uma Content-Security-Policy mandada só como Report-Only (comunica, não bloqueia) e um X-Frame-Options num sítio cuja política traz também frame-ancestors, que é a que o navegador segue. O valor está no relatório; compare-o com o que julgava ter posto.
- São precisos os seis?
- Cinco são uma linha de configuração cada um e não há razão para não os pôr. A Content-Security-Policy é a que custa trabalho a sério, porque uma estrita parte-lhe os scripts em linha até os arranjar — e é também a única que limita o dano de um XSS em vez de contar com evitá-lo. Essa põe-se primeiro em Report-Only, leem-se os relatos, e depois liga-se.
- Porque é que unsafe-inline é um problema se o resto está fechado?
- Porque é exatamente aquilo que uma CSP existe para impedir. Com unsafe-inline em script-src, uma etiqueta script injetada corre — e isso é o ataque inteiro. Tudo o resto que a política restrinja vale menos do que esse buraco. A saída são os nonce ou os hash, e o strict-dynamic deixa-o conservar o unsafe-inline como rede para navegadores antigos sem que conte contra si.