Por que o modo Report-Only difere do modo Enforced na Content Security Policy

By Mirko Peters · 2026-04-23

Se você leva a segurança web a sério, entender a diferença entre os modos "report-only" e "enforced" na Content Security Policy (CSP) não é um detalhe: é o que faz toda a diferença. O modo report-only permite ver o que seria bloqueado pela sua política sem interromper nada, transformando seu site em uma espécie de campo de testes de segurança. Já o modo enforced não está para brincadeira: ele bloq

Automatically translated with AI from the original post. Read the English original

Cover: Fix Conditional Access Loopholes in Microsoft 365

Este artigo explica por que esses modos importam, o que eles representam para a experiência no navegador e do usuário e como sair do simples monitoramento até uma proteção efetiva. Ele foi pensado especificamente para profissionais de segurança e desenvolvedores com foco na Microsoft que querem configurar a CSP corretamente, abordando definições, técnicas práticas e boas práticas para uma implantação segura e uma conformidade inteligente.

Entendendo os modos da CSP e seu impacto

Antes de começar a distribuir cabeçalhos CSP, é preciso entender os dois principais modos da CSP: report-only e enforced. Esses modos vão além de simples configurações: eles determinam como os navegadores modernos protegem (ou apenas observam) os limites de segurança da sua aplicação web. A escolha que você faz afeta diretamente o nível de risco do seu site, a capacidade de auditoria e a fluidez da implantação, especialmente em grandes ambientes Microsoft ou em configurações multinuvem.

Os modos da CSP foram projetados para dar flexibilidade às equipes web. O modo report-only é o ponto de entrada mais suave, permitindo monitorar problemas sem o risco de quebrar algo para os usuários por acidente. Ele apoia a avaliação de riscos, ajuda a identificar lacunas na política e pode revelar código legado ou comportamentos inesperados de terceiros, tudo isso mantendo sua aplicação totalmente operacional.

O modo enforced é a parte principal: ele faz o navegador realmente executar suas instruções. Se um conteúdo não estiver de acordo com a sua política, ele é bloqueado, reduzindo imediatamente a superfície de ataque para coisas como cross-site scripting ou scripts maliciosos de terceiros. Mas isso também significa que erros ou políticas incompletas podem interromper a sua aplicação se você não tomar cuidado com os testes e a adoção.

A ideia por trás dos dois modos da CSP é simples: deixar desenvolvedores e equipes de segurança aperfeiçoarem suas regras em ambiente real antes de ativar o bloqueio. Pense nisso como rodinhas de treinamento para a segurança da sua aplicação, mas com uma linha de chegada em que você passa para a aplicação completa das regras. A seguir, veremos exatamente como o report-only oferece esse feedback do mundo real e o que muda quando a aplicação entra em cena.

Como o Content-Security-Policy-Report-Only funciona para o relatório de violações

O modo report-only é a forma que a CSP tem de deixar você observar da arquibancada antes de entrar em quadra. Ao usar o cabeçalho HTTP Content-Security-Policy-Report-Only, você instrui o navegador a "observar as violações, mas não bloquear nada, apenas reportar". Assim, você recebe um fluxo de relatórios de violação enviados ao endpoint especificado, com um panorama completo do que seria bloqueado caso a política fosse aplicada.

Os navegadores enviam esses relatórios de violação (geralmente como payloads JSON) sempre que um recurso quebra as regras da sua CSP. Por exemplo, se uma página tentar carregar um script de uma origem não aprovada, nenhum script será bloqueado no modo report-only, mas você ainda receberá um alerta com detalhes como a URL de origem, a diretiva violada e, às vezes, um trecho do código suspeito.

Este modo é inestimável para avaliações de risco e testes seguros. Você pode implantar novas regras em um conjunto de aplicações web, monitorar o que é acionado e ajustar a política com base em dados reais, e não apenas em suposições. Se você mantém sistemas legados ou fluxos de trabalho de negócio críticos, não corre o risco de causar indisponibilidades ou chamados de suporte ao avançar rápido demais.

O report-only também viabiliza implantações graduais. Comece com uma política mais permissiva, veja o que precisa de ajuste e avance passo a passo rumo a uma segurança mais rígida. Ele permite que as equipes descubram problemas com scripts de terceiros, conteúdo de CDN ou JavaScript ofuscado, que poderiam ficar escondidos até que a aplicação do modo enforced causasse uma falha drástica. Além disso, é um ganho para a conformidade: você tem a comprovação de que está monitorando ativamente, o que pode ajudar em auditorias quando a organização precisa demonstrar a devida diligência.

