Auditoria gratuita ao site: o que significa a nota e o que corrigir

Escreva o endereço do seu site, carregue num botão e, em menos de um minuto, tem uma nota de segurança de A a F e as quatro notas do Lighthouse da Google. É isto que faz a auditoria gratuita da MarcaWeb, sem registo e sem email. A nota é fácil de ler. O difícil vem a seguir: perceber o que cada linha significa e saber o que corrigir primeiro. Este artigo serve para isso.

Explicamos o que a ferramenta verifica, como a nota é calculada (ponto por ponto, sem segredos), o que fazer para cada resultado, com a configuração para Nginx, Apache, WordPress e Cloudflare, e por que ordem avançar. No fim, dizemos com a mesma clareza o que a ferramenta não consegue ver.

Comece por aqui: abra audit.marcaweb.pt, escreva o endereço (por exemplo, empresa.pt) e volte a este artigo com o resultado à frente.

O que a ferramenta verifica

A auditoria olha para o site por fora, como qualquer visitante ou qualquer atacante o vê, e devolve o resultado em duas fases.

• Segurança, nos primeiros segundos. Os seis cabeçalhos de segurança HTTP que o servidor devia enviar, os cabeçalhos que revelam de mais sobre o servidor, o certificado HTTPS (validade, emissor, dias até expirar e versão do protocolo) e a cadeia de redireccionamentos, passo a passo. Tudo isto dá a nota de A a F.
• Lighthouse, 10 a 45 segundos depois. Os quatro indicadores do Google Lighthouse, medidos pelo PageSpeed Insights em modo telemóvel: desempenho, acessibilidade, boas práticas e SEO, de 0 a 100, mais os três Core Web Vitals (LCP, CLS e INP).
• Informação de contexto. O registo do domínio (registador, data de expiração, servidores de nomes), quando está disponível. Para domínios .pt muitas vezes não está, e nunca conta para a nota.

Enquanto corre, uma consola mostra os passos reais e o que vai encontrando. No resultado, cada cabeçalho pode ser aberto para ver o que faz e o valor exacto que o seu servidor devolveu. A ferramenta não guarda o endereço completo nem quem fez a auditoria.

Como se calcula a nota de segurança

A pontuação começa em 100. Cada um dos seis cabeçalhos de segurança que falte desconta os pontos da tabela. Depois, cada cabeçalho de divulgação que esteja presente (Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version) desconta mais 5. A pontuação nunca desce abaixo de 0.

Os seis cabeçalhos, o que cada um protege e quanto custa a sua falta

Cabeçalho	Contra o quê	Se faltar
Strict-Transport-Security (HSTS)	Obriga o browser a usar sempre HTTPS, mesmo que alguém escreva http:// ou tente forçar uma ligação sem cifra.	−20
Content-Security-Policy (CSP)	Diz ao browser de onde podem vir scripts, estilos e imagens. É a principal defesa contra scripts injectados (XSS).	−20
X-Frame-Options	Impede que o seu site seja metido dentro de um iframe noutro site para enganar cliques (clickjacking).	−10
X-Content-Type-Options	Impede o browser de "adivinhar" o tipo de um ficheiro e executar como script algo que não devia.	−10
Referrer-Policy	Controla quanto do endereço da página o browser envia a outros sites quando o visitante clica numa ligação.	−10
Permissions-Policy	Desliga no browser funcionalidades que o site não usa (câmara, microfone, localização), mesmo que um script tente usá-las.	−5

A nota sai da pontuação final: A de 90 a 100, B de 75 a 89, C de 55 a 74, D de 35 a 54 e F abaixo de 35.

Há uma regra que se sobrepõe a tudo isto. Se o certificado for inválido (expirado, autoassinado, de outro domínio ou de um emissor desconhecido), ou se o endereço final ficar em http sem cifra, a pontuação fica limitada a 39 e a nota é F, por muito bons que sejam os cabeçalhos. Faz sentido: sem HTTPS de confiança, o resto é construído em areia.

Dois pormenores que a ferramenta mostra mas não penaliza: um HSTS com max-age abaixo de 15 768 000 segundos (meio ano) ou sem includeSubDomains aparece com um aviso, sem perder pontos; e um protocolo TLS antigo (TLS 1.0 ou 1.1) é assinalado a título informativo.

