Ataque hacker: Como proteger os sites dos clientes da sua agência

March 29, 2022
0 minute read

Ataques hackers, ciberataques e cibercrimes já são considerados a maior ameaça para empresas em todo o mundo. 


Em média,
30 mil sites sofrem ataques hacker todos os dias. 


A situação piorou muito durante a pandemia de Covid-19, quando muitas atividades migraram do presencial para o online. 


Apenas em 2020, no início da crise sanitária, o FBI identificou um
aumento de 300% no número de crimes cibernéticos.


Alguns dos clientes da sua agência podem pensar que o site deles não tem nada a ver com isso. 


Muitas pequenas empresas acham que seu site não possui nada que valha a pena ser hackeado. Isso não é verdade. 


Qualquer site é um
ativo valioso para o seu proprietário e para seus usuários. E também para os hackers. 


Cabe a você alertar seus clientes para a dimensão e a gravidade do problema. 


Esse artigo vai ajudá-lo a fazer isso. Vamos desconstruir alguns mitos, trazer números, falar sobre os principais tipos de ataques hacker e apresentar dicas de como proteger os sites dos seus clientes. 

Por que cada vez mais sites são hackeados?

Ao contrário do que muita gente pensa, um site pequeno não está imune a ataques maliciosos. Sem os devidos cuidados, os sites de profissionais liberais ou de pequenas empresas que a sua agência construiu podem ser as próximas vítimas. 

Isso porque a grande maioria das violações de segurança em sites não é dirigida para uma empresa ou site em particular. O que os hackers fazem hoje é utilizar ferramentas automatizadas para varrer uma grande quantidade de sites e buscar vulnerabilidades. Elas podem estar no CMS, plugin ou template. 

Hackear sites usando ferramentas automáticas é popular porque os hackers podem lançar um amplo ataque com pouco esforço. Muitos exploram uma vulnerabilidade em uma versão específica do WordPress, Joomla ou outro sistema de gerenciamento de conteúdo. 

Bots automatizados buscam sites usando essa versão. Depois, invadem a máquina dos usuários desses sites para coletar dados pessoais, que são revendidos na Deep Web.

Segundo a empresa de segurança Trustwave, a renda mensal de um hacker pode chegar a R$ 265 mil.

Website, um ativo valioso

Mesmo que o ganho monetário direto do hacker com cada site invadido não seja alto, o grande volume de sites hackeados, a rapidez e a facilidade dos ataques faz com que eles sejam rentáveis. 


O hacker pode lucrar com a venda de informações ou com a utilização dos recursos do servidor do site ou da empresa invadida. 


Outra modalidade de ataque que vem se popularizando no Brasil é o roubo ou sequestro de domínio. No site Registro.br, o hacker pode facilmente ter acesso ao e-mail do proprietário do domínio, já que este banco de dados é público. 


O e-mail então é hackeado e a propriedade do registro é alterada. Os ladrões podem entrar em contato pedindo um resgate, desviar o tráfego para outros sites ou usá-lo para ganhar com anúncios que pagam por clique. Empresas e organizações dos mais diversos tipos e tamanhos são alvo. 


Ou seja, os tempos em que os ataques de hackers eram incomuns e só aconteciam com grandes empresas acabaram. Em vez disso, hackear sites de pequenas e médias empresas tornou-se um ambiente lucrativo para muitas pessoas com algum conhecimento de tecnologia.

Um ataque hacker a cada 39 segundos e outras estatísticas

Alguns números mostram o tamanho da ameaça que representam os ataques hackers:

Essas estatísticas dão uma ideia de como fica mais difícil garantir a segurança dos sites dos seus clientes a cada ano que passa. Qualquer software pode ser hackeado se você não implantar medidas de segurança e seguir as práticas recomendadas.

Conforme a Internet se desenvolve e gera mais recursos para usuários e empresas, como a possibilidade de armazenar enormes quantidades de dados valiosos, os hackers também acessam técnicas mais robustas.

Gráfico tipos de vulnerabilidades aos ataques hacker