Como o modo Enforced aumenta a segurança

O modo de aplicação (enforced) é o momento em que sua política CSP deixa de ser uma sugestão e passa a ser uma regra. Quando você usa o cabeçalho Content-Security-Policy, os navegadores bloqueiam de fato qualquer conteúdo que não esteja de acordo com suas diretivas: sem avisos, apenas ação.

Esse modo fortalece muito sua aplicação web contra ataques como XSS e injeção de scripts não autorizados. Mas cuidado: se sua política não estiver pronta para produção, você pode bloquear sem querer recursos necessários e quebrar o funcionamento do site. Testar primeiro no modo somente relatório é a decisão inteligente. No fim das contas, o modo de aplicação é o que transforma uma política teórica em proteção prática, e por isso é considerado o padrão ouro para uma segurança web robusta.

Implementando relatórios com os endpoints Report-URI e Report-To

Configurar relatórios é o que dá dentes reais à sua política CSP, além de um par de olhos. O CSP permite especificar um ou mais endpoints (usando report-uri ou report-to) para onde os navegadores devem enviar os relatórios de violação. Quando ocorre uma violação, o navegador reúne detalhes como qual recurso foi bloqueado e qual política falhou, empacota essas informações em uma mensagem JSON ou HTTP POST e as envia ao seu endpoint.

A diretiva report-uri é o método legado: você define uma URL e os navegadores enviam os relatórios diretamente para ela. Já para uma flexibilidade moderna e relatórios mais completos, o report-to é a opção mais nova e robusta, especialmente conforme os navegadores ampliam o suporte à Reporting API. O report-to trabalha com um grupo nomeado que pode tratar diferentes tipos de relatório e oferece um controle de filtragem melhor.

Ao configurar esses endpoints, é importante que eles sejam protegidos: pense em HTTPS, controles de acesso e monitoramento de picos inesperados (que podem indicar um ataque ou uma política quebrada). E não esqueça da privacidade: os relatórios podem conter URLs ou até trechos do script ofensivo, o que significa que você precisa estar preparado para remover informações sensíveis antes de armazená-las ou compartilhá-las, observando regulamentações como a LGPD e o CCPA.

O grande valor aqui está na visibilidade. Com relatórios bem configurados, você recebe um fluxo em tempo real de onde sua política está registrando violações, para que possa ajustar, refinar e, por fim, migrar com segurança para a aplicação sem surpresas. Esse nível de monitoramento é essencial, seja você responsável por um único app ou por um ambiente Microsoft 365 extenso.

Entendendo a sintaxe e as diretivas do CSP para um design de política eficaz

Escrever um cabeçalho CSP sólido não é nenhum bicho de sete cabeças, mas exige atenção aos detalhes, especialmente quando você lida com aplicações complexas e integrações com a nuvem da Microsoft. Na base, uma política CSP é uma lista estruturada de diretivas, cada uma informando aos navegadores o que é permitido e o que não é. Você envia essas políticas pelos cabeçalhos HTTP, normalmente como Content-Security-Policy ou Content-Security-Policy-Report-Only, formatadas como strings de regras separadas por ponto e vírgula.

O núcleo da sua política está em diretivas-chave como default-src, script-src e img-src. A default-src é o fallback: se um tipo específico de conteúdo não tiver regra própria, o navegador consulta esta. Já script-src e img-src controlam de perto scripts e imagens, permitindo que você restrinja rigorosamente as origens confiáveis (pense nos seus domínios, CDNs confiáveis e, talvez, em um blob do Microsoft Azure).

A sintaxe importa. Cada diretiva lista os valores permitidos: URLs, esquemas como ‘https:’ ou palavras-chave como ‘self’. Se você permitir scripts inline (às vezes exigidos por código legado), pode precisar de ‘unsafe-inline’, mas tome cuidado: isso enfraquece sua proteção, a menos que você use hashes de script ou nonces para uma validação extra.

Para profissionais Microsoft, preste atenção em como os serviços em nuvem injetam dependências. Aplicações empresariais complexas costumam carregar recursos dinamicamente, usar service workers ou integrar provedores de terceiros. Sua política precisa equilibrar rigidez (por segurança) e flexibilidade suficiente para que a aplicação funcione. Acertar o básico desde o início tornará os testes muito mais tranquilos depois.

