---
title: "The Filter Couldn't Tell Us From an Attacker, So It Blocked Us"
canonical: https://dxdev.com/blog/2026-06-15_the-filter-that-couldnt-tell-us-from-an-attacker/
datePublished: 2026-06-15
---
# The Filter Couldn't Tell Us From an Attacker, So It Blocked Us

The office lost access to its own admin panel late one morning. Not a customer. Not someone else's system going down somewhere out of our control. Us, locked out of the tool we needed to fix the thing that had just locked us out.

The cause turned out to be something running entirely inside the building: an internal tool doing routine page checks against our own sites, moving fast enough to cross about fifteen hundred requests in a day from one address. That address happened to be the office's own. The automated filter watching for scrapers and credential-stuffing attempts saw exactly the pattern it was built to catch, high volume from a single source, and did its job. It blocked the address.

That's the part worth sitting with. The filter wasn't broken. It wasn't confused. Fifteen hundred fast requests a day from one address is a completely reasonable signal for "this might be a bot." The rule fired correctly, on correct logic, against the wrong target, because the rule only had one thing it could measure: how much traffic came from where. It had no second question to ask, like "do we already know and trust this address," that could have told a legitimate internal tool apart from an actual attacker running the identical pattern.

Fixing it took longer than it should have, partly because there was an unrelated migration happening around the same time and that had to be ruled out first as a possible cause. The real answer was sitting in a database, not a log file, so getting to it meant querying the filter's own ban records directly to confirm the trigger reason and the timing lined up with the internal tool's activity. Once that was confirmed, the fix was adding the office's address to an allowlist inside that same database, not slowing the internal tool down. The tool was doing legitimate work. Throttling it would have treated the wrong side of the problem.

The part that stuck with me afterward wasn't the lockout itself. It was realizing that the exact same trap was still open for the next piece of internal tooling. Any future tool that ramps up its own traffic against the company's sites, for a perfectly good reason, will trip the identical rule, because the rule still only knows volume. Nothing about fixing this one lockout taught the filter what else it should already trust.

## If your systems have an automated block or throttle

Ask what single number that rule is actually watching, request rate, failed logins, error count, whatever it is. Then ask honestly whether anything you already run internally, a monitoring tool, a QA script, a bulk job, could plausibly cross that same number on a normal day. If the rule has no way to tell your own infrastructure apart from a stranger doing the same thing, it isn't protecting you from that gap. It's just waiting for the day your own tools trip it.