Capacidades

Header Advisor

Descubra, a partir dos navegadores dos seus próprios usuários, a Content Security Policy de que uma aplicação realmente precisa, implante-a com confiança e mantenha-a atualizada conforme a aplicação muda.

O Header Advisor da WASViking^® escreve a Content Security Policy (CSP) de que uma aplicação precisa a partir de evidências, não de suposições. Você adiciona um header report-only na sua borda ou na origem. Os navegadores dos seus próprios usuários passam então a reportar cada script, estilo, fonte, imagem, frame, chamada de API e bloco inline que a aplicação carrega, página por página. A partir dessas evidências, a plataforma propõe a política, atribui uma nota a ela, detecta quando você a implanta, avisa quando a aplicação muda e a política precisa acompanhar, e separa a mudança legítima do conteúdo injetado.

O problema que ele resolve

Uma CSP ausente ou fraca é um dos achados mais comuns em qualquer aplicação web, e um dos mais difíceis de fechar. A política precisa listar todas as origens que a aplicação carrega, incluindo as que foram adicionadas por gerenciadores de tags, widgets de chat, provedores de pagamento e uma década de decisões de front-end que ninguém documentou. Escrita à mão, a primeira versão quebra a aplicação ou acaba tão permissiva que não protege nada. Escrita uma única vez, ela fica defasada na próxima vez que a equipe de marketing adiciona um script.

O Header Advisor transforma isso em um processo medido. A aplicação continua rodando enquanto a política é aprendida. A proposta é construída a partir do que usuários reais carregaram, com as decisões que precisam de uma pessoa destacadas de forma explícita. Depois da implantação, o mesmo fluxo de evidências mantém a política fiel à realidade.

Como funciona

Adicione o header de descoberta. O portal fornece os nomes e os valores exatos do header para a sua plataforma. O header é Content-Security-Policy-Report-Only, que nunca bloqueia uma requisição; ele apenas pede ao navegador que reporte ao coletor da WASViking o que a página carrega.
Aprenda com o tráfego real. Cada página que os seus usuários abrem acrescenta evidências. Cada fonte é agregada por diretiva e origem, com os dias em que foi vista, o número de navegadores distintos, as páginas em que apareceu e uma amostra do que foi bloqueado. A janela de aprendizado é de sete dias por padrão; a política também fica pronta antes quando nenhuma fonte nova aparece por três dias.
Revise e aprove. A proposta lista cada fonte com um veredito e o motivo por trás dele. Scripts inline, event handlers inline, estilos inline, eval e blob workers recebem, cada um, um card de decisão com as opções e o impacto delas na nota. A política recebe a nota do mesmo avaliador que o motor de scan usa para os headers de segurança, então o advisor e os seus achados nunca divergem.
Implante em dois movimentos. Primeiro, copie a política aprovada como report-only. A WASViking a reconhece pelos relatórios dos próprios navegadores e marca o advisor como candidate (candidata); depois de três dias limpos, você renomeia o header para Content-Security-Policy e o advisor passa a enforced (aplicada). A implantação é detectada, não declarada.
Mantenha a política atualizada. A análise roda a cada dez minutos. Uma nova fonte legítima que atinge o quórum depois da implantação vira uma atualização aguardando revisão, com um diff pronto para a próxima versão. Já o conteúdo que não pertence à aplicação vira um sinal de ameaça.

O que você vê

Tela	O que ela mostra
Header Advisor (lista)	Um card por hostname com o status, o destaque (fontes a revisar, sinais de ameaça abertos), os relatórios dos últimos sete dias, a versão aprovada e a nota dela.
Step 1: Add the discovery header	Nomes e valores do header com um passo a passo para Cloudflare, Google Cloud Load Balancer, nginx, Apache, IIS, Node.js (Express), Next.js, Django, Spring Boot e ASP.NET Core, além de Check header para confirmar que o hostname já o envia.
Step 2: Learning from real traffic	Contador de dias, fontes, páginas vistas, navegadores distintos, fontes novas nas últimas 24 horas, estabilidade e a tabela de fontes com veredito, classificação, evidência e reputação.
Step 3: Review and apply the policy	A política proposta ou aprovada com uma diretiva por linha, a nota dela, os cards de decisão, o rollout em dois movimentos e os snippets por plataforma.
Deployment and monitoring	Relatórios, ruído filtrado, drift pendente e sinais de ameaça abertos; a versão implantada e a disposição como vistas pelos navegadores; a lista de mudanças a revisar com o diff para a próxima versão.
Threat signals	Scripts inline injetados, domínios que imitam o seu, fontes puxadas por endereços que o Edge Threat Radar sinaliza, cada um com severidade, página, amostra e uma ação de reconhecimento.
Policy history	Todas as versões com status, nota, contagem de fontes e datas.

Vereditos

