A store was under an automated card-testing attack — scripted checkout attempts repeated over hours, using the payment form to find live card numbers. Real cost, real urgency, and a decision needed quickly.
Two mitigations were available, and one was a single toggle in the CDN dashboard: turn on automated bot filtering. Fast, free, and exactly the sort of thing an urgent situation makes attractive.
We installed and tuned fraud-order blocking at the application layer, lowering the threshold for repeated failed attempts from a permissive default to a tight one. The attack pattern stopped being viable, and the site's response time improved substantially as a side effect of no longer processing the attempts.
And we advised against enabling the bot filtering — the more valuable half of the recommendation.
The store had live inbound API consumers: a shipping platform, an inventory synchroniser, and a product-data service, all legitimate automated traffic authenticating against the store all day. Bot filtering does not distinguish between an attacker's script and a partner's integration. Switching it on would very likely have challenged those integrations and broken fulfillment, inventory accuracy, and product data — in order to stop an attack that a targeted application-layer control had already stopped.
Nobody would have connected the two events. The attack would have ended, the toggle would have been credited, and days later somebody would be debugging why orders had stopped syncing.
We also reported the mitigation that did not work
A rate-limiting rule was attempted at the CDN and could not be deployed on the account's plan tier. Rather than presenting the partial result as complete, we said so — and noted that at the observed attempt rate the attack was probably distributed anyway, so a per-address burst limit would not have stopped it even if the plan had allowed it.
And one thing we broke, briefly
During this work an upload landed in a web-served directory, making an archive publicly reachable. We found it on our own read-back, overwrote it immediately, verified the origin was returning zero bytes, and purged the CDN cache. It is in this case because the read-back is the point: reading a value back after writing it is the only reason that was minutes rather than months — and a firm that only shows you its clean work is not showing you how it operates.
The second-order effect is where the damage lives
Most bad technical decisions are not wrong in isolation. They are correct fixes applied without knowing what else depends on the thing being changed. Knowing which integrations authenticate against a system — before touching its front door — is not caution. It is the job.
Client, vendor, product and industry details are removed, along with any figures belonging to the client. The technical detail is unchanged. This shows how we work — it is not a claim about a business result, which would require the client’s consent and a baseline measured before the work began.