O seu domínio tem de ser renovado até 25 de Outubro de 2026. Se expirar, o seu site e o email deixam de funcionar e outra pessoa pode comprar o nome. Sem bloqueio de transferência, alguém que entre na sua conta da entidade de registo, ou a engane, pode transferir o seu domínio para outra empresa com mais facilidade.
O que encontrámos: renovação até 25 de Outubro de 2026 · sem bloqueio de transferência · entidade de registo: OVH SAS
Quem pode corrigir: Titular da conta no registador
O SPF lista os serviços autorizados a enviar e-mail pelo seu domínio. Sem ele, ou com vários registos SPF em conflito, os criminosos podem enviar mais facilmente e-mails em seu nome, e os seus e-mails legítimos têm mais probabilidade de ir parar ao spam.
O que encontrámos: O seu domínio recebe e-mail, mas não publica nenhum registo SPF, pelo que qualquer pessoa pode enviar mais facilmente e-mails que afirmam vir de si.
Quem pode corrigir: O seu administrador de e-mail e quem gere o seu DNS · detetado aqui: Google Workspace (e-mail), Cloudflare (DNS)
Sem HSTS, os navegadores dos seus visitantes podem tentar primeiro a versão não encriptada do seu site, que pode ser intercetada em redes partilhadas, como uma rede Wi-Fi pública.
O que encontrámos: O seu site não envia esta definição de proteção (cabeçalho HTTP) aos navegadores.
Quem pode corrigir: O seu fornecedor de alojamento ou o seu programador web · detetado aqui: Cloudflare (site), WordPress (site)
O seu site e o correio eletrónico precisam de correções essenciais para evitar fraudes.
Gemini 3.8 FlashAdaptado à sua resposta «Não tenho conhecimentos técnicos»
Risco significativo
A sua padaria tem uma presença digital ativa, mas existem pontos fracos que facilitam o envio de mensagens falsas em seu nome e o bloqueio do seu endereço na Internet. O sistema que gere o site está desatualizado e o registo do seu domínio necessita de renovação imediata para não perder o controlo da sua marca. Adicionalmente, a falta de regras de proteção no correio eletrónico expõe os seus clientes e parceiros a tentativas de burla e engano. Aplicar as correções prioritárias com o seu prestador de serviços e ativar a confirmação em dois passos nas suas contas protege a reputação do seu negócio.
Páginas do seu site exploradas pelo agente: 5
https://bakery.example/200
https://bakery.example/my-account/200
https://bakery.example/order/200
https://bakery.example/contact/200
https://bakery.example/privacy-policy/200
Pedidos identificados como FmindCyber, só de leitura, limitados ao seu domínio e às páginas para as quais este tem ligações: sem início de sessão, envio de formulários nem caminhos adivinhados.
O seu plano de ação
Fazer jáAlguns minutos · O proprietário da empresa na entidade de registo (OVH SAS)Serviço pago
Renovar o registo do domínio e ativar o bloqueio de transferência
O seu domínio expira dentro de 24 dias; se não for renovado a tempo, o seu site e o correio eletrónico deixam de funcionar e qualquer pessoa poderá comprar o endereço da sua padaria. Sem a proteção de transferência ativa, um terceiro mal-intencionado com acesso à conta pode transferir o domínio para outra entidade.
Como fazer
Aceda à sua área de cliente na OVH SAS com as suas credenciais habituais.
Ative a confirmação em dois passos nas definições de segurança da conta para impedir acessos não autorizados.
Renove o domínio bakery.example por pelo menos um ano adicional e certifique-se de que a renovação automática está associada a um cartão válido.
Ative a opção de bloqueio de transferência (registrar lock) no painel de gestão do domínio.
Confirmar que resultou: Confirme na área de cliente que a data de renovação foi prolongada e que o domínio se encontra com o estado de transferência bloqueado.
Fazer jáAlgumas horas · O administrador do Google Workspace e o gestor de DNS na CloudflareNormalmente incluído pelo seu fornecedor
Autorizar os servidores de correio e proteger o domínio contra falsificação
Atualmente, qualquer pessoa pode enviar mensagens falsas fingindo pertencer à sua padaria, porque os sistemas recetores não têm indicações para rejeitar envios não autorizados. Isso expõe os seus clientes a enganos e aumenta a probabilidade de as suas mensagens legítimas irem para o lixo eletrónico.
Como fazer
Ative a confirmação em dois passos na sua conta Google Workspace para salvaguardar o acesso administrativo.
Contacte o responsável pela gestão do DNS na Cloudflare e solicite a publicação das regras de proteção de correio eletrónico.
Peça a criação do registo SPF fornecido para autorizar formalmente os servidores de envio do Google Workspace.
Solicite a publicação da regra DMARC em modo de monitorização para auditar o tráfego de e-mail do domínio.
No DNS da Cloudflare:
Tipo: TXT | Nome: @ | Conteúdo: v=spf1 include:_spf.google.com ~all
Tipo: TXT | Nome: _dmarc | Conteúdo: v=DMARC1; p=none; rua=mailto:seguranca@bakery.example
Confirmar que resultou: Envie uma mensagem de teste a partir da sua conta profissional para um endereço externo pessoal e confirme nos cabeçalhos recebidos que a autenticação de correio foi validada.
Passo seguinte, quando isto funcionar: Após algumas semanas a analisar relatórios sem incidentes, solicite ao fornecedor a alteração da política DMARC de p=none para p=quarantine e, finalmente, p=reject.
Fazer em breveAlgumas horas · O programador web ou agência responsável pela manutenção do WordPressNormalmente incluído pelo seu fornecedor
Atualizar o WordPress e extensões e ativar atualizações automáticas
A versão do programa que gere o site contém falhas de segurança conhecidas que são procuradas de forma automática por atacantes na Internet. Manter o sistema desatualizado pode permitir a invasores alterar conteúdos, intercetar dados de clientes ou assumir o controlo das páginas.
Como fazer
Ative a confirmação em dois passos para todas as contas de administrador no painel do WordPress.
Solicite ao seu programador uma cópia de segurança completa do site e dos ficheiros antes de proceder a atualizações.
No painel do WordPress, instale a versão mais recente do sistema e atualize as extensões e temas existentes.
Ative as atualizações automáticas de segurança no painel e elimine extensões ou temas inativos.
Confirmar que resultou: Aceda à secção de atualizações do painel do WordPress e confirme que não existem avisos pendentes, testando de seguida os pedidos e formulários no site.
Fazer em breveAlgumas horas · O gestor técnico do site ou fornecedor na CloudflareNormalmente incluído pelo seu fornecedor
Reforçar a proteção da navegação e impedir a incorporação indevida
Sem estas definições no servidor, a ligação pode ser forçada a circular sem proteção em redes públicas e outros sites podem tentar exibir o seu conteúdo em janelas transparentes para induzir os visitantes a cliques involuntários.
Como fazer
Ative a confirmação em dois passos na conta de gestão da Cloudflare.
No painel da Cloudflare, em SSL/TLS, configure o envio da regra HSTS com uma duração inicial curta de teste.
Em regras de transformação de cabeçalhos, adicione as proteções contra incorporação invisível do site e bloqueio de acesso a câmara e microfone.
No Cloudflare:
Strict-Transport-Security: max-age=300
X-Frame-Options: SAMEORIGIN
Permissions-Policy: camera=(), microphone=(), geolocation=()
Confirmar que resultou: Navegue pelas páginas do site e verifique que continuam a carregar normalmente com ligação segura e sem avisos no navegador.
Olá,
Realizámos recentemente uma verificação preventiva de segurança ao nosso domínio bakery.example e gostaríamos de solicitar a implementação de algumas melhorias técnicas, organizadas pela seguinte ordem de prioridade:
1. Proteção de correio eletrónico (SPF e DMARC) no Cloudflare e Google Workspace:
- Publicar o registo TXT para SPF no DNS do nosso domínio, autorizando o envio através do Google Workspace:
v=spf1 include:_spf.google.com ~all
- Publicar a política DMARC em modo de monitorização para acompanharmos o envio de mensagens:
v=DMARC1; p=none; rua=mailto:seguranca@bakery.example
- Confirmar que a assinatura DKIM se encontra devidamente ativada no Google Workspace.
2. Atualização do WordPress e respetivos componentes:
- Realizar uma cópia de segurança completa do site e da base de dados.
- Atualizar o WordPress para a versão mais recente e estável.
- Atualizar as extensões ativas (WooCommerce, Contact Form 7, Cookie Notice e o tema Astra) e remover quaisquer temas ou extensões sem utilização.
- Ativar as atualizações automáticas de segurança no painel.
3. Definições de proteção no Cloudflare (cabeçalhos de resposta):
- Ativar o HSTS com uma duração inicial de teste (Strict-Transport-Security: max-age=300).
- Configurar regras de resposta (Transform Rules) com os seguintes valores:
X-Frame-Options: SAMEORIGIN
Permissions-Policy: camera=(), microphone=(), geolocation=()
4. Validação do formulário de contacto:
- Confirmar que o campo de envio de ficheiros no Contact Form 7 restringe as extensões apenas a imagens comuns e limita o tamanho máximo de envio.
Agradecemos a confirmação assim que estas alterações forem efetuadas.
Com os melhores cumprimentos,
[Name]
Mais da sua análise: riscos, o que o agente observou, plano e glossário
O que pode correr mal
Provável
Envio de mensagens falsas e faturas fraudulentas em nome da padaria
Um burlão envia mensagens fraudulentas em nome da padaria dirigidas a clientes habituais ou fornecedores, solicitando o pagamento de encomendas ou alteração de dados bancários. Como o domínio não tem regras a indicar que apenas os seus serviços oficiais podem expedir mensagens, os sistemas de destino aceitam as comunicações como autênticas, levando os destinatários a confiar no remetente e a transferir valores para contas criminosas.
Provável
Intrusão no site e manipulação de encomendas através de falhas conhecidas
Atacantes utilizam ferramentas automatizadas na Internet à procura de sites com versões antigas do sistema de gestão que tenham falhas conhecidas. Ao identificarem que o site da padaria utiliza uma versão desatualizada, exploram essa vulnerabilidade para assumir o controlo da administração, podendo desfigurar as páginas públicas, intercetar dados submetidos pelos clientes nas encomendas ou injetar código malicioso.
O que o agente notou no seu site
Presença de endereço de e-mail gratuito nos contactos públicosObservado
Apesar de o domínio dispor de registos de receção no Google Workspace, o endereço visível para os visitantes na página inicial e no rodapé é uma conta gratuita do Gmail (@gmail.com). Utilizar um endereço com o domínio próprio da empresa transmite maior credibilidade aos clientes e mantém a posse das mensagens sob o controlo direto do negócio.
Carregamento de script de análise antes da recolha de consentimentoObservado
O script de acompanhamento do Google Tag Manager é descarregado diretamente no carregamento da página inicial, juntamente com o componente de aviso de cookies. Convém verificar com o programador se os dados de navegação só são enviados após a aceitação voluntária do visitante no aviso, garantindo as melhores práticas de privacidade.
Submissão de ficheiros no formulário de contactoObservado
O formulário de contacto do site inclui um campo para submissão de ficheiros (fotografias) através da extensão Contact Form 7. É recomendável assegurar que o servidor valida estritamente os tipos de ficheiro aceites e limita o tamanho máximo permitido, prevenindo o envio de conteúdos maliciosos.
Presença de extensões e tema a necessitar de acompanhamentoInferido
Durante a navegação nas páginas foram identificados o tema Astra (4.6.2) e as extensões WooCommerce (8.9.1), Contact Form 7 (5.9.3) e Cookie Notice (2.4.16). Como a verificação automática incidiu apenas no núcleo da plataforma, o administrador deve aceder ao painel interno e confirmar se existem novas versões disponíveis para cada um destes elementos.
O certificado de segurança encontra-se ativo e válido, garantindo a proteção da ligação dos visitantes.
Os visitantes que acedem ao endereço sem prefixo de segurança são encaminhados automaticamente para a ligação protegida.
O site instrui os navegadores a respeitar os tipos legítimos de ficheiros, prevenindo a execução inadequada de conteúdos.
O domínio não se encontra assinalado em catálogos públicos de segurança como distribuindo conteúdos perigosos.
Termos utilizados neste relatório
Confirmação em dois passos (2FA)
Mecanismo de segurança que exige um código temporário adicional além da palavra-passe para aceder a uma conta.
DNS
Sistema público que encaminha os visitantes e as mensagens de correio para os servidores corretos da sua empresa.
SPF
Registo público que indica quais os serviços autorizados a enviar mensagens de correio eletrónico em nome do seu domínio.
DMARC
Regra que indica aos destinatários como lidar com mensagens que tentem imitar indevidamente o endereço da sua empresa.
HSTS
Definição técnica que obriga os navegadores a comunicar com o site exclusivamente através de ligações protegidas.
Extensão (Plugin)
Módulo complementar instalado no site para disponibilizar funcionalidades adicionais, como formulários ou lojas.
Esta análise avaliou a informação pública do seu domínio, incluindo as definições no DNS público e as páginas acessíveis no site (a página inicial, a área de conta, a página de pedidos, o formulário de contacto e a política de privacidade). A verificação passiva não acede aos bastidores dos servidores, não consulta código privado nem bases de dados, não tenta iniciar sessão nem submeter formulários, e não inspeciona as definições internas das caixas de correio no fornecedor de serviço. Para avaliar aspetos mais aprofundados, são recomendadas revisões técnicas autorizadas com os seus prestadores de serviço. Escrito por um agente de IA num ambiente isolado a partir das evidências deste relatório e das páginas que explorou; a nota e as verificações abaixo resultam de testes determinísticos.
Este exemplo premium foi escrito em inglês. A sua própria análise premium é escrita no seu idioma.
Plano de ação com IA
Renew your domain urgently, update WordPress, and protect your bakery against email spoofing.
Premium · Gemini 4 ArgonAdaptado à sua resposta «Giro o meu site num painel de administração»
Risco significativo
Golden Crust Bakery (bakery.example) currently earns a C grade (score 65) with an elevated risk level. Your foundation has solid pieces in place: a valid TLSv1.3 HTTPS certificate, automatic redirection from HTTP to HTTPS, x-content-type-options: nosniff protection, CAA records restricting certificate issuance to letsencrypt.org, and Google Workspace MX and candidate DKIM records. However, three urgent issues put your business at immediate risk. First, your domain registration at OVH SAS is due for renewal on October 25, 2026, and has no transfer lock enabled, meaning your website and email could stop working or be transferred away if not renewed and locked today. Second, your website runs WordPress 6.8 (while 7.1.3 is available) and loads an outdated jQuery 1.12.4 library with known security flaws, while your public user sitemap and author page (/author/marie/) expose the administrator username marie. Third, your domain publishes no SPF record and its DMARC policy (p=none) does not block fake emails or send reports to any mailbox, allowing scammers to spoof @bakery.example emails to your catering and online-order customers. Working with Pixel Agency (listed on your legal notice as your website maintainer) and using your OVH, Cloudflare, and Google Workspace dashboards, you can resolve the most urgent domain, WordPress, and email spoofing risks this week and then add browser security headers and cookie protections over the coming month.
Pedidos identificados como FmindCyber, só de leitura, limitados ao seu domínio e às páginas para as quais este tem ligações: sem início de sessão, envio de formulários nem caminhos adivinhados.
O seu plano de ação
Fazer jáAlguns minutos · Business owner (in your OVH SAS registrar dashboard)Gratuito
Renew your domain name immediately and turn on the registrar transfer lock
Your domain registration is due for renewal on October 25, 2026, and has no transfer lock enabled. If it expires, both your website and email stop working immediately and someone else can buy your domain name. Without a transfer lock, anyone who gets into your registrar account can move your domain to another provider.
Como fazer
Sign in to your OVH SAS control panel and open the Domain Names section for bakery.example.
Renew the domain immediately for at least one year, turn on automatic renewal, and confirm that your saved payment method is valid.
In the domain general information tab, enable the domain transfer lock (protection against transfer) and turn on two-step sign-in for your OVH account.
Confirmar que resultou: Check your OVH domain panel to confirm the new expiration date is in 2027 or later and that transfer protection shows as active.
Passo seguinte, quando isto funcionar: Keep automatic renewal enabled and verify your saved payment card in OVH each year at least 30 days before the renewal date.
Fazer jáAlgumas horas · Pixel Agency (your web developer) and business owner in WordPress AdminNormalmente incluído pelo seu fornecedor
Update WordPress, plugins, and jQuery, and protect the administrator account
Your website runs WordPress 6.8 (while 7.1.3 is available) and loads jQuery 1.12.4, both of which have publicly known security flaws that automated bots actively target. In addition, your user sitemap and author page reveal the administrator username marie, making password-guessing attacks against your sign-in page much easier.
Como fazer
Take a full backup of your website files and database through your OVHcloud hosting panel or backup plugin before making changes.
In WordPress, go to Dashboard -> Updates, update WordPress from 6.8 to 7.1.3, update your theme (astra4.6.2) and plugins (woocommerce8.9.1, contact-form-75.9.3, cookie-notice2.4.16), and click Enable auto-updates for all plugins and themes.
Ask Pixel Agency to replace the external https://code.jquery.com/jquery-1.12.4.min.js script with the current version bundled with WordPress, and to hide public version numbers (WordPress 6.8 and ?ver= query strings).
Enable two-step sign-in for the marie administrator account and any staff accounts, change the public display name so it differs from the login username, and restrict public user sitemaps (/wp-sitemap-users-1.xml) and file upload types on /contact/.
Confirmar que resultou: Check Dashboard -> Updates in WordPress to confirm version 7.1.3 and all plugin updates are installed, confirm jquery-1.12.4.min.js and the WordPress 6.8 generator tag no longer appear on your homepage, and test signing in with two-step verification.
Passo seguinte, quando isto funcionar: Review installed plugins quarterly with Pixel Agency and remove any plugins or themes that are no longer used.
Fazer jáAlgumas horas · Business owner (in Google Workspace Admin) and DNS manager (in Cloudflare)Gratuito
Publish an SPF record, confirm DKIM signing, and set up DMARC reporting
Your domain receives email through Google Workspace (smtp.google.com) and publishes a google._domainkey record, but has no SPF record at all and its DMARC policy (v=DMARC1; p=none) neither blocks fake emails nor sends reports to a mailbox. Criminals can spoof @bakery.example to send fake catering invoices to your customers, and genuine emails may land in spam.
Como fazer
List every service that sends email using @bakery.example, including Google Workspace, your website forms (woocommerce and contact-form-7), and Mailchimp if it sends from your domain.
In Cloudflare, go to DNS -> Records and publish a single TXT record on bakery.example with v=spf1 include:_spf.google.com ~all (adding any other confirmed sending services to that same record).
In the Google Workspace Admin console, go to Apps -> Google Workspace -> Gmail -> Authenticate email, select bakery.example, and confirm that DKIM signing is active for your google._domainkey record.
In Cloudflare (DNS -> Records), update the _dmarc.bakery.exampleTXT record to add a monitored reporting mailbox (rua=mailto:postmaster@bakery.example) while keeping p=none during initial monitoring, and replace goldencrust.bakery@gmail.com on your website footer with an @bakery.example address once ready.
Confirmar que resultou: Send a test email from a @bakery.example Google Workspace mailbox to an external email address and check the received message headers to confirm spf=pass, dkim=pass, and dmarc=pass.
Passo seguinte, quando isto funcionar: After two to four weeks of clean DMARC reports showing that all legitimate emails pass, update _dmarc.bakery.example from p=none to p=quarantine, and later to p=reject.
Fazer em breveAlgumas horas · Pixel Agency (your web developer)Normalmente incluído pelo seu fornecedor
Add Secure and HttpOnly cookie protections and fix unencrypted image links
Cookies set on your homepage (wp_lang) and sign-in page (wordpress_test_cookie) lack the Secure flag, allowing them to travel over unencrypted connections, and session cookies without HttpOnly can be stolen by malicious scripts to hijack accounts. In addition, your homepage loads its logo (http://bakery.example/wp-content/uploads/2019/03/logo.png) over unencrypted HTTP.
Como fazer
In WordPress, go to Settings -> General and confirm both WordPress Address (URL) and Site Address (URL) use https://, then update http://bakery.example/wp-content/uploads/2019/03/logo.png and any other http:// media links to https://.
Ask Pixel Agency to review the cookies set across the site (wp_lang on the homepage and wordpress_test_cookie on /my-account/) and ensure every cookie sets the Secure attribute and all sign-in or session cookies also set HttpOnly.
While reviewing /my-account/, check the WooCommerce endpoint settings (WooCommerce -> Settings -> Advanced) so customers have a working password reset flow.
Confirmar que resultou: Open https://bakery.example/ and https://bakery.example/my-account/ in a browser, check the developer tools cookie list to confirm Secure (and HttpOnly for session cookies) are enabled, and verify no http:// mixed content warnings appear.
Passo seguinte, quando isto funcionar: Whenever a new plugin is installed, check browser storage tools to ensure any new session cookies include Secure and HttpOnly.
Fazer em breveAlguns minutos · Pixel Agency or business owner (in Cloudflare dashboard)Gratuito
Enable HSTS, clickjacking protection, and Permissions-Policy headers in Cloudflare
Without Strict-Transport-Security (HSTS), visitors on public Wi-Fi can have their initial connection intercepted before redirecting to HTTPS. Without X-Frame-Options and Permissions-Policy, other websites can embed your pages in hidden frames to trick customers into clicking buttons (clickjacking), and scripts could request access to camera, microphone, or location features.
Como fazer
In the Cloudflare dashboard for bakery.example, check SSL/TLS -> Edge Certificates to confirm Always Use HTTPS is enabled and Minimum TLS Version is set to at least TLS 1.2.
Go to Rules -> Overview and create a Response Header Transform Rule matching HTTPS requests for http.host eq "bakery.example" and ssl.
Add three Set static header actions: Strict-Transport-Security with value max-age=300 (a five-minute initial trial), X-Frame-Options with value SAMEORIGIN, and Permissions-Policy with value camera=(), microphone=(), geolocation=().
Match: (http.host eq "bakery.example" and ssl)
Set static: Strict-Transport-Security = max-age=300
Set static: X-Frame-Options = SAMEORIGIN
Set static: Permissions-Policy = camera=(), microphone=(), geolocation=()
Confirmar que resultou: Load https://bakery.example/ and verify in browser developer tools (Network tab) that Strict-Transport-Security, X-Frame-Options, and Permissions-Policy appear in the response headers and that all pages and the booking frame load normally.
Passo seguinte, quando isto funcionar: Once you confirm all pages and subdomains work over HTTPS without errors, increase Strict-Transport-Security step by step to max-age=15768000 (six months) and then max-age=31536000 (one year).
Fazer em breveAlgumas horas · Pixel Agency (your web developer) in CloudflareNormalmente incluído pelo seu fornecedor
Deploy a Content Security Policy starting in report-only mode
Your pages load third-party scripts and frames without a Content-Security-Policy header. If a vulnerable plugin or compromised script injects malicious code into your order or sign-in pages, browsers currently have no rule stopping that code from running and stealing customer information.
Como fazer
Ask Pixel Agency to list every external script, font, style, form action, and frame origin used across your site, including www.googletagmanager.com, booking.example.net, and bakery.us21.list-manage.com.
In Cloudflare (Rules -> Overview), add a Response Header Transform Rule setting Content-Security-Policy-Report-Only first, so browsers report policy violations without blocking anything on the live site.
Test every customer journey—signing in at /my-account/, ordering pick-up items at /order/, sending a message with an image at /contact/, and loading the booking widget on the homepage—before switching to enforcement.
Confirmar que resultou: Open your homepage, /my-account/, /order/, and /contact/ in a browser, confirm Content-Security-Policy-Report-Only is present in the response headers, and check the browser console to ensure legitimate features work cleanly.
Passo seguinte, quando isto funcionar: After testing all key pages in report-only mode and resolving any legitimate warnings, change the header name from Content-Security-Policy-Report-Only to Content-Security-Policy to enforce the protection.
Mais tardeAlguns minutos · Pixel Agency or website managerGratuito
Publish a security.txt contact file for security researchers
No /.well-known/security.txt file is currently available on your website. If a security researcher or partner finds a problem on your site, they have no standard way to report it directly to your team.
Como fazer
Set up a monitored email address or alias on your domain (such as security@bakery.example) for receiving security reports.
Ask Pixel Agency to publish a UTF-8 plain-text file at /.well-known/security.txt containing Contact:, Expires: (in RFC 3339 format), and Canonical: lines.
Confirmar que resultou: Open https://bakery.example/.well-known/security.txt in a browser and confirm it displays the plain-text contact file with a future expiration date.
Passo seguinte, quando isto funcionar: Set a yearly calendar reminder to update the Expires: date before it lapses.
Mais tardeAlguns minutos · DNS manager (in Cloudflare) and registrar manager (in OVH SAS)Gratuito
Inspect and confirm end-to-end DNSSEC validation between Cloudflare and OVH SAS
Public DNS shows a published DS record for bakery.example, which helps prevent attackers from redirecting visitors or email to fake servers, but the passive check does not verify whether the cryptographic chain of trust is valid from end to end.
Como fazer
Note that this item is unassessed rather than a confirmed defect; inspect the current setup before changing anything, because an incorrect change can make your domain unreachable.
In Cloudflare (DNS -> Settings -> DNSSEC) and your OVH SAS domain control panel, check that the active zone signing key matches the published parent DS record (key tag 2371, algorithm 13).
Ask Pixel Agency or your DNS administrator to run an independent end-to-end DNSSEC chain validation and document a rollback procedure before making any future DNS changes.
Confirmar que resultou: Confirm in Cloudflare's DNSSEC settings that DNSSEC shows as active and that your DNS administrator confirms end-to-end signature validation.
Passo seguinte, quando isto funcionar: Before any future DNS migration or registrar change, coordinate disabling and re-enabling DNSSEC carefully so your domain stays reachable.
Hello Pixel Agency team,
We recently completed a security review of https://bakery.example/ and would like your help applying the following updates, ordered by priority:
1. Domain renewal and transfer lock (urgent - due October 25, 2026)
- Please confirm with us that bakery.example is renewed in the OVH SAS registrar panel, automatic renewal is enabled, and the registrar transfer lock is turned on.
2. WordPress core, plugins, jQuery, and administrator security (urgent)
- Back up the site on OVHcloud, then update WordPress from 6.8 to 7.1.3 and update the astra (4.6.2) theme and all plugins (woocommerce 8.9.1, contact-form-7 5.9.3, cookie-notice 2.4.16), enabling automatic updates.
- Replace the external https://code.jquery.com/jquery-1.12.4.min.js script with the current version bundled with WordPress.
- Remove the public WordPress 6.8 generator tag and ?ver= asset version strings, disable the public users sitemap (/wp-sitemap-users-1.xml), change the public display name for the marie administrator account, and enable two-step sign-in for all administrators.
- Verify that the file upload field on /contact/ strictly restricts allowed image types and file sizes.
3. Email authentication for @bakery.example (high priority)
- Confirm all services that send email from @bakery.example (Google Workspace, WooCommerce/Contact Form 7, and Mailchimp if applicable) and publish a single SPF TXT record on bakery.example, starting from v=spf1 include:_spf.google.com ~all.
- Confirm active DKIM signing for google._domainkey.bakery.example in Google Workspace Admin (Apps -> Google Workspace -> Gmail -> Authenticate email).
- Update _dmarc.bakery.example to include a monitored report address (v=DMARC1; p=none; rua=mailto:postmaster@bakery.example) so we can review reports and move to p=quarantine and p=reject.
4. HTTPS mixed content, cookies, and password reset link (soon)
- Update the unencrypted logo URL (http://bakery.example/wp-content/uploads/2019/03/logo.png) to https:// and verify both URLs under Settings -> General use https://.
- Ensure all cookies (including wp_lang and wordpress_test_cookie) use the Secure attribute and that sign-in/session cookies also use HttpOnly.
- Check the /my-account/lost-password/ endpoint in WooCommerce so customer password resets work properly, and check that Google Tag Manager (G-EXAMPLE) waits for cookie consent.
5. Cloudflare security headers, security.txt, and DNSSEC check (soon / later)
- In Cloudflare (Rules -> Overview), add a Response Header Transform Rule for bakery.example over HTTPS setting Strict-Transport-Security: max-age=300 (to be increased after testing), X-Frame-Options: SAMEORIGIN, and Permissions-Policy: camera=(), microphone=(), geolocation=().
- Prepare and test a Content-Security-Policy-Report-Only header covering self, https://www.googletagmanager.com, https://booking.example.net, and https://bakery.us21.list-manage.com before enforcing it.
- Publish https://bakery.example/.well-known/security.txt as plain text with a monitored contact address and future expiration date, and confirm that the DNSSEC DS record (key tag 2371) at OVH SAS validates end to end with Cloudflare.
Please let me know when Steps 1 through 3 are complete and share the schedule for the remaining items.
Best regards,
[Name]
Mais da sua análise: riscos, o que o agente observou, plano e glossário
O que pode correr mal
Provável
Automated website takeover via outdated WordPress software or exposed admin username
Automated bots constantly scan websites for WordPress 6.8 and jQuery 1.12.4, and read /wp-sitemap-users-1.xml and /author/marie/ to discover that your administrator username is marie. An attacker either exploits a known flaw in the outdated software or runs automated password-guessing attacks against /my-account/ for user marie, gaining control of your store to deface pages or read customer pick-up orders.
Provável
Spoofed catering invoices and payment requests sent in your bakery's name
Because bakery.example publishes no SPF record and its DMARC policy is p=none with no reporting address, a scammer sends emails appearing to come from orders@bakery.example to your wedding-cake or catering customers asking them to wire a deposit to a fraudulent bank account. Receiving mail providers have no rule telling them to block these fake messages, and customers may also be confused because the website footer shows a free @gmail.com address.
Possível
Injected script stealing customer login sessions or order details
An attacker uses the known flaw in jQuery 1.12.4 or a vulnerable plugin to inject a malicious script into /order/ or /my-account/. Because no Content-Security-Policy header restricts which scripts may run or where they can send data, the script runs in visitors' browsers, reading unprotected cookies or skimming customer names, phone numbers, and passwords as they are typed.
Pouco provável, mas possível
Interception of unencrypted requests or cookies on shared public Wi-Fi
A customer or staff member connects to café Wi-Fi and visits bakery.example. Before the browser redirects to HTTPS—or when it requests the unencrypted http:// logo image or sends cookies (wp_lang, wordpress_test_cookie) that lack the Secure flag—someone on the same wireless network intercepts the initial connection or reads the unprotected cookies.
O que o agente notou no seu site
Administrator username exposed on author page and user sitemapObservado
Your public user sitemap (/wp-sitemap-users-1.xml) and blog page (/blog/) link to /author/marie/, which publicly displays the administrator's username and role. Giving away the exact administrator login name makes automated password-guessing attacks against /my-account/ much easier.
Posts by Marie (administrator)https://bakery.example/author/marie/
Sign-in page sets an unprotected cookie and links to a missing password reset pageObservado
The customer account page (/my-account/) serves a password login form (method="post") and sets a cookie named wordpress_test_cookie without the Secure or HttpOnly attributes. Its password reset link (/my-account/lost-password/) also points to a page we could not reach.
wordpress_test_cookie (secure: false, httponly: false) and form action https://bakery.example/my-account/ with password fieldhttps://bakery.example/my-account/
Contact form accepts file uploads via Contact Form 7Observado
Your contact page (/contact/) invites customers to upload an inspiration photo using a file input field powered by the contact-form-7 plugin (version 5.9.3). File upload forms need strict checks on allowed image formats and file size so attackers cannot upload malicious scripts or fill up server storage.
Send us a message and your inspiration photo · form action https://bakery.example/contact/#wpcf7-f42-o1 with file fieldhttps://bakery.example/contact/
Google Analytics script loads alongside the cookie consent pluginObservado
Every page loads Google Tag Manager (https://www.googletagmanager.com/gtag/js?id=G-EXAMPLE) immediately alongside the cookie-notice plugin (ver=2.4.16). Loading analytics scripts before a visitor accepts the cookie banner can raise privacy compliance questions that you should check with an advisor.
Public contact address uses a free Gmail account instead of your domainObservado
Even though your domain has Google Workspace mail servers configured, every page lists a free Gmail address (goldencrust.bakery@gmail.com) as your public contact. Using a free webmail address makes it harder for customers to spot look-alike Gmail accounts created by scammers.
WordPress plugin versions and third-party booking and newsletter services identifiedObservado
Your pages expose the exact versions of your theme (astra4.6.2) and plugins (woocommerce8.9.1, contact-form-75.9.3, cookie-notice2.4.16), which can be updated in WordPress under Dashboard -> Updates. The site also embeds a booking frame from https://booking.example.net, sends newsletter sign-ups to https://bakery.us21.list-manage.com/subscribe/post, and posts online pick-up orders from /order/ to /checkout/.
External scripts loaded without integrity verification hashesObservado
Every page loads two third-party scripts (https://code.jquery.com/jquery-1.12.4.min.js and https://www.googletagmanager.com/gtag/js?id=G-EXAMPLE) without subresource integrity checks. If an external script host were ever modified, browsers would run the altered script on your sign-in and ordering pages automatically.
2 external scripts loaded from https://code.jquery.com and https://www.googletagmanager.com without integrity attributeshttps://bakery.example/
Web agency and hosting provider identified on legal notice pageObservado
Your legal notice page states that the site is built and maintained by Pixel Agency and hosted by OVHcloud in Roubaix, France. Knowing that Pixel Agency manages WordPress while Cloudflare and OVH handle DNS, hosting, and domain registration helps you assign each security fix to the right team.
Publisher: Golden Crust Bakery SARL. Website built and maintained by Pixel Agency. Hosting: OVHcloud, Roubaix, France.https://bakery.example/legal-notice/
O seu roteiro
Esta semana
Renew bakery.example at OVH SAS before October 25, 2026, turn on automatic renewal, and enable the domain transfer lock.
Back up the site and update WordPress from 6.8 to 7.1.3, update all plugins and the astra theme, replace jQuery 1.12.4, and enable two-step sign-in for administrator marie.
Publish a single SPF record (v=spf1 include:_spf.google.com ~all), confirm active Google Workspace DKIM signing, and add a rua= reporting mailbox to _dmarc.bakery.example.
Este mês
Fix the unencrypted http:// logo link on the homepage, add Secure and HttpOnly flags to cookies, and repair the /my-account/lost-password/ page in WooCommerce.
Add Strict-Transport-Security (max-age=300), X-Frame-Options (SAMEORIGIN), and Permissions-Policy via a Cloudflare Response Header Transform Rule.
Deploy a Content-Security-Policy-Report-Only header in Cloudflare and test sign-in, online ordering, contact uploads, and the booking widget.
Este trimestre
Review DMARC reports and step up _dmarc.bakery.example from p=none to p=quarantine and then p=reject, and replace goldencrust.bakery@gmail.com on the site with an @bakery.example address.
Switch Content-Security-Policy-Report-Only to an enforced Content-Security-Policy header and increase Strict-Transport-Security to max-age=31536000 (one year).
Publish /.well-known/security.txt and verify end-to-end DNSSEC chain validation between Cloudflare and OVH SAS.
O que já está bem
Your HTTPS security certificate is valid until December 29, 2026, and protects connections using modern TLSv1.3 encryption.
Visitors who type your web address without https:// are automatically redirected to the encrypted HTTPS website.
Your server sends the x-content-type-options: nosniff header so browsers do not misinterpret uploaded or served file types.
Public DNS includes CAA records limiting certificate issuance to letsencrypt.org, Google Workspace MX records, and a candidate DKIM key at google._domainkey.bakery.example.
Your website is not flagged as dangerous by Google Safe Browsing and uses safe default referrer behavior across linked pages.
Termos utilizados neste relatório
Content Security Policy (CSP)
An HTTP response header that tells browsers which scripts, frames, and connections are allowed to run on your pages, helping block injected malicious code.
DMARC
A DNS record that tells receiving email servers what to do with messages claiming to come from your domain that fail SPF or DKIM checks, and where to send summary reports.
DKIM
A digital signature added to outgoing emails by your mail provider (such as Google Workspace) so receivers can verify the message was genuinely sent by your domain.
DNSSEC
A system of digital signatures on your DNS records that prevents attackers from redirecting your domain name to a fake server.
HSTS
An HTTP header (Strict-Transport-Security) that instructs browsers to always connect to your website over encrypted HTTPS and never fall back to unencrypted HTTP.
Secure and HttpOnly cookie flags
Flags on browser cookies: Secure ensures the cookie is only sent over encrypted HTTPS, and HttpOnly blocks page scripts from reading session cookies.
SPF
A DNS TXT record listing every mail server and third-party service authorized to send email on behalf of your domain.
Transfer lock
A safety lock at your domain registrar (OVH SAS) that blocks your domain name from being moved to another registrar without your explicit approval.
This passive review examined public DNS records, HTTPS certificate settings, and publicly reachable pages on `bakery.example` (including your homepage, `/my-account/`, `/order/`, `/contact/`, `/privacy-policy/`, `/legal-notice/`, `/blog/`, `/robots.txt`, `/wp-sitemap.xml`, `/wp-sitemap-users-1.xml`, `/wp-sitemap-posts-page-1.xml`, and `/author/marie/`). Pages we could not reach (`/sitemap.xml`, `/my-account/lost-password/`, and `/.well-known/security.txt`) were not accessible. Because a passive check never signs in, submits forms, or tests for vulnerabilities, it cannot see inside your WordPress admin panel, Cloudflare or Google Workspace dashboards, server configuration, payment processing behind `/checkout/`, or whether DNSSEC signatures and DKIM email signing validate end to end. Escrito por um agente de IA num ambiente isolado a partir das evidências deste relatório e das páginas que explorou; a nota e as verificações abaixo resultam de testes determinísticos.
Assistente
Pergunte o que quiser sobre este relatório
Exemplo de conversa sobre a padaria fictícia. O seu próprio relatório inclui o assistente.
O meu site foi pirateado?
A nossa verificação foi passiva (analisando apenas a página inicial, as páginas públicas, a segurança do correio e as definições públicas) e não consegue detetar se o seu site foi invadido ou pirateado no passado. Por isso, não podemos garantir que o site está totalmente seguro.
Para tentar perceber se o seu site foi comprometido, existem alguns sinais de alerta que pode verificar por si próprio:
Utilizadores administradores desconhecidos no painel de gestão do seu site.
Páginas novas ou redirecionamentos estranhos que enviam os visitantes para outros sites.
Avisos de segurança no motor de pesquisa (como no Google Search Console) ou alertas vermelhos no navegador ao aceder ao site.
Mensagens de erro invulgares ou alterações no aspeto da página que não autorizou.
Se suspeitar de alguma atividade fora do comum, recomendamos que contacte imediatamente o seu programador web ou o seu fornecedor de alojamento para que possam realizar uma auditoria interna aos ficheiros e à base de dados.
O que devo pedir primeiro à minha agência web?
Para começar a proteger a sua padaria, deve pedir à sua agência web ou programador que trate primeiro das duas correções mais urgentes assinaladas no relatório:
Em primeiro lugar, solicite a atualização imediata do WordPress e de todos os componentes associados. O seu site utiliza o WordPress 6.8, que tem falhas conhecidas, tal como algumas das bibliotecas em uso. Peça-lhes que façam uma cópia de segurança completa, atualizem o sistema e os temas para as versões mais recentes e ativem as atualizações automáticas de segurança.
Em segundo lugar, peça-lhes que colaborem com quem gere o seu e-mail para configurar as regras de proteção de correio eletrónico no seu domínio. Como não tem um registo SPF publicado, qualquer pessoa pode enviar e-mails falsos em seu nome com facilidade. Devem criar um registo SPF e uma política DMARC inicial para proteger a sua marca e os seus clientes contra fraudes.
Enquanto a agência trata destas atualizações técnicas, há algo muito importante que pode e deve fazer por si próprio: aceda à sua entidade de registo de domínio (OVH SAS) para garantir que o seu domínio bakery.example é renovado (pois expira a 25 de Outubro de 2026) e ative a confirmação em dois passos nessa conta e no seu e-mail.
Glossário:
WordPress: O sistema de gestão que a sua agência utilizou para criar e atualizar as páginas do seu site.
Registo SPF: Uma configuração pública que funciona como uma lista de servidores autorizados a enviar e-mails em nome da sua empresa.
Muitos ataques a pequenas empresas começam com uma palavra-passe roubada ou uma fatura falsa, não com o site. Uma verificação passiva não os vê: dedique alguns minutos a cada ponto.
Autenticação em dois passos nas suas contas (MFA)
Ative a autenticação em dois passos nas contas de administração do site, de e-mail, da entidade de registo do domínio e de alojamento. Antes disso, guarde os códigos de recuperação num local seguro e garanta que alguém consegue recuperar o acesso, para não ficar bloqueado.
Pergunte o que é copiado, com que frequência e se é guardada uma cópia separada do site, para que um ataque ou uma eliminação não a consiga atingir. Teste uma restauração numa cópia separada, nunca sobre o site em produção, e registe por escrito quem pode restaurar e como.
Verifique se os seus endereços apareceram numa fuga de dados
O Have I Been Pwned e o XposedOrNot permitem-lhe verificar o seu domínio e receber um alerta gratuito quando endereços desse domínio aparecem numa fuga publicada. Não verificamos isto por si e nunca tratamos dados divulgados. Se aparecer um endereço, mude a palavra-passe e ative o início de sessão em dois passos.
Copie as prioridades, o contexto de alojamento e os passos de correção como uma única tarefa, ou transfira-os em Markdown.
Ler ou copiar as instruções para o agente
Fornecedores que detetámos
Estes indícios vêm dos cabeçalhos recolhidos, do HTML da página inicial e dos registos DNS. Confirme o serviço e os seus acessos antes de alterar definições. O encaminhamento do correio recebido não identifica todos os remetentes de saída.
Cloudflare — Fornecedor de DNS
Cloudflare — Entrega do site
Google Workspace — Correio recebido
WordPress — Software do site
Todas as verificações
Corrigir primeiroMelhorarBomNão confirmado
Ligação segura Em ordem
Certificado de segurança (HTTPS)Bom
O certificado HTTPS é válido: os navegadores mostram uma ligação segura.
Porque é importante
Se o certificado estiver em falta ou for inválido, os navegadores mostram aos seus visitantes o aviso «Não seguro» ou «A sua ligação não é privada», e muitos saem antes de o contactar ou de comprar.
Quem pode corrigir
O seu fornecedor de alojamento ou o seu programador web · detetado aqui: Cloudflare (site), WordPress (site)
O que fazer
Este resultado não exige nenhuma alteração. Mantenha a configuração que funciona e use estes passos para a verificar.
Como verificar a correção
Abra o seu site numa janela privada do navegador: deverá carregar sem aviso e mostrar o cadeado. Depois, execute novamente esta verificação: este ponto deverá aparecer como «Bom».
O certificado é válido e não está perto de expirar.
Porque é importante
Quando o certificado expira, os navegadores bloqueiam os seus visitantes com um aviso de segurança em página inteira, pelo que o seu site fica, na prática, inacessível até ser renovado.
Quem pode corrigir
O seu fornecedor de alojamento (os certificados são normalmente renovados automaticamente) · detetado aqui: Cloudflare (site), WordPress (site)
O que fazer
Este resultado não exige nenhuma alteração. Mantenha a configuração que funciona e use estes passos para a verificar.
Como verificar a correção
Após a renovação, execute novamente esta verificação: a data de expiração deverá ser posterior e este ponto deverá aparecer como «Bom».
O seu site não envia esta definição de proteção (cabeçalho HTTP) aos navegadores.
Porque é importante
Sem HSTS, os navegadores dos seus visitantes podem tentar primeiro a versão não encriptada do seu site, que pode ser intercetada em redes partilhadas, como uma rede Wi-Fi pública.
Quem pode corrigir
O seu fornecedor de alojamento ou o seu programador web · detetado aqui: Cloudflare (site), WordPress (site)
O que fazer
Ative o HSTS apenas quando o HTTPS funcionar de forma fiável em todo o site: os navegadores memorizam-no, mesmo depois de o remover. Peça ao seu fornecedor de alojamento o cabeçalho Strict-Transport-Security, primeiro com uma duração curta (max-age=300, cinco minutos), e aumente-a depois gradualmente até, pelo menos, 180 dias (max-age=15552000), idealmente um ano (max-age=31536000). Só acrescente includeSubDomains ou preload quando todos os subdomínios funcionarem em HTTPS: são difíceis de anular.
Como verificar a correção
Execute novamente esta verificação: este ponto deverá aparecer como «Bom». Depois, confirme que as suas páginas principais continuam a carregar normalmente.
Passos para o fornecedor sugerido
Definir Strict-Transport-Security na Cloudflare
Pré-requisitos
As evidências recolhidas sugerem Cloudflare. Confirme que gere o serviço em causa antes de seguir estes passos.
Confirme que controla a zona Cloudflare, que o proxy está ativo para este nome de anfitrião e que há capacidade disponível para Transform Rules. Guarde os cabeçalhos de resposta e as regras existentes; inspecione regras posteriores que possam sobrepor-se a esta alteração.
Para uma nova implementação de HSTS, confirme primeiro que o HTTPS e a renovação de certificados são fiáveis. Preserve qualquer política existente mais forte. Este teste de cinco minutos exclui subdomínios e preload.
No WordPress, anote os URL atuais do Endereço do WordPress e do Endereço do site, bem como as definições do proxy. Depois da alteração aprovada, verifique a página inicial, a página de início de sessão e os recursos do tema, à procura de ciclos de redirecionamento ou conteúdo misto. Não altere os URL do site nem confie em cabeçalhos reencaminhados sem verificar a configuração do servidor de origem.
Passos
Em Rules → Overview, crie uma Response Header Transform Rule. Substitua YOUR_HOSTNAME na expressão abaixo pelo nome de anfitrião autorizado exato; faça corresponder apenas o HTTPS.
Escolha Set static para Strict-Transport-Security, com o valor max-age=300. Guarde com Save as Draft, reveja a regra exata e obtenha aprovação antes de Deploy. Altere apenas este cabeçalho; não ative a transformação incluída Add security headers.
Match: (http.host eq "YOUR_HOSTNAME" and ssl)
Operation: Set static
Header: Strict-Transport-Security
Value: max-age=300
Verificar a alteração
No nome de anfitrião previsto, verifique exatamente um cabeçalho de resposta Strict-Transport-Security: max-age=300 através de HTTPS. Verifique páginas e recursos representativos, incluindo redirecionamentos e erros controlados, e confirme que os outros nomes de anfitrião não são afetados.
Reversão
Reponha a política anterior, se existia. Para retirar apenas esta nova política do nome de anfitrião, sirva max-age=0 através de HTTPS válido; remover o cabeçalho não limpa o HSTS em cache. Mantenha o HTTPS a funcionar durante todo o período máximo (max-age) anterior. As políticas do domínio principal e o preload exigem tratamento separado.
Isto aplica-se na periferia da rede (edge) da Cloudflare, não na origem. Um servidor de nomes correspondente, por si só, não prova que o proxy está ativo nem que controla a zona. Regras posteriores podem substituir o resultado; o HSTS em cache pode sobreviver a uma reversão.
O seu site não envia esta definição de proteção (cabeçalho HTTP) aos navegadores.
Porque é importante
Uma Content Security Policy (política de segurança de conteúdo) indica aos navegadores que scripts e recursos o seu site pode carregar. Sem ela, código malicioso introduzido no seu site (por exemplo, através de um plugin vulnerável) é executado livremente nos navegadores dos seus visitantes e pode roubar o que estes escrevem.
Quem pode corrigir
O seu programador web · detetado aqui: Cloudflare (site), WordPress (site)
O que fazer
Isto exige cuidado, porque uma política demasiado restritiva pode impedir o seu site de funcionar. Peça ao seu programador que liste os scripts, tipos de letra e serviços que o site utiliza (estatísticas, pagamentos, chat) e que teste depois uma política em modo «report-only» (só relatório), que assinala problemas sem bloquear nada. Passe à aplicação efetiva só quando as suas páginas principais funcionarem e mantenha a definição anterior pronta a repor.
Como verificar a correção
Execute novamente esta verificação: este ponto deverá aparecer como «Bom». Depois, teste as suas páginas principais (formulário de contacto, pagamento, reservas) para garantir que nada deixou de funcionar.
Passos para o fornecedor sugerido
Preparar uma regra CSP de observação na Cloudflare
Pré-requisitos
As evidências recolhidas sugerem Cloudflare. Confirme que gere o serviço em causa antes de seguir estes passos.
Confirme que controla este nome de anfitrião com proxy e que tem capacidade para regras de cabeçalhos de resposta. Registe as políticas aplicadas e Report-Only existentes, incluindo as regras de Client-side security. Não as substitua.
Com o programador, faça o inventário dos recursos necessários e dos percursos essenciais. Use um endpoint de relatórios HTTPS aprovado pelo responsável, com controlo de acessos e retenção limitada; os relatórios podem revelar URLs de páginas.
No WordPress, anote os URL atuais do Endereço do WordPress e do Endereço do site, bem como as definições do proxy. Depois da alteração aprovada, verifique a página inicial, a página de início de sessão e os recursos do tema, à procura de ciclos de redirecionamento ou conteúdo misto. Não altere os URL do site nem confie em cabeçalhos reencaminhados sem verificar a configuração do servidor de origem.
Passos
Em Rules → Overview, prepare uma Response Header Transform Rule que corresponda apenas a este nome de anfitrião exato. Guarde um rascunho; não implemente marcadores de substituição (placeholders).
Adapte o exemplo apenas como política de observação. Se os cabeçalhos já existirem, peça ao respetivo responsável que junte a política e os destinos de relatórios. Reveja a ordem das regras e obtenha aprovação antes da implementação.
Teste os percursos essenciais e inspecione os relatórios recebidos. No WordPress, inclua o início de sessão, o editor, os plugins e qualquer processo de pagamento. Prepare uma política aplicada, revista separadamente, só depois de resolver as violações legítimas.
Verifique os dois cabeçalhos de resposta e a receção de um relatório de violação controlado num navegador compatível. O modo Report-Only não bloqueia recursos e não resolve o resultado deste relatório sobre a falta de uma CSP aplicada.
Reversão
Desative apenas a nova regra de observação ou reponha os cabeçalhos registados; preserve qualquer política aplicada preexistente.
Este é um ponto de partida restritivo para observação, não uma política aplicada. O suporte da Reporting API varia. O DNS na Cloudflare, por si só, não demonstra o controlo da resposta pública.
Alguns cookies não têm Secure, ou um cookie de início de sessão ou de sessão não tem HttpOnly; pergunte para que serve cada um.
Porque é importante
Os cookies podem manter os seus visitantes ou funcionários com a sessão iniciada. Sem o atributo Secure, um cookie pode circular sem encriptação, e sem HttpOnly um código malicioso na página pode lê-lo, o que poderia permitir a alguém apoderar-se de uma sessão.
Quem pode corrigir
O seu programador web · detetado aqui: Cloudflare (site), WordPress (site)
O que fazer
Pergunte ao seu programador para que serve cada cookie. Os cookies de início de sessão e de sessão devem ter Secure e HttpOnly. Alguns cookies, como os de banners de consentimento ou de estatísticas, precisam legitimamente de ser lidos pela página, por isso não os altere todos de uma vez: teste primeiro o início de sessão e as suas integrações, e mantenha uma forma de reverter.
Como verificar a correção
Execute novamente esta verificação e reveja a lista de cookies com o seu programador. Depois, confirme que o início de sessão e as restantes funcionalidades continuam a funcionar.
Ficheiro de contacto de segurança (security.txt)Melhorar
Não estava disponível nenhum ficheiro security.txt na localização padrão.
Porque é importante
Se alguém descobrir um problema de segurança no seu site, um ficheiro security.txt indica-lhe como o contactar. Sem ele, um aviso útil pode nunca lhe chegar ou ir parar à pessoa errada.
Quem pode corrigir
O seu programador web ou quem gere o seu site · detetado aqui: Cloudflare (site), WordPress (site)
O que fazer
Publique um ficheiro de texto simples em /.well-known/security.txt no seu site HTTPS. Precisa de uma linha Contact: com um endereço consultado regularmente (por exemplo, mailto:security@o-seu-dominio.example) e de uma linha Expires: com uma data futura no formato RFC 3339 (como 2027-12-31T23:59:59Z). Crie um lembrete para o atualizar antes dessa data e indique apenas dados de contacto que aceite tornar públicos.
Como verificar a correção
Abra https://o-seu-dominio/.well-known/security.txt num navegador: deverá aparecer o ficheiro de texto com o seu contacto e uma data futura. Depois, execute novamente esta verificação. Se acrescentar uma linha Canonical:, esta tem de incluir esse endereço exato.
Enviar esta correção ao seu programador ou assistente de IA
Encaminhar os visitantes para o site seguro (redirecionamento HTTPS)Bom
Os visitantes que escrevem o endereço sem https:// são encaminhados para o site seguro.
Porque é importante
Os visitantes que escrevem o seu endereço sem «https://» podem ficar numa página não encriptada, onde o que leem ou escrevem (como os dados de um formulário de contacto) pode ser visto ou alterado, por exemplo numa rede Wi-Fi pública.
Quem pode corrigir
O seu fornecedor de alojamento ou o seu programador web · detetado aqui: Cloudflare (site), WordPress (site)
O que fazer
Este resultado não exige nenhuma alteração. Mantenha a configuração que funciona e use estes passos para a verificar.
Como verificar a correção
Numa janela privada, escreva o seu endereço começando por http://: deverá chegar à versão https:// do mesmo endereço. Depois, execute novamente esta verificação: este ponto deverá aparecer como «Bom».
Proteção do tipo de ficheiro (X-Content-Type-Options)Bom
O seu site envia esta definição de proteção aos navegadores.
Porque é importante
Sem esta definição, os navegadores podem adivinhar o tipo de ficheiro que recebem, pelo que um ficheiro enviado ou identificado por engano pode ser executado como código nos navegadores dos seus visitantes.
Quem pode corrigir
O seu programador web ou o seu fornecedor de alojamento · detetado aqui: Cloudflare (site), WordPress (site)
O que fazer
Este resultado não exige nenhuma alteração. Mantenha a configuração que funciona e use estes passos para a verificar.
Como verificar a correção
Execute novamente esta verificação: este ponto deverá aparecer como «Bom». Depois, confirme que as suas páginas mantêm o aspeto e o funcionamento normais.
Remetentes de e-mail autorizados (SPF)Corrigir primeiro
O seu domínio recebe e-mail, mas não publica nenhum registo SPF, pelo que qualquer pessoa pode enviar mais facilmente e-mails que afirmam vir de si.
Porque é importante
O SPF lista os serviços autorizados a enviar e-mail pelo seu domínio. Sem ele, ou com vários registos SPF em conflito, os criminosos podem enviar mais facilmente e-mails em seu nome, e os seus e-mails legítimos têm mais probabilidade de ir parar ao spam.
Quem pode corrigir
O seu administrador de e-mail e quem gere o seu DNS · detetado aqui: Google Workspace (e-mail), Cloudflare (DNS)
O que fazer
Liste todos os serviços que enviam e-mail por si: o seu fornecedor de caixas de correio, mas também formulários do site, newsletters e ferramentas de faturação ou de reservas. Mantenha exatamente um registo SPF que os cubra a todos, usando os valores que cada fornecedor documenta; junte os duplicados num só em vez de acrescentar um segundo registo. Não substitua as entradas existentes por um registo restritivo que «bloqueia tudo», ou os seus e-mails legítimos podem ser rejeitados.
Como verificar a correção
Quando a alteração DNS tiver efeito, execute novamente esta verificação: este ponto deverá aparecer como «Bom». Depois, envie um e-mail de teste a partir de cada serviço e confirme que os cabeçalhos da mensagem recebida mostram spf=pass.
Passos para o fornecedor sugerido
Rever o SPF para o Google Workspace
Pré-requisitos
As evidências recolhidas sugerem Google Workspace. Confirme que gere o serviço em causa antes de seguir estes passos.
Confirme que o Google Workspace envia e-mail em nome deste domínio exato, e não apenas o recebe. Faça o inventário dos formulários do site, newsletters, gateways e todos os outros remetentes. Guarde os registos TXT existentes e os respetivos TTL; preserve os registos MX, DKIM e o restante DNS não relacionado.
Confirme o domínio do remetente de envelope usado pelo SPF e o domínio From visível usado pelo DMARC; podem ser diferentes.
Mantenha exatamente uma política SPF por domínio de envio. Um registo MX de entrada não permite estabelecer a lista completa de remetentes de saída.
Passos
No fornecedor de DNS autoritativo, junte os registos SPF duplicados numa única política revista. O exemplo abaixo serve apenas para uma nova política quando o Google Workspace é o único remetente. Caso contrário, preserve todos os remetentes confirmados e a proteção existente; não substitua o registo às cegas.
Verifique a avaliação SPF completa face ao limite de dez termos que geram consultas DNS, incluindo includes e redirects aninhados. Reveja as diferenças (diff) e obtenha aprovação antes de publicar.
Após a propagação DNS, verifique o valor TXT autoritativo e os resultados de autenticação do servidor recetor para cada serviço de envio.
TXT no domínio de envio SPF:
v=spf1 include:_spf.google.com ~all
Verificar a alteração
Depois de esta alteração se propagar no DNS, use uma mensagem recebida após a alteração numa caixa de correio separada para verificar spf=pass e o domínio de envelope avaliado para cada remetente. Confirme que existe exatamente uma política publicada e que as consultas DNS se comportam de forma válida. As mensagens anteriores servem apenas de referência; um registo DNS, por si só, não prova a entrega na caixa de entrada.
Reversão
Reponha a política SPF guardada enquanto corrige as autorizações, preservando o DNS não relacionado. Os registos em cache atrasam o efeito; volte a verificar mensagens reais de todos os remetentes.
O SPF verifica o domínio de envelope e pode falhar após um reencaminhamento. Não herda automaticamente a política de um domínio principal. Um domínio do fornecedor que passe na verificação não fica, por si só, alinhado com o seu endereço From visível.
Proteção contra a usurpação de e-mail (DMARC)Melhorar
A sua política DMARC é «p=none»: assinala os e-mails falsos, mas continua a deixá-los passar. Depois de analisar os seus relatórios, passe para «p=quarantine» e, em seguida, para «p=reject».
Porque é importante
Sem uma política DMARC, os criminosos podem enviar mais facilmente e-mails que parecem vir da sua empresa, e os fornecedores de correio eletrónico não têm nenhuma instrução para os bloquear. Se existirem vários registos DMARC, nenhum é aplicado.
Quem pode corrigir
O seu administrador de e-mail e quem gere o seu DNS · detetado aqui: Google Workspace (e-mail), Cloudflare (DNS)
O que fazer
Configure primeiro o SPF e o DKIM para todos os serviços que enviam e-mail por si. Depois, publique um único registo DMARC (_dmarc.o-seu-dominio) com p=none e um endereço de relatórios consultado regularmente: monitoriza sem bloquear. Após algumas semanas de relatórios sem problemas, passe gradualmente para p=quarantine e depois para p=reject; tornar a política restritiva cedo demais pode bloquear os seus próprios e-mails.
Como verificar a correção
Quando a alteração DNS tiver efeito, execute novamente esta verificação: este ponto aparece como «Bom» quando a política for p=quarantine ou p=reject. Depois, confirme nos relatórios DMARC que os seus e-mails legítimos passam.
Passos para o fornecedor sugerido
Rever o DMARC para o Google Workspace
Pré-requisitos
As evidências recolhidas sugerem Google Workspace. Confirme que gere o serviço em causa antes de seguir estes passos.
Confirme que o Google Workspace envia e-mail em nome deste domínio exato, e não apenas o recebe. Faça o inventário dos formulários do site, newsletters, gateways e todos os outros remetentes. Guarde os registos TXT existentes e os respetivos TTL; preserve os registos MX, DKIM e o restante DNS não relacionado.
Confirme o domínio do remetente de envelope usado pelo SPF e o domínio From visível usado pelo DMARC; podem ser diferentes.
Verifique a política DMARC aplicável do domínio principal e o alinhamento SPF/DKIM dos remetentes legítimos antes de alterar a política. Combine uma caixa de correio para relatórios agregados que pertença ao operador ou seja aprovada por ele; não invente uma.
Inspecione a assinatura DKIM atual antes de alterar chaves. A ausência de resposta para um seletor comum não prova que o DKIM esteja ausente. Mantenha ativos os seletores e a assinatura que funcionam; um alias de caixa de correio não estabelece o domínio de assinatura.
Passos
Em Google Admin → Apps → Google Workspace → Gmail → Authenticate email (na consola em português: Aplicações → Google Workspace → Gmail → Autenticar email), selecione o domínio de envio exato. Apenas para uma nova configuração, peça a um superadministrador que gere uma chave de 2048 bits, se o DNS o suportar, com um seletor não utilizado. Copie o nome e o valor TXT completos indicados pela Google; preserve uma chave existente que funcione.
Publique esse TXT exato no fornecedor de DNS autoritativo, verificando se este acrescenta o domínio automaticamente. Depois, escolha Start authentication (Iniciar autenticação) e confirme que aparece Authenticating email with DKIM. Num Gmail recém-ativado, pode ser preciso esperar 24 a 72 horas antes de gerar a chave; o DNS e a autenticação podem demorar 48 horas.
Após a propagação e a ativação, envie um novo teste autorizado a partir de cada serviço e endereço From para uma caixa de correio externa separada que controle. Procure dkim=pass no Authentication-Results do recetor e, no DKIM-Signature, o domínio d= e o seletor s= reais; verifique o alinhamento com o From visível. Outro alias da mesma caixa de correio e mensagens mais antigas não provam o resultado da alteração.
No fornecedor de DNS autoritativo, consolide as políticas TXT _dmarc duplicadas numa única política aprovada pelo responsável. Preserve uma política mais forte já estabelecida; o exemplo abaixo serve apenas para uma nova implementação em modo de monitorização.
Substitua YOUR_APPROVED_REPORT_ADDRESS pela caixa de correio combinada e depois reveja e aprove as diferenças (diff) no DNS. Destinos de relatórios externos exigem autorização do destinatário no DNS. Não acrescente relatórios forenses por predefinição.
No Google Workspace, aguarde pelo menos 48 horas após configurar o SPF/DKIM antes do DMARC e monitorize depois durante cerca de uma semana. Reveja cada fluxo de envio legítimo antes de passar gradualmente para quarantine e reject.
TXT em _dmarc.YOUR_MAIL_DOMAIN:
v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_ADDRESS
Verificar a alteração
Depois de esta alteração se propagar no DNS, verifique que existe exatamente uma política DMARC aplicável, SPF ou DKIM alinhado, dmarc=pass nos resultados de autenticação de uma mensagem recebida após a alteração e relatórios agregados utilizáveis que cubram a política alterada. As mensagens anteriores servem apenas de referência. p=none monitoriza; não impõe a rejeição.
Reversão
Reponha a política anterior aprovada pelo responsável, normalmente p=none durante uma nova implementação, enquanto corrige o alinhamento. Preserve o SPF/DKIM que funciona. As caches DNS atrasam a reversão e as mensagens rejeitadas não são recuperadas automaticamente. Mantenha as chaves TXT DKIM durante a investigação; a Google aconselha mantê-las depois de parar a assinatura e esperar pelo menos quatro dias antes de remover um registo recém-adicionado. Não volte a gerar uma chave que funciona como forma de reversão.
Estes passos exigem o seu administrador de e-mail e não inspecionam as definições do inquilino (tenant). Os registos MX de entrada não estabelecem os remetentes de saída. Um registo DNS ou a ausência de um seletor comum não provam nem a assinatura ativa nem a sua ausência; verifique mensagens realmente recebidas.
Estão publicados registos MX. Os respetivos destinos, a disponibilidade e a entrega nas caixas de correio não foram testados.
Porque é importante
Os registos MX indicam aos outros servidores de e-mail para onde entregar o e-mail do seu domínio. Se estiverem errados ou forem contraditórios, os e-mails dos seus clientes podem ser devolvidos ou perder-se. Um endereço web que não é usado para e-mail pode, legitimamente, não ter nenhum.
Quem pode corrigir
O seu fornecedor de e-mail, ou quem gere o DNS do seu domínio · detetado aqui: Google Workspace (e-mail), Cloudflare (DNS)
O que fazer
Este resultado não exige nenhuma alteração. Mantenha a configuração que funciona e use estes passos para a verificar.
Como verificar a correção
Quando a alteração DNS tiver efeito, execute novamente esta verificação. Depois, à parte, envie um e-mail de teste para a sua própria caixa de correio e a partir dela, para confirmar a entrega.
Foi encontrada uma possível chave num seletor comum. A assinatura das mensagens e a validade da chave não foram testadas.
Porque é importante
O DKIM acrescenta uma assinatura digital aos seus e-mails para que os destinatários possam confirmar que vêm mesmo da sua empresa e que não foram alterados. Sem ele, os seus e-mails têm mais probabilidade de ir parar ao spam e o DMARC protege pior o seu domínio.
Quem pode corrigir
O seu administrador de e-mail · detetado aqui: Google Workspace (e-mail), Cloudflare (DNS)
O que fazer
Este resultado não exige nenhuma alteração. Mantenha a configuração que funciona e use estes passos para a verificar.
Como verificar a correção
Quando o DKIM estiver ativado e a alteração DNS tiver efeito, envie um novo e-mail para um endereço externo que controle (não um alias nem um colega). Nos cabeçalhos da mensagem recebida, procure dkim=pass e anote os valores d= e s= em DKIM-Signature: s= é o seletor a consultar no DNS.
Está publicado um registo DS; as assinaturas DNSSEC e a cadeia de confiança não foram validadas.
Porque é importante
O DNSSEC assina digitalmente as respostas DNS do seu domínio, o que dificulta que atacantes encaminhem os seus visitantes ou o seu e-mail para um servidor falso. É uma camada extra de proteção e não um requisito básico.
Quem pode corrigir
Quem gere o DNS do seu domínio, em conjunto com a entidade de registo do domínio · detetado aqui: Cloudflare (DNS)
O que fazer
O DNSSEC parece estar ativo: a sua entidade de registo publica o respetivo elo (registo DS). Não há nada a alterar. Se mudar o seu DNS para outro fornecedor, peça primeiro aos dois fornecedores que planeiem em conjunto a mudança do DNSSEC.
Como verificar a correção
Peça ao seu fornecedor de DNS que confirme que o DNSSEC é validado corretamente de ponta a ponta. Esta verificação pode mostrar que o DNSSEC está publicado, não que funciona.
Enviar esta correção ao seu programador ou assistente de IA
Foram publicados registos CAA neste nome de anfitrião. As suas restrições e o seu tratamento pelos fornecedores de certificados não foram avaliados.
Porque é importante
Um registo CAA indica que organizações podem emitir certificados HTTPS para o seu domínio, o que torna mais difícil obter um certificado fraudulento. É opcional, e um registo errado pode impedir a renovação do seu próprio certificado.
Quem pode corrigir
Quem gere o seu DNS, em conjunto com o seu fornecedor de alojamento · detetado aqui: Cloudflare (DNS)
O que fazer
Este resultado não exige nenhuma alteração. Mantenha a configuração que funciona e use estes passos para a verificar.
Como verificar a correção
Peça ao seu fornecedor de alojamento que confirme as regras CAA em vigor, incluindo as herdadas do seu domínio principal ou de aliases, e que o certificado do seu site continua a poder ser renovado.
Lidas a partir da mesma resposta da página inicial, mais a lista de sites perigosos da Google, com correções para a sua plataforma. Ainda não contam para a nota.
Não assinalado como perigoso pela GoogleBom
Porque é importante
Se a Google indicasse o seu site como perigoso, os navegadores avisariam os seus visitantes.
A Google não pode garantir que as suas informações sejam completas e isentas de erros: alguns sites perigosos podem não ser identificados e alguns sites seguros podem ser identificados por engano.
Domínio renovado com antecedência e bloqueado contra transferênciasMelhorar
Porque é importante
O seu domínio tem de ser renovado até 25 de Outubro de 2026. Se expirar, o seu site e o email deixam de funcionar e outra pessoa pode comprar o nome. Sem bloqueio de transferência, alguém que entre na sua conta da entidade de registo, ou a engane, pode transferir o seu domínio para outra empresa com mais facilidade.
O que vimos
renovação até 25 de Outubro de 2026 · sem bloqueio de transferência · entidade de registo: OVH SAS
Como corrigir
Inicie sessão na sua entidade de registo e confirme que a renovação automática está ativa e o cartão de pagamento é válido, ou renove já. No painel da sua entidade de registo, ative o bloqueio de transferência (também chamado registrar lock ou proteção de transferência), se estiver disponível.
Formulários e conteúdos da página em HTTPSMelhorar
Porque é importante
Imagens ou conteúdos multimédia da sua página inicial usam endereços http:// não cifrados: os navegadores tentam https:// em alternativa e descartam-nos se falhar, pelo que podem não aparecer.
O que vimos
Imagens ou multimédia por http://: 1
Como corrigir
No WordPress, defina os dois endereços em Definições → Geral como https:// e substitua as antigas ligações http:// com um plugin de pesquisar e substituir (faça antes uma cópia de segurança).
Nenhuma biblioteca do site com falhas conhecidasMelhorar
Porque é importante
As versões antigas destas bibliotecas têm falhas publicamente conhecidas que os atacantes podem usar contra os seus visitantes, por exemplo para executar os seus próprios scripts nas suas páginas.
O que vimos
jQuery 1.12.4 (CVE-2020-11022)
Como corrigir
Atualize o WordPress, o tema e os plugins; uma biblioteca antiga vem normalmente de um tema ou plugin desatualizado. Peça ao seu programador que remova ou atualize o que restar.
Versão do WordPress sem falhas conhecidasMelhorar
Porque é importante
Esta versão do WordPress tem falhas de segurança publicamente conhecidas que os atacantes procuram automaticamente.
O que vimos
WordPress 6.8 · mais recente 7.1.3
Como corrigir
Faça uma cópia de segurança e, no WordPress, vá a Painel → Atualizações e instale a versão mais recente; ative as atualizações automáticas. Se uma agência criou o seu site, peça-lhe que o faça.
Proteção contra incorporação ocultaMelhorar
Porque é importante
Sem ela, outro site pode mostrar as suas páginas dentro de uma moldura invisível e levar os visitantes a clicar em botões que não conseguem ver (clickjacking).
Como corrigir
No Cloudflare, adicione uma Transform Rule de cabeçalho de resposta X-Frame-Options: SAMEORIGIN.
Limites à câmara, ao microfone e à localizaçãoMelhorar
Porque é importante
Uma Permissions-Policy impede que os scripts das suas páginas, incluindo os de terceiros, peçam acesso à câmara, ao microfone ou à localização.
Como corrigir
No Cloudflare, adicione uma Transform Rule Permissions-Policy: camera=(), microphone=(), geolocation=().
Versões de software mantidas privadasMelhorar
Porque é importante
Os números de versão visíveis indicam aos atacantes exatamente que falhas conhecidas devem tentar.
O que vimos
WordPress 6.8
Como corrigir
Mantenha o WordPress e os respetivos plugins atualizados automaticamente e oculte a versão com o seu plugin de segurança.
Endereços de páginas privadas mantidos privadosBom
Porque é importante
Uma Referrer-Policy insegura envia os endereços completos das páginas, que podem incluir ligações privadas ou tokens, a todos os sites para onde as suas páginas têm ligações. Sem ela, os navegadores utilizam um valor predefinido seguro.
Com o seu consentimento, o Google Analytics mede a forma como os visitantes utilizam as nossas páginas públicas, para que as possamos melhorar. As verificações, os relatórios e as páginas de conta nunca o carregam. Nada é carregado antes da sua escolha, e pode alterá-la em qualquer momento em Definições de cookies, no rodapé. Privacidade e cookies
Fmind