Advanced Business Logic  Attack Techniques : Fail-open Bot Attacks

"Fail-open" in Real Life

Let's say you're planning an extended family vacation abroad. After your neighbors warn you about recent break-ins in the neighborhood, you decide to upgrade your security. To ensure you have a worry-free trip, you install a smart lock on your main door that uses facial recognition and alerts you every time the door is opened. You set it to open the door only to one family member.

A standard burglar might try to break the door or print a silicone mask that resembles one of the family members. The problem is that in both scenarios, you will immediately detect the break-in through the smart lock's app.

However, a more sophisticated thief operates differently. They might come to your main door at night and test the new lock without attempting to break in. After a few nights, they discover that tapping the camera's eyepiece six times triggers a shutdown. When this happens, the lock assumes there's a technical malfunction and opens to prevent a scenario in which family members are locked out of the house.

The burglar takes advantage of this to steal everything in the house. While you are on vacation, you receive a push notification that the camera has not been working for six seconds. You assume it's a temporary glitch caused by heavy rain. This is exactly what bot operators do when they launch a fail-open attack on your website or mobile application.

In this blog, I'll uncover ways bot operators disguise their bot attacks as a system bug to bypass your bot detections--and how you can identify this scenario when it happens to you.

Keep this image of the crafty burglar handy! We'll keep revisiting it as we explore how fail-open logic can turn helpful safeguards into unguarded entrances for automated threats.

1. Fail-open 101: Availability Safeguard = Critical Weakness

What does "fail-open" mean?

Just like the smart lock, which automatically opens once it loses connection to the camera, many security controls have a built-in graceful degradation switch: If something goes wrong and the error rate of the sensors surpasses the defined threshold (for example, 5% of the traffic), the anti-bot detections are shut down, allowing traffic to pass through so customers aren't locked out of their accounts. This is "fail-open." The opposite, "fail-secure," blocks everything until an admin or DevOps engineer intervenes.

Why does fail-open exist?

• Uptime SLAs - Businesses are more aware of the risk of false positives that might lock out paying or potential customers than they are of this type of business logic exploitation. Therefore, uptime can become a priority over security.
• Customer experience & brand image - A checkout that crashes during Black Friday can cost millions in minutes. Blocked users often complain on social media platforms, which can escalate the situation into a PR crisis.
• Legacy expectations - Early web defenses were primarily tuned for availability, rather than automated abuse.

Burglar callback: Your smart lock's designers programmed it to open if the camera appears to be broken. Their priority was saving a stranded family, not stopping a genius burglar.

2. Attack Preparations

Phase 1: Traffic Pattern Research – Threat actors utilize marketing tools that analyze web traffic, user base and geo data. They identify when the traffic is at its lowest peak (typically at night), when the testing of the attack and the attack itself usually occur. This maximizes the threat actor's chance of hitting the fail-open trigger threshold. The below-threshold stat is arbitrary, as the optimal attack window varies between applications.

Phase 2: Account Reconnaissance Strategy – Threat actors collect dozens of "aged accounts" (active for at least six months). These accounts tend to be less observed by the security and fraud team, which usually focuses more on new accounts.

Phase 3: Error Threshold Discovery – The threat actors test, research, and map the application's Business Logic in the context of fail open using bots that run on existing and new accounts (A/B testing): how to generate sensor errors, and many of them are needed to trigger the fail open state.

3. How Bot Operators Trigger FailOpen

After following the above preparation steps and using the data points collected, the threat actor can move to the attack itself:

Phase 4: Error Flooding – At the optimal hour, the threat actor floods the login API with quirky headers, rare user agents, or malformed calls until the bot manager module reports excessive errors.

Phase 5: Fail Open Activation - Once the error rate suppresses the fail-open trigger threshold, the security component degrades into "monitor-only" or "bypass mode" to protect site availability. The first step of the attack is now complete.

Phase 6: Follow-Up Attack - The threat actor launches the main bot attack, initiating account takeover, scraping inventory prices, buying limited stock inventory (scalping) or similar.

Another example of a fail-open attack is exploiting a lack of input validation or rate limiting:

• The bot operator runs tests using bots targeting a specific platform.
• After several days, they figure out the target doesn't limit the UA string's max length.
• They send requests with a user-agent string 14 times longer than the standard, causing a UA parsing error in the bot-detection sensor.
• Since many detections rely on UA and incoming sessions lack UA, the detection failure rate increases.
• When this error rate reaches 5% of the traffic, fail-open is triggered.
• By now, the bot operator can run the attack itself, whether it's an account takeover (credential stuffing) or crawlers.

4. Why Detection Is So Hard

1. It's supposed to happen. Fail-open is an intentional design decision, not an overlooked coding mistake.
2. Operational blind spots. Availability alerts often route to the Ops team; security analysts may never see that the bot filter is in bypass mode.
3. Healthy-looking metrics. Once in fail-open mode, every fraudulent request returns an HTTP 200. Dashboards show "green."
4. Post-incident ambiguity. Logs capture when the control switches off, but rarely capture the reason why, leaving responders to guess.

Burglar callback: You received a harmless-looking push notification saying something like "camera offline for six seconds". Without full context, you shrugged it off. Similarly, many SOCs do the same when a bot manager quietly logs "fallback mode active."

5. Mitigation & Good Practices

Below is a plain-language action list you can share with security, DevOps, and product teams:

1. Train. Teach your security team and developers about fail-open attack vectors. It's nearly impossible to detect a threat you’re unaware of. These attacks are stealthy because developers and SOC analysts often misclassify fail-open logs as technical issues rather than cyberattacks. Repeated fail-open incidents might be triggered by threat actors testing defenses and should raise a red flag, prompting a quick and efficient investigation.
2. Build visibility. Build a dashboard that covers all fail-open errors and related errors that might trigger them, ensuring both teams have complete visibility on this dashboard.
3. Log context, not just state. Capture reason codes (e.g., "captcha error surge," "latency spike") to shorten forensic timelines.
4. Use progressive enforcement, not a binary on/off approach. When suspicion rises, tighten rate limits or step up user verification—don’t open the floodgates.
5. Blend signals. Network telemetry shows volume anomalies; server-side behavior analytics catch business logic abuse that looks "normal" to the edge.
6. Simulate the burglar. Conduct red-team drills that intentionally trigger fail-open scenarios to expose monitoring and process gaps. The only way to identify your blind spots is to search for them actively.

What's Next in This Series

This blog is the first in a series of three that sheds more light on advanced bot business logic techniques. In part 2 of this series of advanced business logic attack techniques, we'll explore how sophisticated bots disguise their identity as legitimate bots like search engines and AI tools to bypass all bot detection completely. I'll also look at ways you can identify those bots. Follow the Radware CTI blog to stay informed by Radware bot researchers.