Antes de corrigir: onde se mudam os cabeçalhos

Os cabeçalhos de segurança são enviados pelo servidor, não pelas páginas. Onde se configuram depende de como o site está alojado:

• Servidor próprio ou VPS com Nginx: no bloco server do site, com add_header … always;. O always garante que o cabeçalho vai também nas respostas de erro. Atenção a um comportamento do Nginx: se um bloco location tiver o seu próprio add_header, deixa de herdar os do bloco server, e é preciso repeti-los lá.
• Apache ou alojamento partilhado: no ficheiro de configuração do site ou no .htaccess, com Header always set …. Precisa do módulo mod_headers activo (a2enmod headers num servidor próprio; nos alojamentos partilhados costuma estar).
• WordPress: o caminho mais seguro é o servidor (os dois pontos acima). Se não tiver acesso, há plugins que acrescentam cabeçalhos a partir do painel, como o "HTTP Headers", e vários plugins de segurança incluem esta opção. Confirme depois com a auditoria: alguns alojamentos retiram ou sobrepõem cabeçalhos.
• Cloudflare ou outra CDN à frente do site: os cabeçalhos podem ser adicionados na CDN. Na Cloudflare, em Rules, as "Transform Rules" permitem modificar os cabeçalhos de resposta, e o HSTS tem uma opção própria em SSL/TLS → Edge Certificates.

Depois de cada alteração, volte a correr a auditoria e abra a linha do cabeçalho para ver o valor que o servidor devolveu. É a forma mais rápida de confirmar que a alteração chegou ao visitante e não ficou presa numa cache.

O que fazer para cada cabeçalho

Strict-Transport-Security (HSTS), −20

Diz ao browser: "durante este tempo, fala comigo só por HTTPS". O valor habitual é um ano.

# Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Cautelas. Antes de pôr um max-age longo, confirme que tudo funciona em HTTPS: todas as páginas, imagens, scripts e, se usar includeSubDomains, todos os subdomínios (loja., mail., intranet.…). Se um subdomínio só responder em http, deixa de abrir nos browsers que já viram o cabeçalho, até o prazo expirar. Comece com um valor curto, como max-age=300, teste, e só depois suba para o ano. O parâmetro preload inscreve o domínio numa lista embutida nos browsers; é poderoso, mas praticamente irreversível, por isso só quando tiver a certeza de que nunca vai precisar de http em nenhum subdomínio. A ferramenta avisa se o max-age for inferior a meio ano ou se faltar includeSubDomains, mas não tira pontos por isso.

Content-Security-Policy (CSP), −20

É o cabeçalho que mais protege e o que mais parte sites quando é posto à pressa: uma política demasiado restrita bloqueia o Google Analytics, o chat, as fontes externas ou o vídeo do YouTube. A forma correcta de o introduzir é em três passos.

1. Comece em modo de relatório. Com Content-Security-Policy-Report-Only, o browser não bloqueia nada; limita-se a registar na consola (e, se indicar um report-to, a enviar) o que teria bloqueado.
2. Construa a lista de origens permitidas. Navegue pelo site durante alguns dias com a consola aberta e vá acrescentando as origens legítimas (o seu próprio domínio, a CDN, o Analytics, as fontes, o serviço de chat).
3. Passe a impor. Troque o nome do cabeçalho para Content-Security-Policy, com a mesma política.

# Nginx, primeiro em modo de relatório
add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data: https:; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'self'" always;

# Apache, já a impor
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'self'"

A política do exemplo é um ponto de partida, não uma receita: a sua tem de listar o que o seu site usa. No WordPress, os temas e plugins metem scripts e estilos em linha por todo o lado, pelo que uma CSP rigorosa costuma exigir 'unsafe-inline' em style-src e, muitas vezes, em script-src. Mesmo assim vale a pena: limitar as origens de onde podem vir scripts já corta a maior parte dos ataques. A directiva frame-ancestors faz o mesmo que o X-Frame-Options e com mais precisão; se a incluir, mantenha o X-Frame-Options na mesma, porque é o que a ferramenta (e os browsers antigos) verificam.

X-Frame-Options, −10

# Nginx
add_header X-Frame-Options "SAMEORIGIN" always;

