Firebase App Check has quietly shipped one of its more important security upgrades this year: replay attack protection through one-time-use tokens. Instead of a client presenting a reusable App Check token on every request, an app can now call getLimitedUseToken() to fetch a token that’s consumed the moment your backend verifies it. Once spent, it’s dead — a captured or intercepted token can’t be replayed against the same endpoint to rack up free API calls or drain a rate-limited quota.
That’s a meaningful hole closed, but it’s also a new blind spot if you don’t instrument it. Baseline App Check enforcement tells you whether a request came from your genuine app; it doesn’t tell you when someone tried to reuse an already-spent token, how often that’s happening, or which endpoints are actually attracting replay attempts versus which ones enabled the stricter mode for no measurable benefit. Teams that flip on replay protection without tracking its outcomes end up with a security control they can’t evaluate — they don’t know if it’s working, and they don’t know if the added latency on every verified call is worth the coverage.
Data Points to Track
- Replay rejection count and rate: how many verification attempts fail specifically because a token was already consumed, per endpoint, per day
- Consumption-to-verification latency: the added round-trip time
getLimitedUseToken()and server-side consumption introduce, so you can weigh security gain against user-facing delay - Endpoint coverage map: which callable functions and custom backend routes have replay protection enabled versus standard App Check only
- Repeat-offender signals: device or session identifiers associated with multiple replay attempts, which often indicate a compromised token source rather than a one-off network glitch
- Fallback/error path hits: how often a legitimate client fails a replay check due to retries or duplicate requests from flaky connections, so you can distinguish real attacks from client-side retry logic gone wrong
Setup Steps
- Identify your highest-value endpoints first — anything tied to paid quota, write access, or sensitive data — and enable replay protection there before rolling it out app-wide.
- Instrument
getLimitedUseToken()calls on the client to log token acquisition alongside the existing App Check verification events already in your pipeline. - Log the consume-and-verify step server-side, capturing both successful single-use verifications and rejections from already-spent tokens as distinct event types.
- Add a latency metric around the verification call, since replay protection adds a network round trip — you want this visible before it shows up as an unexplained regression in API response time dashboards.
- Set an alert threshold on replay-rejection rate per endpoint, so a sudden spike — a likely sign of active token interception — surfaces immediately instead of waiting for the next quota bill.
Actionable Insights
A near-zero replay-rejection rate across weeks is useful confirmation that your baseline App Check setup was already holding, and tells you which endpoints you could safely leave on standard protection rather than paying the latency cost everywhere. A rate that’s low but non-zero and concentrated on one or two endpoints usually points to a specific integration — a webhook, a third-party client, a cached build — replaying stale tokens, worth chasing down individually rather than dismissing as noise.
The latency data matters just as much as the security data: if the added round trip is invisible against your existing response times, there’s no reason not to expand coverage; if it’s measurably slowing your busiest endpoint, that’s a real tradeoff to make deliberately rather than one that quietly settles in production because nobody measured it before shipping.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert