Configuração CORS CSP Website Seguro:
proteja o seu site contra injeção de scripts maliciosos
A maioria dos sites tem classificação D ou F em securityheaders.com — o que significa que browsers de utilizadores não têm instruções para bloquear conteúdo malicioso injetado. Configuramos Content Security Policy (CSP) e CORS headers para o vosso contexto específico, com processo report-only que garante zero quebra de funcionalidades legítimas antes de ativar o bloqueio.
CORS headers configurar e Content Security Policy: o que são e o que protegem
Uma explicação clara para quem não é especialista em segurança web.
Os headers de segurança HTTP são instruções que o vosso servidor envia ao browser de cada visitante. Dizem ao browser o que pode e não pode fazer enquanto o utilizador está no vosso site. Sem estas instruções, o browser fica em modo permissivo — o que abre espaço para que código malicioso injetado seja executado sem restrições.
O CSP — Content Security Policy — é o mais importante: diz ao browser de onde podem vir scripts, estilos, imagens e frames. Se alguém injetar código malicioso no site, o browser recusa executá-lo porque não vem de uma origem autorizada. O CORS controla que outros sites podem fazer pedidos à vossa API ou recursos — evitando que sites maliciosos usem os vossos serviços em nome dos vossos utilizadores.
O desafio é que uma configuração errada pode quebrar o site — scripts legítimos bloqueados, integrações que param de funcionar. Por isso o nosso processo começa sempre em modo de observação: vemos o que seria bloqueado, ajustamos para incluir o que é legítimo, e só depois ativamos. O resultado é um website seguro com classificação A em ferramentas de auditoria independentes, sem nenhuma funcionalidade afetada.
Tudo o que recebe na configuração CORS e CSP
Não apenas CSP e CORS — uma suite completa de headers de segurança HTTP configurados para o vosso contexto específico.
Quem precisa de configuração CORS e CSP — e o que muda
Cenários concretos de sites onde esta configuração fez a diferença.
E-commerce com dados de pagamento
Loja online com WooCommerce e gateway de pagamento integrado que precisava de demonstrar medidas de segurança para conformidade PCI DSS nível básico. A configuração de CSP e suite de headers foi parte do conjunto de medidas técnicas documentadas para o processo de conformidade.
Aplicação web com API exposta
Empresa com aplicação SaaS cujo CORS estava configurado com Access-Control-Allow-Origin: * por omissão de um programador. A configuração restritiva por endpoint eliminou o risco de pedidos cross-origin não autorizados à API sem afetar os clientes legítimos da aplicação.
Site institucional com conteúdo injetado
PME de serviços financeiros com site WordPress comprometido que tinha código de redirecionamento injetado num plugin. Após limpeza do malware, a implementação de CSP garantiu que mesmo que ocorresse nova injeção, o código não seria executado pelo browser dos visitantes.
Auditoria de segurança externa
Empresa com auditoria de segurança externa que identificou ausência de headers HTTP de segurança como finding de risco médio. Implementámos a suite completa para fechar o finding com evidência verificável em ferramentas independentes, com classificação A documentada para submissão aos auditores.
Quer ver que nota tem o seu site nos headers de segurança?
A maioria dos sites tem classificação D ou F em securityheaders.com. Chegamos à classificação A sem quebrar uma única funcionalidade.
Do diagnóstico à classificação A — processo em 5 etapas sem impacto no site
Abordagem cuidadosa que garante que os headers protegem o site sem quebrar uma única funcionalidade legítima.
Auditoria dos headers e recursos atuais
Análise dos headers HTTP existentes, scripts e estilos carregados em todas as páginas, origens externas usadas (analytics, chat, ads, fonts), integrações de terceiros e arquitetura do servidor. Esta análise define a política inicial a testar.
CSP em modo report-only
Ativamos o CSP em modo report-only: o browser regista violações mas não bloqueia nada. Recolhemos reports durante 3 a 7 dias, cobrindo todos os fluxos do site — incluindo utilizadores autenticados, checkout, formulários e embeds.
Refinamento e configuração de CORS
Com base nos reports, refinamos a política CSP para incluir todos os recursos legítimos com o menor escopo possível. Configuramos CORS para cada endpoint e implementamos os restantes headers em paralelo.
Ativação e testes manuais
Ativamos todos os headers em modo de bloqueio e testamos manualmente todas as funcionalidades críticas: formulários, pagamentos, áreas de login, embeds, carregamento de scripts de terceiros e fluxos de utilizador autenticado.
Validação externa e entrega
Validamos com securityheaders.com e Mozilla Observatory para classificação A. Documentamos a política completa com justificação de cada diretiva e entregamos relatório final com evidência da configuração implementada.
Ferramentas e stacks que usamos na configuração
Implementação adaptada à arquitetura específica do vosso site — Nginx, Apache, Cloudflare ou PHP.
Implementação no servidor
Configuração de headers via Nginx (add_header), Apache (.htaccess ou vhost), Cloudflare Transform Rules ou PHP (header()) conforme o stack do vosso site. Para WordPress, usamos plugin dedicado para nonces CSP compatível com o core e plugins comuns.
Ferramentas de auditoria e validação
Securityheaders.com e Mozilla Observatory para avaliação externa, Report-URI ou Cloudflare para recolha de violações CSP em report-only, e testssl.sh para verificação de configuração TLS/SSL complementar.
Monitorização de violações CSP
Configuração de endpoint de report para recolha contínua de violações CSP em produção, com análise periódica para detetar novas origens não autorizadas — útil para identificar injeções de código malicioso em tempo real.
CSP que protege sem quebrar o site — a parte difícil que a maioria evita
Adicionar headers genéricos é trivial. Configurar um CSP que bloqueia ataques sem quebrar plugins e integrações de terceiros em WordPress requer experiência com casos reais.
Experiência com WordPress e plugins
WordPress é o caso mais complexo para CSP. Temos experiência com os padrões de scripts do core e os plugins mais comuns, o que acelera significativamente o processo de refinamento da política sem tentativa e erro.
Processo report-only obrigatório
O período report-only não é opcional no nosso processo — é a garantia de que a política final não quebra funcionalidades que os utilizadores e integrações dependem. Sem este passo, a probabilidade de quebrar algo é alta.
Suite completa de headers
Não configuramos apenas CSP e CORS. Entregamos uma suite completa que aborda todos os vetores relevantes — incluindo os menos conhecidos como Permissions-Policy que restringe acesso a APIs do browser por scripts de terceiros.
Política documentada e mantível
A política CSP fica documentada com a justificação de cada diretiva. Quando adicionam um novo plugin ou integração, a equipa técnica sabe exatamente o que ajustar sem precisar de recomeçar do zero.
Atualizações quando o stack muda
Quando adicionam um novo plugin, ferramenta de analytics ou chat ao site, a política CSP pode precisar de ajustes. Estamos disponíveis para atualizar a configuração rapidamente sem repetir todo o processo.
Resposta rápida se algo bloquear
Se após a ativação algo deixar de funcionar, respondemos e corrigimos no próprio dia — sem tickets com dias de espera que afetam a experiência dos utilizadores do site.
Dúvidas sobre Configuração CORS e CSP
O que é o Content Security Policy e porque é a proteção mais eficaz contra XSS?
Content Security Policy (CSP) é um header HTTP que instrui o browser sobre que origens de conteúdo o site autoriza a carregar — scripts, estilos, imagens, frames e fontes. Com CSP bem configurado, mesmo que um atacante consiga injetar código malicioso no HTML do site via uma vulnerabilidade, o browser recusa-se a executá-lo porque não vem de uma origem da lista autorizada. É a defesa em profundidade mais eficaz contra Cross-Site Scripting (XSS), que está consistentemente no top 3 dos ataques web mais comuns e com maior impacto.
O que é o CORS e que problemas cria se estiver mal configurado?
Cross-Origin Resource Sharing (CORS) é o mecanismo que controla que domínios externos podem fazer pedidos à vossa API ou recursos. CORS demasiado permissivo — com Access-Control-Allow-Origin: * — permite que qualquer site na internet faça pedidos autenticados em nome dos vossos utilizadores, abrindo vetores de ataque CSRF graves. CORS demasiado restritivo quebra integrações legítimas como aplicações móveis ou frontends em domínios diferentes. A configuração correta exige análise cuidadosa do contexto de cada endpoint.
Configurar CSP pode quebrar o funcionamento do site?
Sim, uma política CSP incorreta pode impedir que scripts e estilos legítimos carreguem, quebrando funcionalidades do site — desde formulários até pagamentos online. É por isso que o nosso processo inclui sempre um período em modo "report-only" onde as violações são registadas sem bloquear nada. Analisamos os reports durante 3 a 7 dias, ajustamos a política para incluir todos os recursos legítimos, e só depois ativamos o bloqueio real. Este processo garante que nenhuma funcionalidade legítima fica afetada.
O WordPress tem desafios específicos na configuração de CSP?
Sim, WordPress é o caso mais complexo para CSP. O core usa scripts inline, e muitos plugins adicionam eval() e estilos embutidos — precisamente o tipo de conteúdo que o CSP visa bloquear. Além disso, cada plugin pode carregar scripts de origens externas diferentes. A configuração de CSP em WordPress requer experiência com como o CMS e os plugins mais comuns funcionam internamente, e conhecimento de como usar nonces para permitir scripts legítimos sem usar unsafe-inline que anula a proteção.
Que outros headers de segurança HTTP devem ser configurados além de CSP e CORS?
Uma suite completa de headers de segurança inclui: X-Frame-Options ou CSP frame-ancestors para proteção contra clickjacking, X-Content-Type-Options para impedir MIME sniffing pelo browser, Referrer-Policy para controlar que informação é enviada em pedidos a terceiros, Permissions-Policy para restringir acesso a APIs do browser como câmara e geolocalização, e HSTS (HTTP Strict Transport Security) para forçar HTTPS em todos os pedidos futuros. Cada header endereça um vetor de ataque específico — são complementares, não redundantes.
Como verificam se a configuração final está correta?
Validamos a configuração com ferramentas externas independentes: securityheaders.com para análise da suite completa de headers HTTP, Mozilla Observatory para avaliação mais abrangente que inclui cookies e configurações de segurança adicionais, e testssl.sh para verificação de SSL/TLS. O objetivo é sempre atingir classificação A ou A+ nestas ferramentas — o que garante que os standards da indústria estão cobertos. O resultado final é documentado no relatório de entrega.
Depois de configurado, o CSP precisa de ser mantido?
Sim. O CSP pode precisar de ajustes sempre que adicionam uma nova integração ao site — um chat, uma ferramenta de analytics, um pixel de marketing ou um novo plugin WordPress. Cada nova origem de scripts ou estilos pode gerar violações de CSP se não for adicionada à política. Documentamos a política com a justificação de cada diretiva para que a vossa equipa técnica saiba o que ajustar, e estamos disponíveis para atualizar a configuração quando o stack muda.
Veja também: Configuração WAF para Websites · Segurança Informática