A Seasonal Security Audit Checklist for Black Friday and Holiday Traffic Spikes
Black Friday is not a surprise. It arrives on the same calendar every year with the same three problems: more traffic than your load test predicted, more bots than your firewall expected, and fewer engineers online than you would like. The teams that come through it well are rarely the ones with the biggest budget. They are the ones who ran a deliberate audit in October, while there was still time to fix things quietly.
What follows is a working checklist, not a compliance exercise. It covers authentication, rate limiting, and incident response — the three areas where a seasonal peak turns small weaknesses into expensive ones.
Authentication: tighten it before the crowd arrives
Login endpoints are the most expensive thing you serve. Every attempt costs database lookups, password hashing, session writes, and sometimes an email or SMS. Attackers know this. Credential stuffing campaigns recycle username and password pairs from older breaches, and a retail login page in late November is one of the best places in the world to test them.
- Enforce MFA on every admin, support, and staff account, including the contractor account someone created last spring. If you have been planning to move from SMS codes to an authenticator app or passkeys, do it now, while change control is still relaxed.
- Rate limit by account, by IP, and by device fingerprint. Per-IP limits alone collapse against a botnet that rotates addresses.
- Add progressive delays or a challenge after repeated failures, then test the threshold against real customer behaviour. A lockout policy that triggers on a family sharing one tablet will cost more revenue than the attack.
- Review password reset and account recovery flows. They get less attention than login and are often the easier path in, especially when they leak whether an address is registered.
- Confirm that signing a user out actually invalidates their refresh token. If it does not, you do not have a session control.
- Inventory API keys and service accounts with write access. Delete dormant ones. Rotate anything that was ever shared over chat.
Rate limiting that holds up under real traffic
Rate limiting is easy to switch on and hard to get right. The goal is not to stop all traffic; it is to protect the expensive paths while keeping the cheap ones fast for legitimate customers.
- Classify endpoints by cost. Product pages and images are cheap. Search, login, coupon validation, and checkout are not.
- Apply separate limits for anonymous and authenticated users. A signed-in customer checking order status should not be treated like a scraper.
- Return a proper 429 with a Retry-After header, and treat the rate of 429s as a monitoring signal. A sudden jump usually means either an attack or a limit set too tight.
- Put idempotency keys on payment and order endpoints. Retries during a spike are normal; duplicate charges are not.
- Use challenges rather than hard blocks for ambiguous traffic. Blocking a shared corporate IP or a mobile carrier range will show up in your support queue within minutes.
- Load test with abusive patterns — hot-key requests, deep pagination, rapid cart updates — not just a polite mix of page views.
Edge, cache, and dependencies
Caching is a security control. If a product page is served from the edge, it never reaches origin and never consumes a database connection during the busiest hour of the year. Review cache rules for anything that could be personalised — prices, stock levels, loyalty status — and make sure user-specific responses carry the right headers.
WAF rules deserve the same care. Roll new rules in log-only mode for a few days, read the false positives, then enforce. Names with apostrophes, gift-card lookups, and long search strings will trip naive patterns.
Also review the third-party scripts on your checkout page. Every tag is a dependency with its own availability and supply-chain risk, so pin what you can, apply a content security policy, and remove anything nobody can explain.
Finally, write down who to call. Your CDN, DNS provider, payment processor, and email or SMS vendor all have status pages and escalation paths. Confirming that your account has priority support during peak season takes fifteen minutes now and saves hours later.
Incident response, written before you need it
During a spike, nobody has time to invent a process. Settle it in advance.
- Define alert thresholds in plain numbers: error rate above a set percentage for five minutes, checkout latency above a set value, queue depth beyond a limit.
- Publish an on-call schedule that covers the holidays and includes a secondary. Test that paging actually reaches a human.
- Write runbooks for the five failures you consider most likely: origin overload, payment provider errors, a bad deploy, cache stampede, credential stuffing wave.
- Prepare communication templates for the status page, support macros, and an internal channel, so you are editing rather than writing from scratch at 2 a.m.
- Agree on a break-glass path: who can deploy during a change freeze, how they get credentials, and where that action is logged.
- Rehearse rollback and feature flags. Being able to disable a checkout change without a full deployment is worth more than any dashboard.
A 45-minute tabletop with the team is enough. Pick one scenario, walk it from detection to mitigation to customer communication, and note where the runbook is wrong. It usually is.
A four-week pre-peak timeline
- Four weeks out: inventory accounts, keys, and MFA coverage. Schedule the load test. Start the change-freeze list.
- Three weeks out: run the load test with abusive patterns. Tune rate limits, cache rules, and WAF. Verify cloud quotas and autoscaling limits with your provider.
- Two weeks out: run the tabletop. Confirm vendor escalation contacts. Check that dashboards and alerts reach real people at 3 a.m.
- One week out: freeze risky changes, rehearse the rollback, publish the on-call rota, brief support on what is changing.
- Peak days: keep a shared channel open, appoint one decision maker, and log every intervention with a timestamp.
The week after: turn the spike into next year's baseline
Once traffic falls back, resist the urge to move on. Review what actually fired: which alerts were useful, which limits caught real customers, which runbook steps were wrong. Remove temporary allowlists and break-glass accounts. Rotate any credentials that were shared during an incident. Keep the rate limits that worked and delete the ones that only produced noise.
Then fold the results back into the checklist. The document you write this year is the one that makes next November boring, which is exactly what you want.