Principais tipos de ataque hacker

Todos os dias surgem notícias sobre novas vulnerabilidades que foram descobertas e deixaram milhões de sites expostos a ataques hacker. 

No caso de sites WordPress, dados do WPScan sobre as vulnerabilidades mais exploradas pelos hackers indicam Cross-site Scripting (XSS) e injeção de SQL. Elas respondem por mais da metade de todas as invasões. 

Segundo a Patchstack, ferramenta de proteção de sites WordPress, XSS é a técnica de hacking de sites mais comum para WordPress.

Já o último levantamento da Accenture sobre o custo do cibercrime no mundo aponta que os ataques hackers que geram maiores prejuízos são os malwares. A seguir veremos o que significam algumas dessas expressões.

1. Cross-site Scripting (XSS)

Os ataques de XSS visam o código de uma página da web que é executado no navegador do usuário, ao invés de no servidor. O hacker insere scripts maliciosos no navegador desses usuários. 

A maioria tem como objetivo coletar dados pessoais, redirecionar as vítimas para sites controlados pelo hacker ou fazer com que o computador do usuário execute operações comandadas pelo atacante.

2. Injeção de SQL

A maioria dos sites usa Structured Query Language (SQL) para interagir com bancos de dados. O SQL permite que o site crie, recupere, atualize e exclua registros do banco de dados. Ele é usado para tudo, desde o login de um usuário no site até o armazenamento de detalhes de uma transação de comércio eletrônico.

Nesse tipo de ataque oculto, o cibercriminoso insere um código SQL malicioso para violar as medidas de segurança e acessar dados protegidos. Uma vez instalado, ele pode controlar o banco de dados do site e sequestrar informações dos usuários.

3. Malware

Malware é um termo genérico para qualquer tipo de “malicious software” (“software malicioso”). Eles são projetados para se infiltrar no dispositivo do visitante do site sem o conhecimento dele. Podem causar prejuízos, danificar sistemas, interceptar dados ou simplesmente irritar o usuário. 

Adware, spyware, vírus, botnets, cavalos de Troia, worms, rootkits e ransomware - todos se enquadram na definição de malware. Independentemente do tipo, todo malware segue o mesmo padrão básico: o usuário, sem querer, baixa ou instala o malware, que infecta o dispositivo.

O site tem seu SEO prejudicado e pode ser removido dos resultados da busca do Google se estiver infectado.

4. Ataque DDoS

Um ataque DDoS pode travar completamente o site ou torná-lo extremamente lento. Isso acontece por meio de uma rede — chamada de zumbi — com computadores que já estão infectados e se conectam ao hacker mestre. 

O uso de uma CDN (Rede de Entrega de Conteúdo) configurada corretamente pode melhorar a segurança do site e evitar esse tipo de ataque. 

5. Exploração de vulnerabilidades ou port scanning attack

Nesse tipo de malware, os hackers usam brechas para obter acesso ao site. Um bom exemplo são os plugins instalados em sites WordPress e que se encontram desatualizados. 

Caso encontre alguma vulnerabilidade no sistema, o malware informa a “porta” disponível. O hacker pode então acessar todos os arquivos no servidor.

6. Defacement

Imagine essa situação: você está navegando tranquilamente pela internet e, quando acessa o site de um dos clientes da sua agência, depara-se com uma página inicial diferente. Em vez do conteúdo, encontro uma mensagem indicando que o site foi invadido. Ou propaganda de viagra. 

É isso que os especialistas chamam de defacement ou deface. Ocorre quando o hacker substitui o conteúdo do site por conteúdo malicioso. O mais comum é que o invasor não acesse a base de dados nem derrube o servidor ou sequestre as máquinas responsáveis. Mas os prejuízos para a imagem da marca e a credibilidade da empresa são grandes.

O que acontece com um site invadido