# Apache
Header always set X-Frame-Options "SAMEORIGIN"

SAMEORIGIN deixa o seu próprio site enquadrar as suas páginas (alguns construtores de páginas e o editor do WordPress precisam disso); DENY proíbe tudo. Se precisar que um parceiro enquadre uma página sua, isso só se faz com frame-ancestors na CSP.

X-Content-Type-Options, −10

# Nginx
add_header X-Content-Type-Options "nosniff" always;

# Apache
Header always set X-Content-Type-Options "nosniff"

Só tem um valor possível e não parte nada. É o cabeçalho mais fácil de recuperar.

Referrer-Policy, −10

# Nginx
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# Apache
Header always set Referrer-Policy "strict-origin-when-cross-origin"

strict-origin-when-cross-origin é o valor por omissão dos browsers modernos e um bom equilíbrio: outros sites ficam a saber que o visitante veio do seu domínio, mas não de que página. Se preferir não dizer sequer o domínio, use no-referrer, sabendo que o Analytics dos outros deixa de o ver como fonte.

Permissions-Policy, −5

# Nginx
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;

# Apache
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"

Cada funcionalidade entre parênteses vazios fica desligada para a página e para tudo o que ela enquadra. Se o site usa alguma (um mapa que pede a localização, por exemplo), retire-a da lista ou permita-a com geolocation=(self).

Cabeçalhos de divulgação, −5 cada

Um servidor que responde com Server: Apache/2.4.41 (Ubuntu) ou X-Powered-By: PHP/7.4.3 está a dizer a quem procura vulnerabilidades exactamente por onde entrar. A ferramenta desconta 5 pontos por cada um destes cabeçalhos presente: Server, X-Powered-By, X-AspNet-Version e X-AspNetMvc-Version.

# Nginx (nginx.conf): esconde a versão; o cabeçalho Server fica só "nginx"
server_tokens off;

# Apache
ServerTokens Prod
ServerSignature Off
Header always unset X-Powered-By

# PHP (php.ini)
expose_php = Off

Com server_tokens off o Nginx continua a enviar Server: nginx, sem versão; retirar o cabeçalho por completo exige um módulo extra. O mesmo acontece com uma CDN à frente do site (a Cloudflare responde com Server: cloudflare). Nesses casos são 5 pontos que se aceitam: o cabeçalho existe, mas já não revela a versão, que era o que importava. No IIS, os cabeçalhos X-AspNet-Version e X-AspNetMvc-Version retiram-se no web.config (enableVersionHeader="false") e no arranque da aplicação (MvcHandler.DisableMvcResponseHeader = true).

Os problemas do certificado, mensagem a mensagem

Quando o bloco TLS mostra um erro, a nota é F de imediato. Cada mensagem tem uma causa própria e uma solução própria.

