Attackers are evolving their tactics and finding new ways to impersonate real users. And these don’t look like bots or fake devices, but near-perfect copies of legitimate traffic. One emerging tactic involves replaying payloads captured from real users to bypass fraud checks and slip past defenses undetected.
Ingress Replay Protection closes that blind spot. Fingerprint now remembers the unique signatures of each incoming request for a short window and quietly flags any attempts to reuse them. If a request looks identical to one we've already seen, you’ll see a simple replayed: true flag with no new code and no extra latency.
For security-first teams in banking, fintech, and other high-risk industries, this early warning is gold: It enables real-time fraud detection and sharper risk scoring because even the most polished impostors can’t slip through by reusing captured data.
A rising threat you can’t ignore
Since JavaScript runs in the browser, attackers can sometimes capture requests sent by real users. Here’s what a Fingerprint replay attack looks like in practice: an attacker sets up a client-side proxy (or uses another method to capture network traffic), records the entire POST / signal identification payload from a legitimate browser, then re-sends that payload to our signal ingress endpoint. Because the data is genuine, they obtain the same visitorId and clean Smart Signals, letting them skate past bot, VPN, and browser tampering checks.
Some of our most security-conscious customers have flagged this as a growing threat. Since this kind of attack targets our backend endpoint rather than your application, it's not something you can solve on your own.
That’s why we’ve built Ingress Replay Protection: to identify and flag when a signal payload has been reused, and help you act on it.
What the signal reveals
When Fingerprint detects a likely replay attack based on unique signals in the request, we return a replayed: true flag in the full event data, whether you're accessing it through Sealed Client Results, the /events API, or webhooks.
This signal is built for real-time decisioning, which gives you immediate visibility into suspicious payload reuse so you can act fast. Teams use it to block or challenge risky requests as they happen, feed real-time risk scoring models with a high-confidence indicator, and trigger alerts when replay behavior is detected during high-value actions. By incorporating security features like this into your authentication or transaction flows, you can respond to threats before they cause harm.
How it works
Fingerprint generates and stores a short-term cache of identifiers found in incoming POST / payloads, such as unique signal hashes or synthetic paths. It then checks for reuse across sessions.
If the same unique signal is used more than once in a suspicious pattern, the request is flagged with replayed: true.
This detection is:
- Fast — designed to run without adding meaningful latency
- Secure — keeps attacker insights minimal
Note: This feature does not block the request by default. Instead, it gives you full visibility into potential abuse, allowing you to decide how to handle it. Think of it as an intelligent alert, not a hard gate. We chose this approach to limit the information available to the attacker. Because the flag isn’t exposed, it allows customers to react silently, without prompting the attacker to modify their techniques.
Example
{
"products": {
"identification": {
"data": {
"visitorId": "Ibk1527CUFmcnjLwIs4A9",
"requestId": "1708102555327.NLOjmg",
"replayed": true
// .. other information and Smart Signals
}
}
}
}In this case, an attacker may see a valid visitorId and requestId on their end — but the receiving system detects the reuse and flags it with replayed: true, giving customers visibility into the replay attempt.
Learn more
Want to dive deeper into how we detect replay behavior and how you can use it in your fraud strategy?
