A live broadcast is the one product that loses all its value if it arrives ten minutes late.
A news article can be read tomorrow and a film can be watched next week. The final whistle, the result of a phone vote, the first lap of a race and the speech everyone tuned in for exist live once, and the viewer who missed them because the player spun is not coming back for the replay.
That shapes everything about how a media company should test its defences. The busiest minutes are booked months ahead, the audience turns up in the same five minutes, and most of the delivery chain is somebody else's network.
DDoS testing for media and live streaming, defined
DDoS testing for media and live streaming is an authorised exercise that measures how a broadcaster's or streaming platform's delivery chain behaves under denial-of-service load at audience scale. It follows the stream from the contribution feed at the venue, through the packager and origin shield, out across one or more CDNs, and covers the per-viewer services that are never cached: entitlement, DRM licences and personalised ad playlists.
Methodology that applies to every sector (authorisation, ceilings, how to read results) lives in the complete guide to DDoS testing. Here the subject is the live moment and the chain that carries it.
| Component | Cached at the edge? | What a flood does to it |
|---|---|---|
| Contribution ingest | n/a, one sender | cuts the feed for every CDN at once |
| Live packager and origin | behind the shield | collapses if the shield is bypassed or missing |
| Media segments | yes, seconds after they exist | fine, unless requests reach for segments that do not exist yet |
| Live playlists | for a second or two | the most frequent request in the system |
| SSAI playlists | no, one per viewer | every reload reaches the ad-insertion service |
| Entitlement and DRM licences | no | the whole arriving audience hits them at kickoff |
Live has no replay button
The shape of a live audience is the first thing to get right, because an attack rides on top of it.
The audience arrives in the last few minutes
Viewers do not trickle in across an hour. They open the app in the minutes before the start time, and many more arrive within seconds of a goal, a red card or a breaking story being pushed to their phones.
Every one of those arrivals does more than fetch video. It authenticates, checks entitlement, requests a DRM licence, loads a master playlist and then picks a rendition. The start of a stream is the most expensive moment in a viewer's session, and a live event makes everyone's start happen together.
Big events draw attackers
Broadcasters are a documented target. On New Year's Eve 2015 the BBC's websites, iPlayer included, were taken offline for several hours by a DDoS attack claimed by a group calling itself New World Hacking, which put a size on it that was never independently confirmed.
During the 2022 Eurovision Song Contest in Turin, Italian police said they had blocked DDoS attacks by the pro-Russian groups Killnet and Legion against the contest's network infrastructure during the semi-final and the final. A live vote with a hard window is an obvious target, because a few lost minutes cannot be re-run.
A crowd and a flood look alike from the sofa
Not every bad night is an attack. When Netflix streamed the Jake Paul and Mike Tyson fight in November 2024, it later said the event peaked at 65 million concurrent streams, and viewers widely reported buffering and failed starts. No DDoS was involved.
The point for a test plan is that viewers, the press and sometimes the operations team cannot tell the two apart while it is happening. That cuts both ways: an attack can hide inside a record audience, and a record audience can trip controls that were tuned to stop an attack.
The playlist is the request that never stops
Segment-based streaming (HLS and MPEG-DASH) makes each player reload its playlist continuously to learn which segments are new. For a live stream that reload happens roughly once per segment duration, for every viewer, for the whole event.
The arithmetic at the edge
With 4-second segments and a million viewers, players ask for a playlist about 250,000 times a second. Nobody calls that an attack, because it is the product working as designed.
The edge absorbs it because the playlist is cacheable for a second or two. Each edge location collapses simultaneous requests for the same object into one fetch upstream, and an origin shield collapses the edge locations again, so a 6-rendition stream with playlists cached for 2 seconds puts only a handful of requests a second on the packager.
That division by tens of thousands is the whole defence of the packager, which in many architectures is a small redundant pair sized for the shielded rate. Anything that defeats the caching hands the packager a rate it was never built for.
Signed URLs can put every viewer in the cache key
Streaming platforms protect content with tokenised URLs, often a signature and an expiry in the query string, unique to each viewer. If the CDN validates the token and then caches on the path alone, a million viewers share one cached playlist.
If the token stays in the cache key, each viewer's request is a different object. Every playlist reload becomes a miss, and the cache does no work at all. It is the textbook cache-busting attack, except that your own player is sending it.
This misconfiguration often hides at normal audience sizes, because the shield still collapses some of it and the origin copes. It shows up at the first record audience, or when somebody adds random query parameters on purpose.
Server-side ad insertion makes every playlist personal
Server-side ad insertion (SSAI) stitches ads into the stream by rewriting the playlist for each session. The segments may still be cached, but the playlist cannot be: it is generated per viewer, on every reload.
So with SSAI the most frequent request in the system bypasses the cache by design. At a million viewers and 4-second segments, the manifest-manipulation service sees the full 250,000 requests a second, and at each ad break it also makes ad-decision calls for the whole audience in the same few seconds.
Whoever runs that service, you or a vendor, it needs to be load tested at the event's audience estimate plus attack headroom, with the vendor's permission. It is the least visible single point of failure in many streaming stacks.
In rehearsal
Confirm the cache key. Request the same live playlist with two different valid tokens and with a junk query parameter, and check the CDN's response headers and logs for hits. Then check what the SSAI and ad-decision services can sustain, separately from the CDN, because their ceiling is the audience's ceiling.
Requests for segments that do not exist yet
Caching works on objects that exist. A live stream is a sequence of objects that appear every few seconds, which leaves a gap an attacker can aim at.
Future segments are misses by construction
A request for a segment number a few hundred ahead of the live edge cannot be served from any cache, because the segment has not been made. It travels to the packager, which answers with a 404.
If the CDN does not cache that 404 (many configurations do not cache errors, or cache them very briefly), an attacker can generate an endless stream of guaranteed misses by counting upwards. The same works for renditions or audio tracks that the URL pattern implies but the stream does not carry.
The broader family of cache-defeating requests, and how to measure what the edge really absorbs, is covered in the CDN cache absorption post. The live version is narrower and easier to close: reject at the edge any segment number implausibly far beyond the current live edge, and cache 404s for a second or two.
Low-latency streaming holds requests open
Low-Latency HLS adds blocking playlist reloads: the player asks for a playlist that does not exist yet (using _HLS_msn and _HLS_part query parameters) and the server holds the request open until it does. That trades request rate for open connections, the same exchange the WebSocket post describes for long-lived sockets.
The HLS specification tells the server to answer requests too far beyond the live edge with a 400 rather than holding them. Check that your packager and your CDN actually do. A packager that holds a request for a segment thousands of parts ahead is holding a connection until somebody gives up.
The contribution feed is the single wire
Every CDN, every rendition and every viewer depends on one thing upstream of the packager: the programme feed coming from the venue or the studio.
Ingest is a public address with one legitimate sender
Contribution usually arrives over SRT (UDP), RTMP (TCP port 1935) or a broadcaster's managed link. The ingest endpoint is often a public address, and its only legitimate client is a handful of encoders.
That makes it unusually easy to protect and unusually costly to leave open. A flood that saturates the ingest point, or exhausts its connection handling, blacks out the stream on every platform at once, however much capacity the CDNs have. A CDN cannot cache a frame that was never produced.
Redundancy only counts if it is independent
Most live workflows send a primary and a backup feed. The test is whether the backup is actually independent: a different region, a different address, ideally a different provider, and already receiving the feed rather than waiting to be switched on.
Two ingest addresses in the same region behind the same upstream link are one target with two names.
In rehearsal
Restrict ingest to the encoders' source addresses where the network allows it, and require the SRT passphrase or the platform's stream key on everything. Then, during a rehearsal with a test stream, send a bounded flood at the primary ingest address and measure what viewers of the test stream see: no gap, a gap the player buffer rides out, or seconds of black. Time how long it takes master control to notice, too.
Leave the venue's own uplink out of scope. It is usually bonded cellular or a leased circuit shared with the production, and a test that takes it down during setup costs a rehearsal.
Kickoff is an authentication storm
The cached part of the chain divides load by tens of thousands. The per-viewer services in front of playback divide it by nothing.
Entitlement and licences are never cached
At the start of an event each arriving viewer needs a session, an entitlement check (is this account allowed this channel, in this country, on this device) and a DRM licence for Widevine, PlayReady or FairPlay. None of those can be served from a cache.
If 2 million viewers arrive in the last five minutes before kickoff, the licence service sees about 6,700 requests a second for those five minutes, before a single attacker joins in. An L7 flood aimed at the licence or entitlement endpoint needs far less traffic than one aimed at the video, and it produces the same result: a player that never starts.
Key rotation repeats the bill
Many live services rotate content keys during the stream, which sends players back for a new licence at each rotation. If every player received its first licence in the same five minutes, rotation repeats a share of that peak on a schedule, for the whole event.
A licence policy that covers the event's length, or key rotation spaced so that renewals spread out, changes that load more than any edge rule can.
A licence vendor has its own limits
The licence service is often a third-party multi-DRM provider, with its own rate limits per customer. Those limits were set for your normal day.
Load testing it means asking that provider first, under their testing policy. What you can test unaided is your side: what your player does when a licence request fails (retry with backoff, or retry immediately and multiply the load), and whether your entitlement service, which you do own, holds the kickoff arrival rate with an L7 flood added.
Challenges do not work inside a player
On a website, a challenge is a page the user clicks through. A smart TV app, a set-top box or a games console fetching a playlist or a licence over an API has no way to show one.
So the controls that protect the licence and entitlement endpoints have to be rate limits, token checks and behaviour scoring that a non-browser client can pass silently. Test from the real device types, not only from a browser, and count failed starts per device family.
Multi-CDN failover moves the load onto your origin
Large streaming services run more than one CDN, so that a problem on one can be routed around. During an attack that switch is a mitigation, and it has to be rehearsed like one.
How the switch happens
Traffic is steered between CDNs by DNS, by the player itself, or by a content steering server (both HLS and DASH now define one) that tells players which CDN to prefer. DNS steering waits on resolver caches and TTLs. Player-side and steering-server switching can move viewers within a playlist reload or two.
Either way the viewers get through. The question is what happens behind the second CDN.
The backup CDN may have no shield
The primary CDN usually fetches through an origin shield, because the operations team tuned it. The backup is often configured as a straight pull from origin, because it carries little traffic on a normal day and a shield costs money.
When every viewer moves across, each of the backup's edge locations fetches from the packager separately. With the same assumptions as above (6 renditions, 4-second segments, playlists cached for 2 seconds), that is 4.5 requests a second per fetcher: one fetcher through a shield, 200 without one.
The packager was sized for the shielded rate. Failing over to protect the viewers can take down the one component both CDNs depend on.
The origin address leaks through the backup
A backup CDN that pulls direct needs the packager's address, and a packager that accepts any CDN's pulls is often reachable from anywhere. Once that address is known, an attacker can skip both CDNs.
Locking the origin to the CDNs' published ranges, or to authenticated pulls, is the fix described in the origin IP exposure post. For streaming it has to cover every CDN in the rotation, including the one nobody looks at.
In rehearsal
Switch CDNs during a rehearsal with a realistic synthetic audience and watch the packager's request rate, CPU and error rate through the switch. Run it once for the planned failover and once for the panic one: a sudden, complete move at the worst moment, such as an ad break.
Breaking news has no booking
Sport and entertainment are scheduled. News is not, and a news site's busiest ten minutes arrive with no warning at all.
The control that sees a crowd as an attack
A breaking story produces a flash crowd that looks, to a rate-based control, much like an L7 flood: a sudden rise in requests, from many new sources, to the same few URLs. If the thresholds were tuned against an ordinary day's baseline, the biggest audience of the year is the one most likely to be challenged or blocked.
The test is to replay a previous big news day's traffic shape against the staging edge and count what the controls do to it. A false-positive rate measured on an ordinary day says nothing about the day that matters.
Serve something rather than nothing
News publishers have an option that live video lacks. Article pages can be served stale from the edge when the origin struggles (stale-while-revalidate and stale-if-error), and a stripped-down static page can stand in for the full site.
Both need testing before they are needed: switch the origin off behind the staging edge and confirm what readers get, and for how long.
Before the next big event
The calendar is the test plan. Work back from the event date.
- Eight weeks out: write down the audience estimate, the arrival window and the services that are never cached. Ask each CDN, the DRM provider and the SSAI vendor for their testing policies.
- Six weeks out: confirm cache keys, 404 caching and the far-future segment rule on every CDN. Restrict ingest addresses.
- Four weeks out: load test entitlement, licence and ad-insertion paths at the arrival rate plus attack headroom, with each provider's permission.
- Three weeks out: rehearse an ingest flood against the primary feed on a test stream, and a full CDN switch with a synthetic audience.
- Two weeks out: run the decisions as a tabletop exercise set during the event: who switches CDNs, who talks to the rights holder, who updates the status page.
- Event week: a change freeze on edge and player configuration, and the people who can make each call on shift.
Production limits, abort criteria and who can stop a test belong in the plan before any of this, as set out in testing without disrupting production.
FAQ
Can a CDN absorb a DDoS attack on a live stream?
It absorbs floods aimed at cached video segments very well. It does not protect what it cannot cache: the contribution feed, entitlement and DRM licence services, personalised ad playlists, or a packager reachable by address. Most streaming outages under attack start in one of those.
Why does low-latency streaming change DDoS exposure?
Low-latency HLS uses blocking playlist reloads, so the server holds requests open until the next part exists. That replaces some request volume with open connections, and a packager or CDN that holds requests for parts far beyond the live edge can have its connections tied up cheaply.
Do DRM licence servers need DDoS protection?
Yes. Every viewer needs a licence to start playback, licence requests cannot be cached, and an L7 flood at the licence endpoint stops playback as completely as one at the video. Ask your multi-DRM provider about its per-customer limits and test your own entitlement service in front of it.
Is it safe to switch CDNs in the middle of a live event?
It is safe if the backup CDN has been rehearsed at audience scale. The common failure is a backup that pulls direct from origin without a shield, so the switch multiplies the request rate at the packager by the number of edge locations.
How do you tell a DDoS attack from a record audience?
From inside the event, often not quickly. Real viewers come from your apps and devices, carry valid tokens, and follow a predictable request sequence (session, entitlement, licence, playlist, segments). Floods tend to skip steps or repeat one of them. Building those checks into the edge rules is easier than writing them during the match.
The audience is a load test you sell tickets to
Every large live event is already a synchronised, global load test, scheduled and promoted by the broadcaster itself. An attacker does not have to out-muscle a CDN; they have to add a little more pressure at the one point in the chain where the audience was already pressing hardest.
Those points are knowable months ahead: the feed with one sender, the playlist nobody can cache, the licence every viewer needs at the same minute, and the backup CDN that has never carried a crowd. Finding them in a rehearsal costs one evening, and missing them costs the one broadcast the audience cannot see again.