Um relato técnico de como o site luisferreira.pt subiu de B (84) para A (97) na avaliação SecurityScorecard em cerca de 75 minutos, sem instalar um único plugin novo e sem tocar no WordPress. Mais importante do que o resultado: as três decisões deliberadas de não corrigir certos issues, e porquê.

Contexto

O site luisferreira.pt foi lançado em Janeiro de 2026 sobre uma stack convencional: WordPress 6.9 com tema Astra, page builder Spectra, alojamento Hostinger Business e Cloudflare PRO no edge. Em 4 de Maio de 2026 foi concretizada uma reestruturação visual e de conteúdo, mantendo a stack inicial. Seis dias após esta reestruturação, a avaliação SecurityScorecard situava o site em 84 (B), com 7 issues abertos.

A distribuição dos issues era reveladora: 1 de risco elevado e 6 de risco baixo, todos concentrados no factor Application Security (com pontuação de 73, grau C). Os restantes seis fatores avaliados — Cubit Score, DNS Health, Endpoint Security, Hacker Chatter, IP Reputation e Network Security — estavam todos a 100 (A).

O objetivo declarado para a intervenção foi subir para o grau A, próximo de 100, mas com uma condição: cada ação tinha de passar num filtro de retorno sobre o investimento. Não foi uma campanha emocional do tipo “quero ser A”; foi uma campanha racional do tipo “vale a pena ser A — e a que custo?”.

Diagnóstico antes de atuar

O primeiro passo não foi corrigir nada. Foi cruzar fontes.

A SecurityScorecard apontava para 7 issues concretos. Em paralelo, o securityheaders.com da Snyk classificava o mesmo site com A+. Esta aparente contradição era informativa, não problemática: as duas ferramentas medem coisas diferentes.

• O site securityheaders.com verifica presença de headers HTTP de segurança.
• A SecurityScorecard verifica qualidade desses headers e procura padrões mais granulares.

Onde o securityheaders.com dava A+ pela presença de HSTS, a SecurityScorecard apontava deficiências reais: max-age de apenas 180 dias (recomendado: 1 ano ou mais), ausência de includeSubDomains e ausência de preload. A CSP existente era minimalista (upgrade-insecure-requests; apenas), faltando a diretiva moderna frame-ancestors para proteção contra clickjacking. O header X-Content-Type-Options: nosniff aparecia em alguns endpoints mas não em outros.

Para o issue de maior impacto — “Unsafe Implementation of Subresource Integrity” (SRI), valendo −9,3 pontos — foi feito inventário completo dos scripts cross-origin carregados pelo site, através de curl e análise do HTML renderizado. O resultado foi inesperado: o único script cross-origin era o do Cloudflare Turnstile (CAPTCHA). Todos os restantes scripts eram same-origin, servidos a partir de luisferreira.pt.

Uma ferramenta única raramente conta a história toda. Quando A+ numa fonte coexiste com C noutra, a resposta não é escolher uma — é perceber o que cada uma mede.

Esta fase de diagnóstico levou cerca de 15 minutos. Sem ela, o resto da intervenção teria seguido caminhos errados.

Execução: edge-first hardening

A remediação foi feita inteiramente no edge da Cloudflare. Zero alterações em WordPress, zero plugins instalados, zero código adicionado.

A estratégia edge-first baseia-se em quatro vantagens práticas:

• Reversibilidade. Cada alteração desfaz-se com um toggle no painel da Cloudflare.
• Independência. Sobrevive a atualizações de tema, plugins e mesmo a migrações de hosting.
• Performance. Executa no edge, antes de chegar ao ciclo PHP da origem.
• Auditabilidade. Todas as regras ficam centralizadas num único painel.

Foram aplicadas quatro alterações:

Cada alteração foi validada imediatamente com curl -sI para confirmar o resultado real na resposta HTTP. A regra é simples: confiar em respostas reais, não em interfaces de configuração.

Aviso operacional importante: a ativação do preload do HSTS é uma decisão difícil de reverter. Implica compromisso de servir HTTPS em todos os subdomínios atuais e futuros durante o período do max-age (1 ano). Antes de ativar, foi validado que não existem subdomínios em HTTP-only.

As três decisões de não fazer

A parte mais valiosa desta intervenção não está no que foi feito. Está no que foi deliberadamente deixado por fazer, e na justificação técnica de cada decisão.

Decisão 1 — Não implementar Worker SRI

A SecurityScorecard sinalizava “Unsafe Implementation of Subresource Integrity” com impacto recuperável de 9,3 pontos. À primeira vista, era o ganho mais óbvio da campanha.

O diagnóstico revelou outra realidade. O único script cross-origin era o challenges.cloudflare.com/turnstile/v0/api.js — o loader do CAPTCHA da Cloudflare. Por design, este loader não suporta SRI: é um script dinâmico que se atualiza silenciosamente sempre que a Cloudflare atualiza o motor anti-bot. Aplicar SRI implicaria que o CAPTCHA partisse em cada atualização da Cloudflare — degradação silenciosa do formulário de contacto.