Alguns sinais de que um site pode ter sofrido um ataque hacker são:

  • O navegador mostra sinais de atividades suspeitas ou telas de aviso indicando que o site foi vítima de um ataque de phishing
  • O servidor tira o site do ar
  • O Google Search Console indica que o site pode ter sido invadido
  • O site fica mais lento que o normal
  • Os emails do domínio da empresa passam a ser classificados como spam
  • O site apresenta redirects, pop ups ou anúncios indesejados

As invasões podem causar danos graves ao proprietário do site. No caso de lojas virtuais ou sites com cadastro de newsletter, o hacker pode roubar nomes e emails dos usuários. Muitas vezes, essas informações são vendidas e podem servir para outros ataques e invasões em outras contas dessas mesmas pessoas. 

Podem ocorrer também danos financeiros diretos como a venda e envio de produtos por preços menores ou por meio de pagamentos com cartões roubados. Em alguns casos, as informações da vulnerabilidade do ambiente ou do controle de pagamentos são divulgadas em grupos e comunidades do crime digital e são realizadas dezenas ou até centenas de ataques. 

Ter um site ainda invadido prejudica a imagem da empresa, pode resultar em um site fora do ar ou fora dos mecanismos de busca. Por fim, é responsabilidade do proprietário do site proteger os dados e as identidades dos seus usuários. 

5 dicas essenciais para proteger os sites dos seus clientes

Ver uma longa lista de medidas de segurança para proteger sites de hackers pode ser assustador e desanimador. O mais importante é ter consciência da dimensão do problema e agir de forma preventiva. 

Comece com as ações abaixo para oferecer uma proteção básica para os sites dos clientes da sua agência. 

1. Preze pela segurança na hospedagem dos sites

Uma boa hospedagem é fundamental para garantir que os sites não fiquem fora do ar e para protegê-los de ataques hacker. Inclua nos pacotes backups e recuperação. Caso os sites dos seus clientes sejam atacados, você poderá retomar a última versão. Custa muito menos do que perder negócios ou ter que consertar os sites. 

2. Instale certificados SSL

O certificado Secure Sockets Layer (SSL) é um protocolo de segurança que criptografa todas as comunicações de e para um site. A instalação de um garantirá que, mesmo que um hacker intercepte dados do seu site, eles nunca serão capazes de entender o que são esses dados.

3. Atualize os sistemas


Mais de 90% dos hacks em sites WordPress ocorrem porque os hackers identificaram uma vulnerabilidade em um tema ou plugin e a exploraram em vários sites.


Quando as vulnerabilidades são descobertas, principalmente por pesquisadores de segurança, elas são divulgadas ao desenvolvedor do plugin para correções. Os desenvolvedores responsáveis ​​lançarão uma correção e os sites com o plug-in instalado verão que uma versão atualizada do plugin estará disponível em breve.


Assim que a correção for lançada, a vulnerabilidade será divulgada publicamente. Se você foi um dos sites que atualizou o plugin ou tema com a correção de segurança, isso é excelente. Caso contrário, seu site se tornará alvo de hackers amadores (chamados de script kiddies) que desejam ganhar dinheiro rápido.

Portanto, é sempre melhor manter tudo – do WordPress aos plugins – atualizado o tempo todo. Também é importante ficar atento na hora de escolher os plugins. Alguns desenvolvedores simplesmente "aposentam" o plugin e não dão mais manutenção, ficando a cargo do dono do site achar outra solução ou viver com o problema.

4. Faça backups frequentemente

Fazer backups é possivelmente uma das táticas mais subestimadas que você pode aplicar. Sempre faça backups diários para que você possa restaurar rapidamente um site no caso de uma falha catastrófica.

Escolha um bom plugin de backup que seja confiável, porque os backups manuais são difíceis de executar corretamente sem um conhecimento considerável.

5. Não utilize senhas fracas e altera-as frequentemente

Muitos sites construídos com WordPress são invadidos simplesmente porque a senha é fraca. Os hackers têm listas dessas senhas e as utilizam para lançar ataques de força bruta conhecidos como "ataque dicionário".

The State of WordPress Security in 2021

Desafios na segurança de sites WordPress


Entendemos que não é nada fácil executar a lista acima. Entretanto, essas ações são fundamentais, especialmente para sites construídos em WordPress. 

A popularidade do WordPress e o fato de ser uma plataforma de código aberto faz com que seja o alvo preferido dos hackers para a invasão de websites. Sem configuração correta, atualização e correção de plugins, a questão não é "se" o site do seu cliente será invadido, mas "quando". 

Por isso, mesmo alguns dos maiores amantes e defensores da plataforma open source questionam se ela é a solução adequada para todos os tipos de site. 

"Eu amo o WordPress. Mas ele demanda muito trabalho para funcionar com eficiência", conta Thomas Rudy, co-fundador do estúdio de criação de conteúdo americano Ten Twenty Seven

Nesse artigo, Rudy conta porque prefere usar a Duda ao invés do WordPress para construir sites para pequenos negócios

Segundo o desenvolvedor e sócio da agência, para usar o WordPress de forma eficaz, você deve considerar o seguinte:

  • Hospedagem — Embora não seja necessariamente difícil hospedar um site WordPress, você pode facilmente comprometer o desempenho se optar por um plano de hospedagem compartilhada. Ou o custo pode ser significativamente maior para um serviço gerenciado.
  • Atualizações — Ao trabalhar com organizações maiores, as atualizações acontecem regularmente. O código está sendo enviado, sua versão é controlada e você tem funcionários atualizando continuamente os plugins, o núcleo do WordPress e, geralmente, prestando mais atenção ao site. Para organizações menores e empresas locais, nada disso é econômico – ou às vezes até acessível.
  • Segurança — Rudy conta que viu inúmeros sites de negócios locais ao longo dos anos vendendo Viagra sem saber ao longo dos anos. Os sites mais comprometidos são sites WordPress de negócios locais que ficaram inativos por anos.
  • Controle de versão – É muito difícil ter uma estratégia adequada de controle de versão implementada. Um clique errado de alguém usando o FileZilla pela primeira vez e adeus site.

"Para o site de uma empresa grande, o WordPress faz sentido, já que você tem uma equipe ou pelo menos um indivíduo dedicado a mitigar esses desafios. Para sites de pequenas e médias empresas, esse quase nunca é o caso. E aí coisas podem dar errado muito rapidamente ou o potencial de otimizar o site de clientes locais nunca é totalmente realizado", explica o co-fundador da agência. 

Como a Duda protege os sites de ataques hacker 


Um dos grandes diferenciais da Duda é garantir praticamente todas as boas práticas de segurança que vimos acima de forma automática. A plataforma é especializada na criação de sites em escala e é usada por mais de 18 mil agências e plataformas SaaS em todo o mundo. 

Todos os websites da Duda são hospedados na Amazon Web Services (AWS), uma das soluções na nuvem mais confiáveis e seguras do segmento. Não há limitações de largura banda ou armazenamento. Os clientes Duda também contam com criptografia SSL que é renovada automaticamente para todos os sites criados na plataforma. 

Mas o que isso significa na prática? 

  • Hospedagem — Está inclusa na plataforma. Quando você estiver pronto para lançar um site, basta ajustar algumas configurações do servidor para o seu domínio – ou se você comprar seu domínio pela plataforma da Duda, isso é feito para você.
  • Atualizações — A equipe de engenharia da Duda está constantemente atualizando a plataforma. Como usuário, você não precisará se preocupar em atualizar para a versão mais recente. Toda atualização feita é 100% compatível com o código anterior, sem a necessidade de controles paralelos. Além disso, estamos sempre melhorando a plataforma para aspectos cruciais de SEO, como Core Web Vitals.
  • Segurança – Os certificados SSL estão incluídos em todos os websites responsivos da Duda e são instalados automaticamente quando o site é publicado. 
  • Controle de versão — Você pode desfazer ou refazer rapidamente edições no site durante a edição e antes de publicar ou republicar. 

