How to protect an online store from DDoS attacks.

Why online stores get attacked

An outage on a content site costs attention. An outage on a store costs orders, and the loss is arithmetic rather than reputational: the sessions in your funnel at the moment the site stops responding do not come back later, they buy somewhere else. Retail is one of the few targets where the victim can price an hour of downtime to the euro — which is precisely what makes it worth extorting. Ransom DDoS demands land in retail inboxes because the recipient can do the arithmetic in their head.

Attacks cluster around the calendar. Black Friday, seasonal sales, a limited drop, a campaign you have already paid to promote — the hours when your traffic is highest are the hours when your infrastructure has the least headroom and your team has the least appetite for risky changes. An attacker who reads your newsletter knows your schedule as well as you do.

Retail also attracts attackers who are not trying to take you offline at all. Price scrapers, scalper bots, card testers and coupon brute-forcers all generate automated, high-volume traffic aimed at exactly the endpoints a flood would target. Whether the denial of service was intentional is a distinction your database connection pool does not make.

What actually breaks first

The instinct is to worry about the homepage. The homepage is the one page that survives, because it caches. Everything downstream of it is dynamic by definition — it depends on a session, a cart, live stock or a third-party call — and dynamic means every request is computed for the person who asked.

The pattern is worth stating plainly: a flood of 300 requests per second against your checkout is worth more to an attacker than 300,000 against your homepage. That is the cost asymmetry behind every Layer 7 attack, and a store hands it over by design, because you cannot cache a shopping cart.

There is a second-order problem specific to commerce. Your checkout is only as available as your payment gateway, your stock sync and your shipping-rate API. A flood that multiplies your outbound calls can get you throttled by your own providers — an outage that continues after the attack stops and that you cannot fix from your side. Bounding request rates at the edge protects your suppliers' rate limits as much as your own servers.

Attack, or just a good day?

This is the question that actually costs stores money, and it cuts both ways: block a real sales surge and you have DDoSed yourself; wave an attack through as "the campaign working" and you find out at the end of the day. Traffic volume alone will not tell you. These signals will.

• The shape of the funnel. A genuine surge preserves rough ratios between category views, product views, carts and orders. An attack inflates one stage and leaves the rest flat. Sessions tripling while conversion falls off a cliff is the clearest single tell there is.
• Path distribution. Campaign traffic lands on the pages you promoted. Attack traffic hammers one endpoint, or spreads evenly across URLs in an order no human would navigate.
• Cache hit ratio. A real crowd wants the same sale page, so your hit ratio goes up. Attacks usually drive it down — randomized query strings, uncacheable paths, deliberate cache busting.
• Entry points and referrers. Real traffic arrives from your email send, your ads, search and social. Floods arrive with no referrer at all, or with one that does not survive a second look.
• Client diversity. Human traffic has a long, messy tail of browser and OS versions. Automated traffic clusters unnaturally: the same user agent, the same TLS fingerprint, the same header ordering, at a volume that tail should never produce.
• Geography against your shipping map. You know which countries you can actually deliver to. A spike from everywhere else is not a market opening up.

One organizational check beats all of the above: a surge you caused is documented somewhere — a send, a post, a price change, an influencer. If nobody in the company can point at the cause within a couple of minutes, treat it as an attack until proven otherwise. The defensive steps are cheap and reversible; the downtime is not.

The bots that are a denial of service either way

Retail carries a category of automated abuse that has nothing to do with taking you offline and produces the same result. OWASP catalogs these as automated threats to web applications, and four of them are aimed squarely at stores:

• Scraping. Competitors and aggregators polling your catalog for prices and stock, often re-crawling thousands of products on a schedule far tighter than any shopper browses. Pure origin load, zero revenue.
• Scalping and denial of inventory. Bots that buy limited stock the instant it drops, or that hold items in carts to keep real customers from buying them. A drop turns into a race your customers lose, and your add-to-cart endpoint absorbs the entire field.
• Carding. Stolen card numbers validated in bulk against your checkout because a €1 test order is the cheapest way to find out which ones still work. The load is the least of it: you pay gateway fees per attempt, then chargebacks, then a fraud ratio your processor notices.
• Coupon and gift-card enumeration. Brute force across a small code space, one database lookup at a time.

