On the web, the client that hits your backend is code you serve on every page load. If its retry logic is wrong, you fix the JavaScript and the next request is already better. A mobile backend does not get that luxury. Its clients are a fleet of compiled binaries scattered across millions of phones, most of them running a version you shipped months ago, and you cannot recall a single one of them.
That is the fact that changes everything about testing a mobile backend for DDoS resilience. The load it has to survive is not shaped by an adversary alone. It is shaped by your own client, running code you can no longer change, reacting to events you sometimes trigger yourself, behind network conditions that make your usual defenses read the wrong signal.
A mobile backend fails in ways a website does not, because its clients behave in ways a browser does not: they retry on a schedule the OS controls, they all wake at the same instant when a push arrives, and they hide behind carrier networks that make a million users look like a hundred addresses. Testing one means reproducing that behavior on purpose, before a product launch or a marketing push does it to you by accident.
What DDoS testing for a mobile backend is
DDoS testing for a mobile backend is a controlled test that measures how an API serving a mobile app fleet holds up when that fleet behaves at its worst: synchronised by push notifications and app launches, retrying without backoff on client code you cannot patch, and arriving from behind carrier-grade NAT where per-IP defenses lose their meaning.
The groundwork every DDoS test shares, getting authorized, bounding the blast radius, deciding what to measure, sits in the complete guide to DDoS testing and is assumed here. A mobile backend is also an API, so the cost-per-request thinking, the retry-storm mechanics, and the rate-limit keying from DDoS testing for APIs carry over unchanged, and this post leans on them rather than restating them. This post is about the five things a mobile client fleet adds on top of that: an unpatchable client, self-inflicted synchronisation, the foreground stampede, carrier NAT, and certificate pinning.
The client you cannot patch
A web frontend and a mobile app both talk to the same API, but only one of them is under your control at the moment it misbehaves.
Change a bug in web client code and every user has the fix on their next navigation. A mobile app is a binary that went through store review, downloaded once, and now runs unchanged until the user chooses to update, if they ever do. At any given time your backend is serving a spread of app versions going back a year or more, each with its own timeout values, its own retry policy, its own idea of how many parallel connections to open.
So "the client" is not a program. It is a distribution. When you reason about offered load you are reasoning about a weighted mixture of every version still installed, and the worst-behaved version in that mixture sets your floor.
The bad retry policy you already shipped
Suppose a build from eight months ago retries failed requests three times with no backoff and no jitter. You found that bug and fixed it in the current release. It does not matter. Every phone still on the old build will do the wrong thing the next time your backend has a slow minute, and you have no lever that reaches them.
How that misbehavior snowballs, one slow minute turning into a flood that feeds itself, is a general property of API clients and is covered in the API testing post. The mobile-specific point is upstream of the mechanics: the amplifier is frozen in the field. On a server you patch the caller. Here the caller is a version you deprecated and cannot uninstall.
This is why a mobile backend test has to be run against a modeled fleet, not a single well-behaved client. The interesting question is not "how does the current app behave under load," it is "what does the sum of every version still in the wild do when the backend slows down," and the honest answer includes the worst policy you ever shipped.
Push notifications are a synchronisation primitive you point at yourself
The single most mobile-specific way to knock over your own backend is to send a push notification.
A push is a message to every device at once. When it lands, a large fraction of the fleet does the same thing in the same second: it opens the app, which reconnects, refreshes a token, pulls the latest state, loads a feed. A campaign push to ten million users is a scheduled, synchronised request spike that you scheduled, aimed at your own origin, and the marketing team fired it without telling anyone in engineering.
This is different from the generic recovery herd that any system faces after an outage. Here the trigger is a control surface you own and fire routinely. Every promotional notification, breaking-news alert, live-event start, and "your order shipped" broadcast is a load event whose size and timing you chose, usually without modeling what it does to the origin.
Jitter is the fix, and most fleets do not have it
The mitigation is to smear the reaction over time instead of concentrating it. Push platforms can stagger delivery over minutes; clients can add randomised delay before their first call after a push; the backend can serve the post-push refresh from cache so the spike hits an edge, not the database.
None of that is on by default, and the client half of it, the randomised delay before the first request, lives in the app binary. So it is subject to the previous section: the version that reacts instantly is already installed on millions of phones.
The test writes itself. Model a push fan-out: N clients, a realistic version mix, each firing its opening sequence of calls within a tight window, and measure what reaches the backend at the peak. Then compare the same total volume delivered with jitter. The gap between those two curves is the load your delivery timing sheds for free, and it is usually large.
The launch and foreground stampede
Push is the loud version of a quieter, constant pattern: mobile apps are suspended and resumed constantly, and every resume is a burst of work.
The OS freezes a backgrounded app. When the user foregrounds it, the app reconnects sockets, checks whether its access token expired while it slept, refreshes it if so, and re-syncs state. One phone doing this is nothing. The whole fleet doing it inside the same few seconds, because a push landed or an outage notice went out or it is 8am on a commute, is a stampede against the exact endpoints that cost the most to serve.
Token expiry synchronises on its own
There is a subtle amplifier here that is specific to auth on mobile. Access tokens are short-lived and refreshed against a token endpoint, which is one of the most expensive endpoints you run.
If a large cohort of tokens was minted in the same burst, say, everyone who reconnected after the last big push, then that cohort expires in the same burst an hour later, and the whole cohort hits the refresh endpoint together. A synchronising event does not just cause one spike; it seeds the next one, sixty minutes downstream, on your most costly path. A test that models the fleet has to carry token lifetimes forward and let the refresh wave form on its own, rather than treating each request as independent.
The foreground herd routes back to the same containment thinking as any recovery scenario in running a DDoS test without disrupting production; what mobile adds is that the herd is triggered by device lifecycle and token TTL, not by a server event you can see coming.
Blocking by IP fails behind carrier NAT
When a mobile backend is under attack, the reflex borrowed from web incident response is to look at the top source IPs and block them. On mobile that reflex is close to useless, and it can make things worse.
Mobile carriers put enormous numbers of subscribers behind carrier-grade NAT. A whole metro's worth of LTE and 5G users can egress through a small pool of public addresses. So the "top talker" in your logs is not an attacker; it is a carrier gateway carrying tens of thousands of real customers alongside whatever abusive traffic shares it. Block that IP and you have taken a city off your service to stop a fraction of the load. Leave it and a per-IP rate limit set low enough to matter throttles all those real users at once.
The inverse breaks you too. A single device roaming between wifi, 5G, and a different cell hands off through several public IPs in a short window, and IPv6 privacy addressing rotates the client's address on a timer by design. So one user is many addresses, and many users are one address, at the same time, on the same service.
The general lesson that per-IP is a coarse key with a large blind spot is developed for APIs in the rate-limiting discipline and in the API testing post, which also covers the residential proxy pools that let an attacker deliberately spread across addresses. The mobile-specific finding is that the address blindness is not an attacker's trick here; it is the normal, unavoidable shape of consumer mobile traffic. Your legitimate fleet already looks like the thing per-IP defenses are built to catch.
So the test has to generate source distributions that mirror carrier reality: a few addresses carrying a large share of legitimate traffic, and legitimate sessions that migrate across addresses mid-flow. If your defense strategy is a list of IPs to block, that traffic shape shows you why it fails before an incident does.
Certificate pinning constrains how you can mitigate
Here is the one that surprises teams during an actual incident, because it turns a routine mitigation into an impossible one.
Many mobile apps pin their server's certificate: the app ships with a copy of the expected certificate or public key and refuses any TLS connection that does not present it. It is a sound control against a forged certificate. It also quietly removes an option you were counting on.
The standard emergency move when an origin is under attack is to put something new in front of it: swing DNS to a scrubbing center, enroll behind a CDN, stand up an edge that terminates TLS and filters before forwarding clean traffic to origin. Every one of those inserts a new TLS endpoint presenting a different certificate. A pinned client rejects it. Instead of being protected, the pinned portion of your fleet now cannot connect at all, and you have converted a partial outage into a total one for your most locked-down users.
This is an availability decision, made at build time
Pinning is usually discussed as a security control, and it is one. But the availability consequence is that your set of possible mitigations is fixed months in advance, in the app binary, by what the pin allows.
Pin to a leaf certificate and you cannot rotate it or move providers without an app release. Pin to an intermediate or to a public-key set that includes a backup key, and you keep the ability to swing traffic to a pre-provisioned mitigation edge whose key is already in the pin set. The difference between those two choices is the difference between having an incident lever and not having one, and it is decided before the incident by someone thinking about certificate security, not about DDoS response.
So this belongs in the test, not as a pinning-bypass exercise, but as a readiness check: does the pre-provisioned scrubbing or CDN path present a certificate the installed fleet will actually accept? If the answer is no, the mitigation you have on paper does not exist for the clients that pinned. Confirm it against real app builds, not against a browser.
What the test has to reproduce
Everything above turns into a specification for a synthetic client fleet, because the tidy, uniform virtual users a load harness generates by default are the one population a mobile backend never actually has to serve.
- A version mixture, not one client. Reproduce the spread of app versions in the field, including the old ones with bad retry and timeout behavior. Model the worst policy still installed, because it sets the floor.
- Trigger synchronisation. Fire a modeled push fan-out and a foreground wave: a large fraction of the fleet running its opening call sequence inside a tight window. Then let a refresh wave form on its own from the token lifetimes you handed out.
- Carrier-shaped sources. Concentrate legitimate traffic behind a few addresses, and migrate individual sessions across addresses mid-flow, so any per-IP defense is tested against the shape real mobile traffic has, not a clean one-IP-per-user assumption.
- The mitigation path, end to end. Verify that your pre-provisioned scrubbing or CDN edge presents a certificate the pinned fleet accepts, and that clients honor whatever backoff signal you send when they do not.
Two safeguards here are unique to mobile, and neither is optional. Never fire a real push at a production audience as a load test: a push is irreversible and lands on real people's phones, so the fan-out is modeled against a staging backend or a controlled test cohort, never broadcast to the live fleet. And keep anything that writes state on a staging replica: account creation, device enrollment, and push-token registration all persist records, and a few of them cost money per call. The broader discipline of keeping a test inside its boundary is the test plan and the testing checklist; what mobile adds is that some of your triggers reach real users the instant you fire them.
FAQ
What is DDoS testing for a mobile backend?
It is a controlled test of how an API serving a mobile app holds up when the app fleet behaves at its worst: synchronised by push notifications and app launches, retrying on old client code you cannot patch, and arriving from behind carrier-grade NAT where per-IP defenses lose their meaning. It reproduces that client behavior deliberately, rather than testing with a clean set of well-behaved virtual users the backend will never actually see.
How is a mobile backend different from a normal web API to test?
The backend is an API and everything about cost-per-request and rate limiting still applies. What mobile adds is the client: it is a compiled binary you cannot patch on demand, it wakes in synchronised waves driven by push and device lifecycle, and it sits behind carrier NAT and certificate pinning. Those change both the load shape you have to test and the defenses you are allowed to use.
Why can a push notification cause an outage?
A push reaches the whole fleet at once, and a large fraction of devices react in the same second by opening the app, reconnecting, refreshing a token, and syncing. That is a synchronised request spike aimed at your own origin, sized and timed by whoever sent the push. Staggered delivery and client-side jitter spread the same volume over time; without them, a routine campaign can exceed backend capacity on its own.
Why does blocking attacker IPs fail on mobile?
Carrier-grade NAT puts huge numbers of real subscribers behind a small pool of public addresses, so a "top talker" IP is usually a carrier gateway full of legitimate users. Blocking it takes real customers offline; a per-IP limit low enough to matter throttles them. At the same time a single user roams across several addresses, so per-IP keys are blind in both directions on mobile traffic.
Does certificate pinning affect DDoS mitigation?
Yes. If the app pins the origin certificate, it will reject any new TLS endpoint you insert in front of the origin during an incident, which is exactly how scrubbing centers and CDNs are usually engaged. Unless the pin set includes the mitigation edge's key, the pinned portion of your fleet cannot connect to the protected path. Pinning to an intermediate or to a key set with a backup key preserves that option; pinning to a leaf removes it.
The amplifier ships in the app store
A website's failure modes live on the server, where you can reach them. A mobile backend's failure modes are split across a boundary you do not control: half of them live in a binary on someone else's phone, running a version you cannot recall, reacting to a push you may not have coordinated, behind a network that hides who is who.
That is the real subject of a mobile backend test. Not how much traffic the origin can absorb, but how much of its own behavior it has already delegated to clients it can no longer change and events it triggers without thinking. The capacity number is the easy part. The hard part is that you shipped the amplifier yourself, months ago, and it updates on the user's schedule, not yours.