An online shop is most valuable to an attacker on the same few days it is most valuable to its owner.
DDoS testing for e-commerce is a controlled, authorised test of whether a shop's defences can separate attack traffic from real shoppers on its busiest day, measured by whether orders keep completing through checkout, basket, stock and payment, rather than by whether the home page still loads. It is for the platform, infrastructure and security engineers who own a storefront, and for the trading and finance leads who carry the cost when a sale day fails.
The general method (scope, authorisation, abort criteria, safe ramps) is the same for any target and lives in the complete guide to DDoS testing. This post covers what is different about a shop: the money path, the peak, the bots, and the calendar.
What makes a shop a different DDoS target?
Three things: the attack lands on top of your own peak, the expensive requests are the ones that make money, and the calendar tells the attacker when to arrive.
The attack lands on top of your peak
Most services get attacked on an ordinary afternoon, with ordinary headroom. A shop is often attacked during a launch, a sale or a seasonal weekend, because that is when an hour of downtime costs the most and an extortion note is most likely to be paid.
So the headroom that matters is capacity minus peak, and on peak day that number is at its smallest. A defence that held comfortably in a March test can fail in November with the same attack, because the same attack is now stacked on four times the normal traffic.
The cheap pages and the money pages are different systems
Browsing a catalogue is mostly cacheable. Product listings, images and descriptions sit at the CDN edge, and an attack against them is largely absorbed there (how much depends on your headers, covered in how CDN caching absorbs a DDoS).
Everything after "add to basket" is the opposite. Each request writes state, reads live stock, or calls a third party. Those are the requests that cannot be served from the edge, and they are the ones a competent attacker aims at.
The calendar is public
Everyone knows when Black Friday is. In 2026 it falls on 27 November, with Cyber Monday on 30 November. Your own launches are announced in advance on purpose. An attacker does not need to probe for your weakest moment; you published it.
Which parts of a shop does a DDoS actually target?
The basket, the stock lookup, the checkout and the payment callback. They are the paths that hold state or wait on a slower system, and each fails in its own way.
The basket writes on every click
An add-to-basket request is a write. For an anonymous shopper it usually creates a session as well, so the first request from a new client allocates a server-side record before the shop knows anything about who sent it.
That makes a basket flood an attack on your session store. If the store is an in-memory cache with an eviction policy, millions of junk guest sessions do not just cost memory; they push out the real ones. Under an LRU policy the shopper who added three items twenty minutes ago is exactly the key that gets evicted, and they come back from the payment page to an empty basket.
A test should count how many session keys a single attack request creates, and watch eviction counters alongside latency. A store that stays fast while evicting real baskets is failing in a way the latency graph does not show.
Stock lookups hit the system that scales least
The product page may be cached, but the "in stock" badge, the per-store availability check and the delivery-date estimate often are not. They call through to an inventory or order-management service that was sized for the shop's ordinary rate, sometimes backed by an ERP that was never meant to face the public internet at all.
An attacker who finds that call has found the narrowest pipe in the building. The API post covers how to find the expensive endpoint behind a cheap request; in a shop, look first at anything that answers "can I have this?".
Reservations turn traffic into held stock
Many shops reserve a unit when it goes into the basket or when checkout starts, and release it after a timeout. That is good for customers and a gift to an attacker.
A bot that adds the last units of a launch product to thousands of baskets and never pays has taken the stock off sale for the length of the hold, without sending much traffic at all. OWASP's Automated Threats to Web Applications handbook names this pattern Denial of Inventory (OAT-021).
The arithmetic is short. Units held equals reservation rate times hold time. At 20 reservations a second with a 15-minute hold, 18,000 units are off sale at any moment, from traffic that would not trip a volumetric alarm.
Checkout and payment leave your perimeter and come back
At checkout the shopper is often sent to a payment page or a 3-D Secure challenge hosted by their bank, then redirected back. The session has to survive that round trip, which brings the eviction problem above straight back.
Separately, the payment provider tells you the result by calling your server: a webhook or callback, server to server. That request comes from the provider's infrastructure, carries no browser, and cannot solve a JavaScript challenge.
Why does the payment callback fail first?
Because the emergency rules applied during an attack are written for browsers, and the callback is not a browser.
The rule that blocks the provider
Under attack, a common response is to raise a JavaScript challenge or tighten a rate-based rule across the whole site. If the callback path is not explicitly exempted, the provider's notification gets challenged or rate limited like everything else.
The shopper has paid. The provider has captured the money. Your order system never heard about it.
What happens next is slow and expensive
Most providers retry failed notifications with a backoff, so the confirmations do arrive, minutes or hours late. In the meantime the order sits unconfirmed, no confirmation email goes out, and some shoppers order again, so the attack's cost shows up later as duplicate charges, refunds and a support queue.
What to test
Before peak, confirm the callback path is exempted by the provider's published source ranges or by signature verification at the edge, not by "nobody would block that". Then, during the test, apply your real emergency rules and confirm a sandbox payment still completes end to end.
Never send test load at the payment provider itself. Use the provider's sandbox for the flow, and check its terms; load against a third party's production endpoints is their decision, not yours.
How do you tell a sale-day spike from an attack?
By whether the traffic moves through the funnel. A sale brings more shoppers who behave like shoppers; an attack concentrates on one step and goes nowhere.
Volume does not separate them
A launch at 09:00 sends traffic from near zero to many times normal in a minute, from a large number of new clients, mostly on the same few URLs. That description fits a flood just as well. If your detection is a rate threshold, the sale and the attack trip it at the same moment.
Funnel ratios do
In a real sale the ratios between steps hold roughly steady while the volumes jump. Views, basket adds, checkout starts and orders all rise together. In an attack on one step, that step's count jumps and the step after it does not follow.
A worked example, with illustrative numbers:
| Per minute | Ordinary day | Sale launch | Sale launch + basket flood |
|---|---|---|---|
| Product views | 10,000 | 40,000 | 40,000 |
| Basket adds | 600 | 2,800 | 14,000 |
| Checkout starts | 180 | 760 | 330 |
| Orders | 120 | 520 | 150 |
| Orders per 1,000 views | 12 | 13 | 3.75 |
The sale quadruples traffic and the conversion ratio barely moves. The flood leaves views alone, multiplies basket adds by five, and cuts orders by more than two thirds, because the basket tier is now too busy to serve the people trying to buy.
Where the ratio test is weak
It needs a baseline for the same kind of event, so the first sale of a new format has none. It reacts in minutes, not seconds. And an attacker who walks the whole funnel, view then basket then checkout, keeps the ratios looking normal; that is closer to bot traffic than a flood, which is the next problem.
The useful habit is to put the funnel on the same screen as the traffic graph during peak, so the person deciding whether to tighten rules is looking at conversion, not just requests.
What happens when bots and a DDoS arrive together?
Two different control systems act on the same traffic, often owned by different teams, and the shopper takes the collateral from both.
Peak brings its own bots
A hot launch attracts scalper bots buying limited stock, card-testing bots using checkout to validate stolen cards, and scrapers watching prices. None of that is a DDoS, but on launch morning it shares the same paths, and a bot management product is usually already scoring it.
Two systems, one request
The DDoS controls (rate rules, challenges, emergency blocks) typically belong to infrastructure or security. The bot product often belongs to the e-commerce team, tuned around launches. During an attack both can act on the same request, in an order set by your edge configuration, and neither team may know what the other changed that morning.
A challenge that is acceptable against a flood at 03:00 is a lost sale at 09:00 when real shoppers are racing for limited stock. Test with the bot product in its launch-day configuration, not its everyday one, and record which system made each block decision.
The waiting room is a DDoS control
A virtual waiting room admits shoppers to the shop at a fixed rate and holds the rest on a static page. Whether it was bought for fairness or for capacity, it is now part of your DDoS defence, and it changes what an attack has to do.
Three things to test:
- The queue page itself. It must be static and cacheable, or the flood simply moves to the page that was meant to absorb it.
- Admission tokens. The token issued at the front of the queue has to be checked on the money path. If
/checkoutor the basket API answers without one, the attacker skips the queue and the shoppers wait in it. - The admission rate. It was set for shoppers. Under attack, a bot that obtains admission tokens consumes slots a shopper needed.
When should an e-commerce DDoS test run?
Before the change freeze, with enough time to fix what it finds and test again.
The freeze decides the deadline
Many retailers stop production changes from early or mid November until January. A test that finds a missing callback exemption on 20 November has found a problem you are not allowed to fix until after the peak it was meant to protect.
Work backwards. If the freeze starts mid November, the test belongs in September or early October, with a retest window in late October for the fixes.
Test the configuration you will run on the day
The shop on Black Friday is not the shop in October. Sale landing pages, promotional pricing, the waiting room, extra autoscaling capacity, the bot product's launch rules and sometimes a different checkout flow are all switched on for the event.
Test that configuration. Where it cannot be switched on early in production, test the closest staging copy and say so in the report, because a result against the October shop says little about November.
A peak load test and a DDoS test answer different questions
A load test asks whether the shop can serve the shoppers you forecast. A DDoS test asks whether your controls can keep serving them while something else is also arriving. Both are needed before peak, and the second assumes the first has passed; there is no point measuring separation on a shop that falls over under its own customers.
What should you measure?
Orders per minute first, then the numbers that explain them. The general case for measuring goodput over availability is made in the L7 testing post; for a shop it turns into a handful of specific numbers.
The numbers that matter in a shop
- Orders per minute during the attack, against the same minute of a comparable baseline.
- Checkout completion rate: checkout starts that became orders.
- Basket survival: baskets that still exist after the shopper returns from payment.
- Callback lag: time from a sandbox payment to the order showing as confirmed.
- Held stock: units in reservation that no paying shopper holds.
- Collateral: real shoppers challenged or blocked, by which control.
A home page that returned 200 for the whole test while orders fell by two thirds is a failed test.
A pre-peak checklist
- Agree the freeze date and book the test window, fix window and retest before it.
- Switch on the peak configuration: waiting room, bot launch rules, sale pages, peak scaling.
- Map the money path: basket, stock and availability calls, reservation, checkout, payment redirect, callback.
- Confirm the payment callback is exempt from emergency rules and challenges, and test it with a sandbox payment under those rules.
- Measure session keys created per anonymous request and set an alert on session-store evictions.
- Write down the reservation hold time and work out the stock an attacker can hold at a modest request rate.
- Check the waiting room's admission token is enforced on basket and checkout, not only on the landing page.
- Put conversion and funnel ratios on the incident screen next to traffic.
- Run the attack on top of simulated peak traffic, not on an empty shop.
- Record which control made each block decision, and what it cost in real shoppers.
The factors that drive the cost of a test like this are broken down in what a DDoS test costs.
FAQ
Should an e-commerce site run a DDoS test during peak season?
Not during the peak itself. Run it before the change freeze against the peak configuration, so there is time to fix and retest. Testing in production during a live sale puts real orders at risk for information you could have had a month earlier.
Can the CDN protect checkout?
Only partly. A CDN can sit in front of checkout and filter at the edge, but it cannot serve a basket or checkout from cache, so every accepted request still reaches your origin. The edge's job there is filtering, and that is what the test has to measure.
How is denial of inventory different from a DDoS?
Denial of inventory holds stock rather than exhausting capacity. It can run at low request rates that no volumetric control notices, which is why reservation hold time is a security parameter as much as a product one.
Does a virtual waiting room stop a DDoS?
It limits how fast shoppers enter, and it moves the pressure onto the queue page and the admission tokens. If both hold and the money path checks the token, it is a useful control. If the queue page is dynamic or the token is not enforced, the attack goes around it.
Do we need the payment provider's permission to test?
You need it to send any load at their systems, and most will point you to a sandbox instead. Test your side of the integration, including the callback endpoint you own, and keep the provider's production endpoints out of scope.
The shop that stays up and sells nothing
Every shop that has been through a bad peak day can describe the same picture afterwards: green health checks, a home page that loaded fine, and an order graph that went flat.
That gap exists because the parts of a shop that are easy to protect and the parts that make money are different systems, and most defences are measured on the first. The question for this year's test is narrow. On the morning the sale opens, with the attack on top of it, does the checkout keep taking orders?