Por isso, a Duda pode ajudar a sua agência a oferecer sites seguros e confiáveis, reduzindo os problemas com vulnerabilidades de segurança, atualizações de plugins e manutenções tediosas de infraestrutura. A plataforma é estável, segura e transparente. 

Você ainda não conhece a Duda? Faça um teste grátis agora ou agende uma conversa com um dos nossos especialistas.


Did you find this article interesting?


Thanks for the feedback!
By Shawn Davis April 16, 2026
Website builder analysed 69M AI crawler visits across over 850,000 websites in February 2026 to determine key trends and characteristics that increase local AEO
By Shawn Davis April 1, 2026
Core Web Vitals aren't new, Google introduced them in 2020 and made them a ranking factor in 2021. But the questions keep coming, because the metrics keep changing and the stakes keep rising. Reddit's SEO communities were still debating their impact as recently as January 2026, and for good reason: most agencies still don't have a clear, repeatable way to measure, diagnose, and fix them for clients. This guide cuts through the noise. Here's what Core Web Vitals actually measure, what good scores look like today, and how to improve them—without needing a dedicated performance engineer on every project. What Core Web Vitals measure Google evaluates three user experience signals to determine whether a page feels fast, stable, and responsive: Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element on a page — usually a hero image or headline — to load. Google considers anything under 2.5 seconds good. Above 4 seconds is poor. Interaction to Next Paint (INP) replaced First Input Delay (FID) in March 2024. Where FID measures the delay before a user's first click is registered, INP tracks the full responsiveness of every interaction across the page session. A good INP score is under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability — how much page elements unexpectedly move while content loads. A score below 0.1 is good. Higher scores signal that images, ads, or embeds are pushing content around after load, which frustrates users and tanks conversions. These three metrics are a subset of Google's broader Page Experience signals, which also include HTTPS, safe browsing, and mobile usability. Core Web Vitals are the ones you can most directly control and improve. Why your clients' scores may still be poor Core Web Vitals scores vary dramatically by platform, hosting, and how a site was built. Some of the most common culprits agencies encounter: Heavy above-the-fold content . A homepage with an autoplay video, a full-width image slider, and a chat widget loading simultaneously will fail LCP every time. The browser has to resolve all of those resources before it can paint the largest element. Unstable image dimensions . When an image loads without defined width and height attributes, the browser doesn't reserve space for it. It renders the surrounding text, then jumps it down when the image appears. That jump is CLS. Third-party scripts blocking the main thread . Analytics pixels, ad tags, and live chat tools run on the browser's main thread. When they stack up, every click and tap has to wait in line — driving INP scores up. A single slow third-party script can push an otherwise clean site into "needs improvement" territory. Too many web fonts . Each font family and weight is a separate network request. A page loading four font files before rendering any text will fail LCP, especially on mobile connections. Unoptimized images . JPEGs and PNGs served at full resolution, without compression or modern formats like WebP or AVIF, add unnecessary weight to every page load. How to measure them accurately There are two types of Core Web Vitals data you should be looking at for every client: Lab data comes from tools like Google PageSpeed Insights, Lighthouse, and WebPageTest. It simulates page loads in controlled conditions. Lab data is useful for diagnosing specific issues and testing fixes before you deploy them. Field data (also called Real User Monitoring, or RUM) comes from actual users visiting the site. Google collects this through the Chrome User Experience Report (CrUX) and surfaces it in Search Console and PageSpeed Insights. Field data is what Google actually uses as a ranking signal — and it often looks worse than lab data because it reflects real-world device and connection variability. If your client's site has enough traffic, you'll see field data in Search Console under Core Web Vitals. This is your baseline. Lab data helps you understand why the scores are what they are. For clients with low traffic who don't have enough field data to appear in CrUX, you'll be working primarily with lab scores. Set that expectation early so clients understand that improvements may not immediately show up in Search Console. Practical fixes that move the needle Fix LCP: get the hero image loading first The single most effective LCP improvement is adding fetchpriority="high" to the hero image tag. This tells the browser to prioritize that resource over everything else. If you're using a background CSS image for the hero, switch it to anelement — background images aren't discoverable by the browser's preload scanner. Also check whether your hosting serves images through a CDN with caching. Edge delivery dramatically reduces the time-to-first-byte, which feeds directly into LCP. Fix CLS: define dimensions for every media element Every image, video, and ad slot on the page needs explicit width and height attributes in the HTML. If you're using responsive CSS, you can still define the aspect ratio with aspect-ratio in CSS while leaving the actual size fluid. The key is giving the browser enough information to reserve space before the asset loads. Avoid inserting content above existing content after page load. This is common with cookie banners, sticky headers that change height, and dynamically loaded ad units. If you need to show these, anchor them to fixed positions so they don't push content around. Fix INP: reduce what's competing for the main thread Audit third-party scripts and defer or remove anything that isn't essential. Tools like WebPageTest's waterfall view or Chrome DevTools Performance panel show you exactly which scripts are blocking the main thread and for how long. Load chat widgets, analytics, and ad tags asynchronously and after the page's critical path has resolved. For most clients, moving non-essential scripts to load after the DOMContentLoaded event is a meaningful INP improvement with no visible impact on the user experience. For websites with heavy JavaScript — particularly those built on frameworks with large client-side bundles — consider breaking up long tasks into smaller chunks using the browser's Scheduler API or simply splitting components so the main thread isn't locked for more than 50 milliseconds at a stretch. What platforms handle automatically One of the practical advantages of building on a platform optimized for performance is that many of these fixes are applied by default. Duda, for example, automatically serves WebP images, lazy loads below-the-fold content, minifies CSS, and uses efficient cache policies for static assets. As of May 2025, 82% of sites built on Duda pass all three Core Web Vitals metrics — the highest recorded pass rate among major website platforms. That baseline matters when you're managing dozens or hundreds of client sites. It means you're starting each project close to or at a passing score, rather than diagnosing and patching a broken foundation. How much do Core Web Vitals actually affect rankings? Honestly, they're a tiebreaker — not a primary signal. Google has been clear that content quality and relevance still dominate ranking decisions. A well-optimized site with thin, irrelevant content won't outrank a content-rich competitor just because its CLS is 0.05. What Core Web Vitals do affect is the user experience that supports those rankings. Pages with poor LCP scores have measurably higher bounce rates. Sites with high CLS lose users mid-session. Those behavioral signals — time on page, return visits, conversions — are things search engines can observe and incorporate. The practical argument for fixing Core Web Vitals isn't just "because Google said so." It's that faster, more stable pages convert better. Every second of LCP improvement can reduce bounce rates by 15–20% depending on the industry and device mix. For client sites that monetize through leads or eCommerce, that's a revenue argument, not just an SEO argument. A repeatable process for agencies Audit every new site before launch. Run PageSpeed Insights and record LCP, INP, and CLS scores for both mobile and desktop. Flag anything in the "needs improvement" or "poor" range before the client sees the live site. Check Search Console monthly for existing clients. The Core Web Vitals report surfaces issues as they appear in field data. Catching a regression early — before it compounds — is significantly easier than explaining a traffic drop after the fact. Document what you've improved. Clients rarely see Core Web Vitals scores on their own. A monthly one-page performance summary showing before/after scores builds credibility and makes your technical work visible. Prioritize mobile. Google uses mobile-first indexing, and field data shows that mobile CWV scores are almost always worse than desktop. If you only have time to optimize one version, do mobile first. Core Web Vitals aren't a one-time fix. Platforms change, new scripts get added, campaigns bring in new widgets. Build the audit into your workflow and treat it like any other ongoing deliverable, and you'll stay ahead of the issues before they affect your clients' rankings. Duda's platform is built with Core Web Vitals performance in mind. Explore how it handles image optimization, script management, and site speed automatically — so your team spends less time debugging and more time building.
By Ilana Brudo March 31, 2026
Vertical SaaS must transition from tools to an AI-powered Vertical Operating System (vOS). Learn to leverage context, end tech sprawl, and maximize retention.
Show More

Latest posts