Veredito	Significado
Recommended	Atingiu o quórum (dias e navegadores) e passou na verificação de reputação. Incluída na política.
Needs your decision	Código inline, `eval`, blob workers ou um host sob um domínio de topo frequentemente abusado. É necessário um card de decisão ou uma inclusão explícita.
Watching	Vista, mas abaixo do quórum. Ainda não incluída.
Excluded	Excluída por você. Mantida nas evidências para que a exclusão fique visível.
Threat	Uma imitação do seu próprio domínio, um endereço literal, um rótulo punycode ou uma fonte puxada principalmente por endereços que o Edge Threat Radar sinaliza como atacantes. Nunca é proposta.

O quórum escala com a audiência: uma fonte precisa ser vista em pelo menos três dias por uma parcela dos navegadores observados, com um piso de três e um teto que você define. Uma aplicação interna ou de staging com menos de dez navegadores roda em um modo de baixo tráfego com quórum de um, para que ainda assim consiga obter uma política.

Fontes que o catálogo completa

Cerca de cinquenta serviços documentados são conhecidos pelo advisor: gerenciadores de tags, analytics, fontes tipográficas, plataformas de CAPTCHA e de desafio, provedores de pagamento, widgets de chat e de suporte, rastreamento de erros, provedores de identidade e CDNs. Quando os navegadores reportam um deles, as diretivas que a documentação dele exige são completadas automaticamente, para que a primeira implantação não quebre um checkout porque um provedor carrega um frame que a janela de aprendizado nunca viu.

Nota de hardening

Toda proposta e toda versão aprovada carrega uma nota: Strong (forte), Partial (parcial), Weak (fraca) ou Missing (ausente), com o motivo. unsafe-inline e unsafe-eval contam como Weak apenas onde enfraquecem a proteção de scripts; unsafe-inline só para estilos é Partial. Os cards de decisão mostram o impacto de cada opção antes de você aprovar, e os hashes dos seus scripts e estilos inline são calculados a partir das suas páginas quando o hostname é alcançável, então a opção Strong fica a um clique quando a aplicação permite.

Seguro por design

Report-only nunca bloqueia. O header de descoberta e o header candidato apenas pedem ao navegador que reporte. Nada do que a aplicação carrega é afetado.
Os relatórios trafegam fora de banda. O navegador os envia depois que a página carregou e os descarta em silêncio se o coletor estiver inalcançável. Uma indisponibilidade no lado da WASViking custa um intervalo de aprendizado, nunca uma requisição no seu lado.
A implantação é detectada a partir de evidências. A plataforma nunca escreve na sua borda nem na sua origem. Você copia o header; os navegadores confirmam.
O movimento de aplicação é seu. Passar a bloquear é um passo separado e deliberado, dado depois que a candidata rodou limpa.

O que é coletado

Os relatórios trazem o caminho da página (sem query string), a diretiva, a fonte bloqueada e, para código inline, uma amostra curta de no máximo 160 caracteres. O coletor os agrega por fonte; os relatórios brutos não são armazenados. Os navegadores são contados por meio de um fingerprint semanal com chave, nunca pelo endereço bruto. Relatórios de um hostname diferente daquele que está sendo analisado são descartados, e o coletor aplica limite de taxa por hostname e por cliente. A retenção dos agregados segue o seu plano.

Alertas

Um único tipo de evento, Header Advisor, disponível em todos os canais de notificação (Slack, Microsoft Teams, e-mail, API). Ele dispara quando uma política está pronta para revisão, quando uma atualização está aguardando depois da implantação e quando um novo sinal de ameaça aparece. Ative por canal em Notification Channels.

O que isto não é

Não é um snippet de JavaScript nas suas páginas. O Header Advisor não adiciona nada à aplicação e não tem como deixá-la mais lenta.

Não é um implantador automático. Aplicar a política na sua borda ou na sua origem continua nas suas mãos, com o valor exato para colar.

Não é um web application firewall. Ele define o que o navegador tem permissão para carregar; não inspeciona tráfego.

Disponibilidade por plano

Elemento do plano	Observações
Hostnames monitorados	Pro: 1. Business: 3. Enterprise: negociado. Um advisor por hostname; subdomínios dos seus alvos são aceitos.
Retenção de evidências	Pro: 30 dias. Business: 90 dias. Enterprise: negociado.
Papéis	Admin e Manager iniciam, aprovam, pausam e removem advisors. Analyst e Read only os visualizam.

Onde fica no portal

Edge Threat Radar → Header Advisor: a lista, os três passos de cada advisor, o monitoramento, os sinais de ameaça e o histórico.
Vulnerabilities → Security Headers: o achado de Content Security Policy oferece iniciar o advisor para aquele hostname.
Notification Channels: o evento Header Advisor em cada canal.

Configuração

Siga Configure o Header Advisor: adicione o hostname, implante o header de descoberta na sua plataforma, acompanhe a janela de aprendizado, aprove a política e faça o rollout em dois movimentos.