Boas práticas para migrar do modo somente relatório para o modo de aplicação

A decisão mais inteligente com o CSP é começar no modo somente relatório, coletar os dados e só então ativar a aplicação. Não trate a implantação do CSP como uma lista de verificação única. Encare-a como um projeto em fases, no qual você monitora, ajusta e endurece gradualmente as políticas para não interromper funcionalidades nem fluxos de trabalho críticos para os usuários finais e para o negócio.

Comece com uma política abrangente, mas sensata, em modo somente relatório. Colete os relatórios de violação, de preferência agregando-os em painéis ou ferramentas de análise para destacar os infratores recorrentes. Isso ajuda a separar o ruído, filtrar falsos positivos e concentrar-se nos riscos reais. Se houver muitos relatórios rotineiros ou redundantes (o que é comum), ajuste sua análise de logs ou até crie filtros em script por user agent ou tipo de recurso.

Quando o volume de violações cair e a maioria dos problemas estiver resolvida, comece a aplicar as regras de forma gradual, mantendo o monitoramento de novas falhas. Coloque primeiro em modo de aplicação as seções de alto risco e baixo tráfego e acompanhe o resultado. Se tudo correr bem, expanda para o restante do projeto. Documente as alterações e obtenha feedback dos desenvolvedores e das partes interessadas durante todo o processo, especialmente em aplicativos complexos do Microsoft 365 ou do Azure, nos quais as camadas de acesso condicional acrescentam complicações extras. Para estratégias relacionadas e planos de implantação, vale a pena conferir este guia sobre problemas de confiança no acesso condicional e este episódio sobre segurança de identidade.

Nunca subestime os testes. Use as ferramentas de desenvolvedor do navegador, testadores de status de CSP e até verificações automatizadas em CI/CD para confirmar que suas políticas funcionam como esperado. O objetivo final? Um aplicativo bloqueado, em conformidade e resiliente, protegido por uma política que foi refinada no mundo real, e não por suposições.

Exemplos práticos de CSP nos modos somente relatório e aplicado

Nada torna o CSP mais concreto do que exemplos reais. No modo somente relatório, você pode usar um cabeçalho como este: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. Essa configuração registra todas as violações, mas não afeta seus usuários, o que a torna ideal para testar em produção sem riscos.

Compare com uma política aplicada: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Agora, o navegador bloqueia ativamente qualquer script ou imagem que não esteja de acordo com as regras, protegendo seus usuários de conteúdo não aprovado imediatamente.

Na prática, as organizações começam no modo somente relatório para identificar quais fornecedores, scripts ou funcionalidades de negócio quebrariam sob um bloqueio mais rígido. Por exemplo, um portal governamental pode descobrir scripts legados ou uma CDN de análise de marketing que dispara violações repetidas. Elas ajustam a política, incluem na lista de permissões os provedores seguros e, então, aplicam a política final em etapas para minimizar as interrupções.

Migrar do modo somente relatório para o modo aplicado pode revelar armadilhas ocultas, especialmente com scripts de terceiros ou conteúdo dinâmico. As equipes costumam encontrar violações "fantasma" que aparecem apenas em determinados navegadores ou em condições específicas. Usando dados reais da fase de relatório, elas ajustam a política até que a aplicação seja não apenas segura, mas também estável para todos os envolvidos.

Resumo das principais diferenças entre os modos somente relatório e aplicado

Comportamento: O modo somente relatório apenas registra violações da política; nenhum conteúdo é bloqueado. O modo aplicado bloqueia ativamente qualquer coisa que viole sua política de CSP.
Finalidade: O modo somente relatório permite testar e ajustar políticas sem nenhum risco para os usuários. O modo aplicado serve para proteção efetiva, tornando as regras de segurança realmente valem.
Impacto nos usuários: O modo somente relatório é invisível; os usuários nunca percebem. O modo aplicado pode quebrar funcionalidades ou conteúdos se você não tiver testado previamente suas regras.
Casos de uso: O modo somente relatório é ideal para implantações graduais, análise de riscos e verificações de compatibilidade com sistemas legados. O modo aplicado é a etapa final para alcançar uma segurança robusta e em conformidade.
Conformidade e risco: O modo somente relatório ajuda no monitoramento e na documentação durante auditorias, enquanto o modo aplicado impede diretamente violações de segurança em tempo real.