None of this is stopped by volume thresholds, because none of it is volumetric. It is defeated by per-client behavioral limits and by making the expensive paths cost the client something — which is the same machinery that stops a Layer 7 flood.

The defense, in the order that matters

1. Cache everything anonymous, aggressively. Full-page edge caching for category and product pages removes your application from the request path entirely for visitors who are not logged in and have nothing in a cart. Bypass the cache on a session or cart cookie, ignore unknown query strings in the cache key so ?utm_source=… and ?x=91772 resolve to the same object, and serve stale content on origin error so a struggling backend degrades into slightly old prices instead of a 502. With a 60-second TTL, a flood against your bestseller page produces one origin request per minute. This is why a CDN is attack armor and not just a speed tool.

2. Bound the funnel with the right key. Rate limits keyed only on IP address are wrong in both directions for retail: mobile carriers and office networks put thousands of genuine shoppers behind one address, while a botnet gives an attacker thousands of addresses. Key on session and account where you have one, fall back to a client fingerprint, and reserve the strictest limits for coupon validation, checkout submission and password reset — the endpoints where a legitimate customer makes a handful of attempts and an attacker needs thousands.

3. Keep machine traffic out of the challenge path. Payment webhooks, ERP and stock sync, marketplace feeds and Google Merchant crawlers cannot solve a browser challenge and must never be shown one. Allowlist those paths explicitly, verify good bots rather than blocking them, and make sure your API-shaped endpoints return 429 rather than an HTML interstitial — the reasoning is in how to protect an API from DDoS attacks. A dropped payment callback is an order marked unpaid, which is more expensive than the attack.

4. Treat CAPTCHAs as a conversion tax. Every interruption between a customer and the buy button costs orders, and the cost is highest on exactly the pages you are most tempted to protect. Verification should be invisible for real browsers and reserved for clients that have already behaved like automation. If your mitigation's answer to a flood is a CAPTCHA wall in front of the checkout, the attacker achieved the goal through your defenses.

5. Make sure the edge cannot be bypassed. None of this holds if your origin server still answers the internet directly. Attackers pull DNS history and certificate transparency logs and probe unproxied subdomains — admin., staging., mail. — then send the flood straight past your filtering. Firewall the origin to accept HTTP only from your mitigation network, and work through how to hide your origin IP address.

6. Do the peak-season work before the change freeze. In the quiet week beforehand: record what normal looks like per endpoint so you have a baseline to compare against, turn on attack alerting and point it at a channel someone actually watches, decide in advance who is allowed to change filtering rules during a sale, confirm your status page and support macros exist, and check that your logs are unsampled — mid-incident is a bad time to discover you cannot see individual requests. If the store is down while you are reading this, work through how to stop a DDoS attack first and come back to this section afterwards.

How Itnetic protects online stores

Itnetic sits in front of your store as a reverse proxy you enable with two DNS records. There is nothing to install in your platform, which matters here more than elsewhere: any defense that runs inside your application has already spent a worker and a database connection on the request it is about to reject.

Anonymous traffic meets an invisible challenge gate at the edge — real browsers pass without a CAPTCHA, and scripted floods aimed at login, search and add-to-cart never reach your backend. Behavioral signatures and IP reputation filtering catch clients that fake a browser user agent, which is what scrapers and card testers do by default, and WAF rules let you allow, block or challenge by path, method, country or client fingerprint. Rate limits bound the endpoints that must stay dynamic, while edge caching serves the catalog without touching your origin. Payment callbacks and integration paths can be marked as an API zone so machine clients receive proper status codes instead of a challenge page they cannot solve.

When traffic spikes during a sale, per-request logs and analytics are what let you answer the only question that matters in the moment — is this customers or is this an attack — from the actual request mix rather than a guess. Attack traffic is never metered against your bandwidth quota, because being attacked during your busiest week should not also produce an invoice, and DDoS protection is included on every plan, including the free one.

Itnetic's DDoS protection goes live in about five minutes, which is short enough to do during an incident and much better done before one. If you want the background first, start with what DDoS mitigation is.