Um CSP nonce e um valor unico e aleatorio gerado por carregamento de pagina que ajuda a validar scripts inline legitimos dentro de uma Content Security Policy. Ao adicionar esse nonce tanto ao cabecalho CSP quanto as tags de script permitidas, desenvolvedores podem permitir scripts inline especificos enquanto mantem protecoes fortes contra XSS. Essa abordagem e particularmente util quando a insercao dinamica de scripts e necessaria, mas um CSP rigoroso e desejado.
Um nonce de CSP (do inglês "number used once", número usado uma vez) é um token aleatório e impossível de adivinhar que o servidor gera em cada resposta e coloca em dois lugares: na origem nonce-... do cabeçalho Content-Security-Policy e em um atributo nonce correspondente em cada <script> ou <style> inline que ele deseja permitir. O navegador executa um script inline somente quando o atributo nonce dele coincide com o valor declarado no cabeçalho para aquele carregamento de página específico. Como o token é gerado novamente a cada requisição e nunca é previsível, qualquer marcação que um invasor injete depois não conseguirá carregar um nonce válido, então o navegador se recusa a executá-la. Isso permite que um site mantenha os scripts inline de que realmente precisa enquanto abandona a permissão genérica unsafe-inline da qual o XSS depende.
A maioria das defesas contra XSS desmorona no momento em que uma política precisa permitir unsafe-inline, porque essa palavra-chave diz ao navegador para confiar em todo script inline, incluindo qualquer um que um invasor consiga injetar. Uma política baseada em nonce remove essa palavra-chave: somente o código inline que o servidor deliberadamente marcou com o token atual pode ser executado. Isso reduz a superfície de ataque para XSS refletido, armazenado e baseado em DOM sem manter longas listas de permissão de hosts externos, e neutraliza manipuladores de eventos injetados e tags de script inline plantadas por meio de um template vulnerável. O nonce é o caminho prático para uma CSP estrita, a configuração que as equipes de segurança recomendam, em páginas reais que ainda dependem de algum JavaScript inline.
Gere o nonce a partir de uma fonte aleatória criptograficamente segura (pelo menos 128 bits) e emita um novo a cada resposta; reutilizar um nonce em páginas em cache anula o propósito. Nunca o coloque onde um invasor possa lê-lo e devolvê-lo. Combine-o com strict-dynamic para que scripts confiáveis possam carregar suas próprias dependências, e mantenha uma lista de permissão de hosts como alternativa para navegadores mais antigos. Como um nonce ainda confia no que quer que um script permitido faça em tempo de execução, ele não consegue impedir um arquivo third-party comprometido. A cside complementa a CSP aqui roteando scripts third-party por meio de um proxy híbrido e analisando o payload real, bloqueando em tempo real comportamentos maliciosos que um nonce válido teria deixado passar sem obstáculos.
Sim. Um nonce deve ser gerado novamente para cada resposta HTTP usando um gerador aleatório seguro. Se você armazenar em cache uma página junto com o nonce dela, ou reutilizar o mesmo valor, um invasor que observe um nonce válido poderia reproduzi-lo dentro de uma marcação injetada, o que anula a proteção. Páginas estáticas ou em cache geralmente precisam de hashes em vez disso.
Ambos permitem que scripts inline específicos sejam executados sob uma política estrita. Um nonce é um token aleatório por requisição adicionado à tag e ao cabeçalho, ideal para páginas renderizadas no servidor. Um hash é um resumo fixo do conteúdo exato do script, mais adequado para conteúdo estático ou em cache, onde você não consegue carimbar um novo token em cada resposta.
We answer client-side security questions every day. Bring yours.