• "Certificado expirado". O certificado passou da data. Os visitantes vêem um aviso de página insegura a ecrã inteiro. Se usa Let's Encrypt, a renovação automática falhou: veja o cron ou o timer do certbot e os registos. Se o certificado foi comprado, renove-o junto do fornecedor e instale o novo. A ferramenta mostra os dias que faltam para o próximo vencimento; se for menos de 30 e não tiver renovação automática, marque na agenda.
• "Certificado autoassinado". O certificado foi criado no próprio servidor e nenhum browser confia nele. Costuma ser o certificado de teste do painel de alojamento ou de um servidor novo. Substitua-o por um certificado emitido por uma autoridade reconhecida (o Let's Encrypt é gratuito e a maioria dos painéis instala-o num clique).
• "Certificado não corresponde ao domínio". O certificado é válido, mas foi emitido para outro nome. O caso mais comum: cobre empresa.pt mas não www.empresa.pt, ou o contrário. Emita um certificado com os dois nomes (ou um wildcard) e confirme que o redireccionamento entre as duas formas acontece já em HTTPS.
• "Emissor do certificado desconhecido". O browser não conhece quem assinou o certificado. Quase sempre falta a cadeia intermédia na configuração do servidor: instale o ficheiro completo (fullchain), não só o certificado do site. Também acontece com certificados de autoridades internas de empresas.

Se a cadeia de redireccionamentos acabar num endereço http://, o problema é anterior ao certificado: o site não está a forçar HTTPS. Configure o redireccionamento permanente (301) de http para https no servidor e, no WordPress, confirme que o endereço do site em Definições → Geral começa por https://. A cadeia mostrada pela ferramenta ajuda também a apanhar saltos a mais: http://empresa.pt → https://empresa.pt → https://www.empresa.pt são dois redireccionamentos onde bastava um.

Ler as notas do Lighthouse

O Lighthouse corre em modo telemóvel, com uma ligação e um processador simulados mais lentos do que um computador de secretária, porque é assim que a Google avalia os sites. As quatro notas usam a mesma escala: 90 a 100 é bom (verde), 50 a 89 precisa de melhorias (laranja) e 0 a 49 é fraco (vermelho). A nota de desempenho varia alguns pontos entre execuções, porque depende do estado do servidor e da rede nesse momento; uma diferença de 3 ou 4 pontos não é sinal de nada. Para comparar, faça duas ou três medições.

Os três Core Web Vitals são o que o Google mede e usa como sinal de posicionamento:

Core Web Vitals: os limites da Google

Métrica	O que mede	Bom	Fraco
LCP (Largest Contentful Paint)	Tempo até o maior elemento visível (normalmente a imagem ou o título de topo) aparecer	≤ 2,5 s	> 4 s
CLS (Cumulative Layout Shift)	Quanto a página "salta" enquanto carrega	≤ 0,1	> 0,25
INP (Interaction to Next Paint)	Tempo entre um toque ou clique e a resposta visível	≤ 200 ms	> 500 ms

O que costuma resolver cada área, por ordem de eficácia:

• Desempenho e LCP. Comprimir e redimensionar as imagens (uma fotografia de 4 MB no topo da página é a causa mais comum), servi-las em WebP ou AVIF, dar prioridade à imagem principal e adiar as restantes; activar a cache no servidor ou no plugin; retirar scripts de terceiros que não usa (chats antigos, pixéis de campanhas acabadas); num WordPress, menos plugins e um tema leve.
• CLS. Dar largura e altura a todas as imagens e vídeos, reservar espaço para anúncios e embutidos, e não injectar banners ou barras de cookies por cima do conteúdo depois de a página aparecer.
• INP. Reduzir o JavaScript que corre ao carregar e ao tocar: scripts de rastreio pesados, carrosséis, animações e plugins que escutam cada clique. Em sites pequenos, o INP alto vem quase sempre de scripts de terceiros.
• Acessibilidade. Texto alternativo nas imagens, contraste suficiente entre texto e fundo, rótulos nos campos dos formulários, títulos por ordem (um h1, depois h2, depois h3) e ligações com texto que diga para onde vão. Cada ponto do relatório indica o elemento exacto.
• Boas práticas. Erros na consola do browser, bibliotecas com vulnerabilidades conhecidas, imagens mostradas com uma resolução diferente da real e, claro, HTTPS. Muitas vezes é a actualização de uma biblioteca antiga.
• SEO. Título e meta descrição em cada página, texto legível em telemóvel, ligações rastreáveis, robots.txt válido e sem bloquear o que devia estar indexado. É a nota mais fácil de levar a 100.

Se o desempenho é o seu problema principal, o artigo sobre a velocidade do site e os Core Web Vitals entra em mais pormenor.

O plano: o que corrigir primeiro

Nem tudo vale o mesmo, nem tudo custa o mesmo. Esta é a ordem que recomendamos e o tempo que cada passo costuma levar a quem gere o servidor ou o alojamento.

1. Certificado e HTTPS em todo o lado (horas). Enquanto houver um erro no bloco TLS ou um endereço final em http, a nota é F e os visitantes vêem avisos. Corrija o certificado conforme a mensagem acima e force o redireccionamento para HTTPS. Confirme com a auditoria que o bloco TLS ficou limpo.
2. Os quatro cabeçalhos pequenos (cerca de uma hora). X-Content-Type-Options, X-Frame-Options, Referrer-Policy e Permissions-Policy são 35 pontos e não partem nada num site normal. Quatro linhas na configuração, reiniciar o servidor, testar. É o melhor retorno por minuto investido.
3. HSTS (uma hora, mais um período de teste). Primeiro com um max-age curto e sem includeSubDomains; depois de confirmar que todos os subdomínios respondem em HTTPS, o valor de um ano. Mais 20 pontos.
4. CSP (uma tarde para a primeira versão, depois dias em modo de relatório). É o passo mais demorado e o único em que vale a pena envolver quem desenvolveu o site. Em modo de relatório não há risco; só passe a impor quando a consola estiver limpa durante vários dias de utilização normal. Os últimos 20 pontos.
5. Versões expostas (minutos). server_tokens off, ServerTokens Prod, expose_php = Off. Não muda a nota de forma dramática, mas tira o mapa da mão de quem procura.
6. Lighthouse (contínuo). Comece pelo que o relatório marca a vermelho; as imagens e os scripts de terceiros resolvem a maior parte. Meça de novo depois de cada alteração, sabendo que a nota oscila alguns pontos por si.

Com os passos 1 a 4 feitos, um site chega a A. Os passos 5 e 6 são o que separa um site que passa no teste de um site bem cuidado.

O que a ferramenta não vê

A auditoria gratuita vê o que qualquer pessoa vê da rua: a porta, a fechadura e a placa com o nome. Não entra. Há uma lista de coisas que só se verificam com acesso ao servidor, ao painel e às contas, e são precisamente as que, pela nossa experiência, mais vezes dão problemas numa PME:

• As versões reais do servidor, do CMS, do tema e dos plugins, e se têm vulnerabilidades conhecidas por corrigir.
• As palavras-passe e o segundo factor de quem entra no painel, no alojamento e no email.
• As contas e permissões: quem tem acesso de administrador, contas de antigos colaboradores ou fornecedores ainda activas.
• As cópias de segurança: se existem, onde estão, de quando são e, sobretudo, se alguém já experimentou repô-las.
• Os formulários e o anti-spam: se um formulário pode ser usado para enviar email em seu nome ou para inundar a caixa de entrada.
• Ficheiros expostos: cópias de segurança deixadas na pasta pública, ficheiros de configuração acessíveis, listagens de directórios.
• O email do domínio: SPF, DKIM e DMARC, que decidem se alguém consegue enviar emails em seu nome e se os seus chegam à caixa de entrada (explicámos no artigo sobre emails no spam).
• Os cookies e o consentimento: que cookies são postos antes de o visitante aceitar.
• O plano de resposta a incidentes: quem faz o quê quando o site é comprometido, e quem tem os acessos para o fazer.

É isto que a auditoria de segurança da MarcaWeb cobre: um relatório com o que encontrámos, por ordem de risco, e as correcções feitas ou orçamentadas. Se quiser avançar, peça uma proposta; respondemos em 48 horas. E se prefere começar pelos hábitos, os cinco hábitos de cibersegurança para uma PME continuam a ser o melhor ponto de partida.

Em resumo

A auditoria gratuita dá-lhe, em menos de um minuto, a nota de segurança do seu site e as notas do Lighthouse, sem registo. A nota começa em 100 e perde pontos por cada cabeçalho de segurança em falta (20, 20, 10, 10, 10 e 5) e por cada cabeçalho que anuncia versões (5); um certificado inválido ou um site em http limitam tudo a 39 e à nota F. Corrija pela ordem que mais rende: primeiro o certificado e o HTTPS, depois os quatro cabeçalhos pequenos, depois o HSTS com cuidado e a CSP em modo de relatório antes de impor, e por fim as versões expostas e o Lighthouse. Repita a auditoria depois de cada passo. O que a ferramenta não consegue ver por fora (acessos, cópias de segurança, email, ficheiros expostos, plano de resposta) é o que a auditoria da MarcaWeb verifica por dentro.

Fontes

• MarcaWeb: auditoria gratuita (audit.marcaweb.pt)
• MDN: Strict-Transport-Security
• MDN: Content Security Policy (CSP)
• MDN: X-Frame-Options
• MDN: Referrer-Policy
• Nginx: módulo ngx_http_headers_module (add_header)
• Apache: mod_headers
• web.dev: Web Vitals (limites de LCP, CLS e INP)
• Chrome for Developers: como o Lighthouse calcula a nota de desempenho
• Google: acerca do PageSpeed Insights