Website DDoS and bot protection setup puts a protection layer in front of your site and teaches it the difference between customers and automated abuse. We place the site behind a CDN and web application firewall, hide the origin server, set rate limits and bot rules for logins, forms, search and checkout, and write a short response plan. The aim is a site that stays reachable during floods and forms that receive far less automated junk.

Two different problems: floods and abuse

DDoS attacks aim to make a site unavailable; bad bots aim to use it against you. Both arrive as automated traffic, and both are handled at the layer in front of your server, with different rules.

CISA, the FBI and MS-ISAC sort DDoS techniques into three types in their joint guide: volume-based attacks that saturate bandwidth, protocol-based attacks on network layers 3 and 4, and application-layer attacks on layer 7 that exhaust the application itself. Bot abuse is catalogued separately by OWASP's Automated Threats to Web Applications project, which lists 21 threat types such as credential stuffing, scraping, account creation and denial of inventory.

What protects a site from each threat

The table matches common threats to the control that handles them and to the public reference behind it.

Threat Control we set up Source
Volume-based flood CDN or DDoS mitigation service in front of the site, origin IP hidden CISA DDoS guide
Protocol attack, layers 3 and 4 Provider-side network mitigation CISA DDoS guide; Cloudflare DDoS documentation
Application-layer flood, layer 7 Rate limits and challenges on costly pages such as search and checkout CISA DDoS guide
Credential stuffing (OAT-008) Login rate limits, bot challenges, multi-factor sign-in OWASP Automated Threats
Scraping (OAT-011) Bot rules and rate limits on catalogue and price pages OWASP Automated Threats
Denial of inventory (OAT-021) Limits on cart holds and checkout attempts OWASP Automated Threats
Form spam and fake accounts Challenges on submission, server-side validation OWASP Automated Threats; CISA (CAPTCHA)

How we set it up

Protection only works when all traffic passes through it, so the order of steps matters. We start with the DNS and the origin server, then add rules from the general to the specific.

  1. Map the site. Domains, subdomains, the origin server, APIs, payment and booking endpoints, and the services that call your site.
  2. Put the protection layer in front. DNS through the CDN or protection provider, TLS end to end, and the origin firewall accepting traffic only from the provider.
  3. Baseline. We record normal traffic levels, as CISA recommends, so an attack can be told apart from a successful campaign.
  4. Rules in logging mode. Rate limits and bot rules for login, password reset, forms, search, cart and checkout run in log-only mode first.
  5. Switch to enforcement. After checking the logs, rules move to challenge or block; verified search engine crawlers and your own integrations are allowed.
  6. Response plan. A short document: how to recognise an attack, whom to call at the hosting and protection providers, which stricter rule set to switch on, and what to record.

Choosing a protection provider

The right provider depends on your hosting, your traffic and the features you need, and many small sites can start on a free tier. Cloudflare, for example, documents that standard unmetered DDoS protection across layers 3 to 7 is available on all its plans.

We compare options against your setup and recommend one. If a paid plan or add-on is needed, the licence is billed at cost, without vendor commissions. The account belongs to your company.

What you receive

You receive a protected site, tested rules and a plan your team can follow during an attack.

  • The site behind a protection layer, with the origin server reachable only through it.
  • Rate limits and bot rules for the pages attackers use, tested in logging mode before enforcement.
  • An allow list for search engines, payment providers and your integrations.
  • A traffic baseline and alert thresholds.
  • A one-page response plan with contacts and the prepared stricter rule set.
  • A short report of the settings, so your developer or next agency can maintain them.

What we need from you

We need access to DNS, the hosting or server, the CMS, the list of services that connect to the site, a contact who can approve rule changes, and a signed scope letter.

Boundaries

The setup covers your websites and the domains listed in the scope letter. Protection providers absorb attacks within the limits of their service; we configure your use of it. Round-the-clock monitoring and managed response during attacks are available on request from a separate provider, named in the proposal. Load testing or simulated attacks on your site are done only with written permission, on dates agreed in advance.

Risks of adding a CDN and stopping there

A CDN switched on with default settings can leave the origin server's IP address public, so an attacker goes around the protection. Strict bot rules copied from a forum can block payment callbacks or search engine crawlers, and the damage shows up days later in lost orders or rankings.

A chatbot can name providers and cannot see your traffic logs. A freelancer may set rules once and leave nobody who knows how to switch to the stricter set during an attack. We test rules before enforcing them and hand over a written plan.

Who does the work

Security engagements are contracted with INNOVA CONSULT LTD., Ottawa, Ontario (Corporations Canada, Corporation Number 1522612). The team runs its own servers and more than 80 websites under daily vulnerability checks.

Cost

A fixed price is set in the scope letter after a 30-minute call. The main factors are the number of domains, the hosting setup and the pages that need bot rules.

Related services

Sources (checked 2026-10-23)

Maksym Stepanenko, founder of Marketing MIX. Last reviewed: 2026-10-23.