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 realmente importa. O modo report-only permite ver o que seria bloqueado pela sua política sem interromper nada, transformando o seu site em um tipo de campo de testes de segurança. Já o modo enforced não está para brincadeira: ele bloqueia

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 são importantes, o que eles representam para a experiência do navegador e do usuário e como sair do simples monitoramento para uma proteção efetiva. Ele foi pensado especialmente para profissionais de segurança e desenvolvedores que trabalham com tecnologias Microsoft e 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, você precisa entender os dois modos principais da CSP: report-only e enforced. Esses modos são mais do que simples configurações: eles definem 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 tranquilidade da implantação, principalmente em grandes ambientes Microsoft ou em configurações multinuvem.

Os modos da CSP foram criados para dar flexibilidade às equipes web. O modo report-only é o ponto de entrada mais suave: ele permite monitorar problemas sem o receio 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 a aplicação totalmente operacional.

O modo enforced é o evento principal: ele faz o navegador realmente executar as 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 contra coisas como cross-site scripting ou scripts maliciosos de terceiros. Porém, isso também significa que erros ou políticas incompletas podem interromper a aplicação se você não tomar cuidado com os testes e a adoção.

A ideia por trás da existência dos dois modos é 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 segurança para a sua aplicação, mas com uma linha de chegada em que você passa para a aplicação plena da política. A seguir, veremos exatamente como o modo report-only fornece 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 oferece para 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 violações, mas não bloquear nada, apenas reportar". Assim, você recebe um fluxo de relatórios de violação enviados para o 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 tenta carregar um script de uma origem não aprovada, nenhum script é bloqueado no modo report-only, mas você ainda recebe um alerta com detalhes como a URL de origem, qual diretiva foi violada e, em alguns casos, um trecho do código suspeito.

Esse 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 críticos para o negócio, não corre o risco de causar indisponibilidade do site ou abrir chamados de suporte por avançar rápido demais.

O modo report-only também oferece suporte a implantações graduais. Comece com tudo liberado, veja o que precisa de ajustes 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, de outra forma, poderiam ficar escondidos até que a aplicação causasse uma falha grave. Além disso, é um ganho de conformidade: você tem a prova 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, tornando-se o padrão de 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 tudo em uma mensagem JSON ou HTTP POST e a 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. No entanto, para mais flexibilidade e relatórios mais completos, report-to é a opção mais nova e robusta, principalmente à medida que 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 melhor controle de filtragem.

Ao configurar esses endpoints, é importante que sejam seguros: 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 armazenar ou compartilhar esses dados, respeitando regulamentações como a LGPD e a CCPA.

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

Navegando pela sintaxe e pelas 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 ao lidar com aplicativos complexos e integrações com serviços de 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 por meio de 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 centro 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 uma regra própria, o navegador consulta esta. A script-src e a img-src são voltadas a scripts e imagens, permitindo controlar com precisão as fontes confiáveis (por exemplo, seus domínios, CDNs confiáveis e, talvez, 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 necessário para código legado), pode precisar de ‘unsafe-inline’, mas tenha cuidado: isso enfraquece sua proteção, a menos que você use hashes ou nonces de script para validação extra.

Para profissionais Microsoft, preste atenção em como os serviços de nuvem injetam dependências. Aplicativos corporativos complexos frequentemente carregam recursos dinamicamente, usam service workers ou integram provedores de terceiros. Sua política precisa equilibrar rigidez (por segurança) e flexibilidade suficiente para que o aplicativo funcione. Acertar o básico desde o início tornará os testes muito mais tranquilos no futuro.

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

A decisão mais inteligente com 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. Em vez disso, encare-a como um projeto em fases, em que você monitora, ajusta e endurece gradualmente as políticas para evitar quebrar funcionalidades para os usuários finais ou fluxos de trabalho críticos para o negócio.

Comece com uma política abrangente, mas sensata, em modo somente relatório. Colete os relatórios de violação; o ideal é agregá-los usando painéis ou ferramentas de análise para destacar os infratores recorrentes. Isso ajuda você a separar o ruído, filtrar falsos positivos e focar 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 scripts 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, continuando a monitorar a possibilidade de novas falhas. Coloque primeiro em modo de aplicação as seções de alto risco e baixo tráfego e monitore. Se tudo correr bem, expanda para o restante do projeto. Documente as alterações e obtenha feedback de desenvolvedores e partes interessadas durante todo o processo, especialmente em aplicações complexas do Microsoft 365 ou do Azure, nas quais as camadas de acesso condicional acrescentam complicações extras. Para estratégias e planos de implantação relacionados, vale conferir este guia sobre problemas de confiança em 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 pipelines de CI/CD para confirmar que suas políticas funcionam como esperado. O objetivo final? Uma aplicação bloqueada, em conformidade e resiliente, protegida por uma política que foi refinada no mundo real, e não por expectativas irreais.

Exemplos reais 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 contra conteúdo não aprovado imediatamente.

Na prática, as organizações começam com o modo somente relatório para identificar quais fornecedores, scripts ou recursos de negócio falhariam sob um bloqueio mais rigoroso. Por exemplo, um portal governamental pode descobrir scripts legados ou uma CDN de análise de marketing que gera 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 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 "fantasmas" que aparecem apenas em determinados navegadores ou sob condições específicas. Usando dados reais da fase somente relatório, elas ajustam a política até que a aplicação seja não só 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 tudo o que viola 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 interromper recursos ou conteúdos se você não tiver testado suas regras antes.
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.