Todos os outros scripts eram same-origin, alguns deles bundles gerados dinamicamente pelo LiteSpeed Cache, cujos hashes mudam a cada atualização de plugin. Implementar SRI nesse contexto exigiria um Cloudflare Worker que: fizesse fetch ao recurso, calculasse SHA-384 em runtime, mantivesse cache de hashes sincronizada e lidasse com cenários de cache miss. Complexidade operacional permanente para resolver um problema de segurança que, no fundo, não existia.

A decisão foi submeter feedback à SecurityScorecard com justificação técnica documentada. Custo: cinco minutos. Risco de regressão futura: zero.

Decisão 2 — Não refinar a CSP

A Content Security Policy aplicada é minimalista: upgrade-insecure-requests; frame-ancestors 'self';. Responde aos dois vetores mais relevantes (mixed content e clickjacking) e nada mais.

A SecurityScorecard sinalizou esta CSP como “Contains Broad Directives”, valendo cerca de 0,2 pontos de recuperação. Refinar com default-src, script-src, style-src, connect-src e diretivas correlatas exigiria inventário completo de todos os assets legitimamente carregados pelo site, incluindo plugins, integrações de terceiros e scripts injetados dinamicamente.

O custo não está no inventário inicial. Está em mantê-lo. Cada atualização de plugin, cada nova integração e cada teste A/B pode introduzir um asset não previsto, quebrando o site silenciosamente — porque a CSP, quando viola, simplesmente bloqueia sem aviso visível no frontend. O diagnóstico de regressão exige inspeção da consola do browser, não é detetado por uptime monitors habituais.

Trocar 0,2 pontos por uma fonte permanente de bugs silenciosos não é negócio.

Decisão 3 — Não substituir o CAPTCHA

Surgiu como hipótese teórica: substituir o Cloudflare Turnstile por outro CAPTCHA com SRI suportado documentalmente.

O Turnstile funciona, é estável, integra-se nativamente com o resto da infraestrutura Cloudflare e é gratuito. A substituição introduziria risco de regressão no formulário de contacto (única via de captação de leads do site), esforço de integração e custo eventual, tudo para resolver um problema cosmético no score SecurityScorecard. É deitar fora a casa para ajustar a moldura.

Em segurança, saber o que não fazer é frequentemente mais difícil — e mais valioso — do que saber o que fazer. Toda a remediação tem custo: tempo, complexidade operacional e risco de regressão. Avaliar esse custo contra o benefício real é discernimento executivo.

Resultado

Princípios transferíveis

Cinco princípios que estiveram em jogo nesta intervenção e que se transferem para contextos corporativos mais complexos:

1. Diagnosticar antes de remediar. Cruzar fontes. Uma ferramenta única conta uma história parcial. O custo de 15 minutos de diagnóstico evita horas de remediação errada.
2. Edge-first quando possível. Resolver no edge (Cloudflare, WAF, reverse proxy) é frequentemente mais barato, mais reversível e mais independente do que tocar na aplicação. Em ambientes SAP corporativos, o princípio equivalente é resolver em SAP Cloud Connector, gateway ou camadas intermédias sempre que possível, em vez de modificar o sistema principal.
3. ROI por ação, não por relatório. Cada finding tem um custo de remediação e um benefício esperado. Avaliar ambos antes de atuar é elementar — e raramente feito de forma sistemática.
4. Documentar as decisões de NÃO fazer. As decisões de não atuar são as primeiras a ser esquecidas — e as primeiras a ser questionadas em auditoria meses depois. Documentar a justificação no momento da decisão evita re-litigar a mesma análise vezes sem conta.
5. Aceitar imperfeição estratégica. 97 sobre 100 com complexidade zero é frequentemente preferível a 100 sobre 100 com complexidade operacional permanente. A diferença não está na pontuação — está no custo acumulado de a manter.

Notas finais

A classificação A da SecurityScorecard não é um fim em si — é um indicador entre outros, com a sua metodologia, os seus biases e os seus pontos cegos. O valor real desta campanha não está nos 13 pontos ganhos: está na metodologia e disciplina de avaliação aplicada a cada ação, no diagnóstico cruzado entre fontes, e na documentação das decisões — incluindo as decisões de não atuar.

A coerência exige que o próprio site reflita os padrões que se aconselham aos clientes — e que esses padrões sejam alcançados com a mesma disciplina de ROI que se recomenda em qualquer outro contexto.

Em consultoria de IT sénior, esta disciplina é frequentemente mais valiosa do que a profundidade técnica isolada. É ela que distingue uma intervenção competente de uma intervenção verdadeiramente útil.

Este caso retrata o estado da infraestrutura e das ferramentas em Maio de 2026. SecurityScorecard, Cloudflare e os outros componentes evoluem continuamente; as decisões aqui descritas devem ser revistas à luz do contexto atual em cada momento.

As decisões descritas foram tomadas para um caso específico — site próprio, contexto de risco baixo, sem requisitos regulatórios sectoriais. Em ambientes corporativos sujeitos a regulação específica (PCI-DSS, HIPAA, NIS2, DORA, entre outros), o cálculo de ROI inclui fatores adicionais e algumas decisões podem ser diferentes.

Contacto →