Configuração CORS e CSP:
proteja o seu site contra injeção de scripts e conteúdo malicioso
Implementação correta de Content Security Policy (CSP) e Cross-Origin Resource Sharing (CORS) para bloquear XSS, data injection e ataques cross-origin. Configurados com processo report-only primeiro para zero impacto em funcionalidades legítimas.
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.
O que CORS e CSP protegem na prática
Headers de segurança HTTP são invisíveis para os utilizadores mas críticos para proteger o site e os seus dados contra ataques do lado do browser.
Cross-Site Scripting (XSS)
CSP é a proteção mais eficaz contra XSS. Mesmo que um atacante consiga injetar código malicioso no HTML do site, o browser recusa executá-lo se não vem de uma origem da lista branca.
Clickjacking
Atacantes podem embeber o vosso site num iframe transparente sobre outro site para enganar utilizadores a clicar em elementos. X-Frame-Options e CSP frame-ancestors bloqueiam este ataque completamente.
Data exfiltration
CSP pode restringir para onde o site pode enviar dados, impedindo que scripts maliciosos injetados enviem informação de utilizadores para servidores de terceiros controlados por atacantes.
CSRF via CORS
CORS permissivo permite que sites maliciosos façam pedidos à vossa API em nome dos vossos utilizadores autenticados. Configuração correta de CORS restringe pedidos às origens explicitamente autorizadas.
Fuga de informação via Referrer
URLs privadas, tokens de sessão em querystrings ou informação sensível no caminho podem ser enviados a terceiros via o header Referrer. Referrer-Policy controla exatamente que informação é partilhada.
Acesso abusivo a APIs do browser
Permissions-Policy restringe acesso a APIs como câmara, microfone, geolocalização e sensores. Impede que scripts de terceiros (analytics, ads) acedam a recursos sensíveis sem necessidade.
Quer verificar 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 funcionalidades.
Do diagnóstico à classificação A em headers de segurança
Processo cuidadoso que garante que os headers de segurança protegem o site sem quebrar uma única funcionalidade legítima.
Auditoria dos headers atuais
Análise dos headers HTTP atuais, scripts e estilos carregados, origens externas usadas, integrações de terceiros (analytics, chat, ads) e arquitetura do servidor para definir a política correta.
CSP em modo report-only
Ativamos o CSP em modo report-only: o browser regista violações mas não bloqueia. Analisamos os reports durante 3-7 dias para identificar todos os recursos legítimos que precisam de ser autorizados.
Refinamento da política
Com base nos reports, refinamos a política CSP para autorizar todos os recursos legítimos com o menor escopo possível. Configuramos CORS e os restantes headers de segurança em paralelo.
Ativação e testes
Ativamos todos os headers de bloqueio e testamos manualmente todas as funcionalidades críticas do site: formulários, pagamentos, embeds, carregamento de scripts de terceiros e áreas de login.
Validação externa
Validamos a configuração com securityheaders.com e Mozilla Observatory para confirmar a classificação A, documentamos a política implementada e entregamos relatório final.
CSP que protege sem quebrar o site — a parte difícil que a maioria evita
Adicionar headers genéricos é simples. Configurar um CSP que realmente bloqueia ataques sem quebrar plugins e integrações de terceiros 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 de WordPress core e os plugins mais comuns, o que acelera o processo de refinamento da política.
Processo que elimina falsos positivos
O modo report-only não é opcional no nosso processo — é a garantia de que a política final não quebra funcionalidades que os vossos utilizadores e integrações dependem.
Suite completa de headers
Não configuramos apenas CSP e CORS. Entregamos uma suite completa de headers que abordam todos os vetores de ataque relevantes — incluindo os menos conhecidos como Permissions-Policy.
Documentação da política
A política CSP fica documentada com a justificação de cada diretiva. Se adicionarem uma nova integração que requeira ajustes, a equipa técnica sabe exatamente o que alterar.
Atualização quando muda o stack
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 rapidamente.
Suporte imediato se algo bloquear
Se após a ativação algo deixar de funcionar, respondemos e corrigimos no próprio dia — sem demoras que afetem a experiência dos utilizadores.
Dúvidas sobre Configuração CORS e CSP
O que é o CSP e porque é importante para a segurança do site?
Content Security Policy (CSP) é um header HTTP que diz ao browser quais as origens de conteúdo que o site autoriza a carregar — scripts, estilos, imagens, frames. Com CSP bem configurado, mesmo que um atacante injete código malicioso no site, o browser recusa executá-lo porque não vem de uma origem autorizada. É a defesa mais eficaz contra Cross-Site Scripting (XSS), um dos ataques mais comuns e prejudiciais.
O que é o CORS e que problemas pode criar se 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 (Access-Control-Allow-Origin: *) permite que qualquer site na internet faça pedidos autenticados em nome dos vossos utilizadores — um vetor de ataque CSRF. CORS demasiado restritivo quebra integrações legítimas. A configuração correta exige análise cuidadosa do contexto.
O CSP pode quebrar o funcionamento do site?
Sim, um CSP mal configurado pode impedir que scripts e estilos legítimos carreguem, quebrando funcionalidades do site. Por isso o nosso processo inclui sempre um período em modo "report-only" onde as violações são registadas mas não bloqueadas. Analisamos os reports, ajustamos a política e só depois ativamos o bloqueio real. Este processo garante que nenhuma funcionalidade legítima fica quebrada.
Os sites WordPress têm desafios específicos com CSP?
Sim. WordPress usa muitos scripts inline, eval() e estilos embutidos que são precisamente o que o CSP tenta bloquear. Além disso, cada plugin pode adicionar os seus próprios scripts e estilos de origens externas. Configuração de CSP em WordPress requer conhecimento profundo de como o CMS e os plugins funcionam e de como usar nonces para permitir scripts legítimos sem abrir brechas.
Que outros headers de segurança devem ser configurados além de CSP e CORS?
Além de CSP e CORS, configuramos um conjunto completo de headers de segurança: X-Frame-Options (proteção contra clickjacking), X-Content-Type-Options (impede MIME sniffing), Referrer-Policy (controlo de informação enviada em referrers), Permissions-Policy (restringe acesso a APIs do browser como câmara e localização) e HSTS (força HTTPS). Cada header endereça um vetor de ataque específico.