Reading bot scores on a login page without drowning in false alarms
What the score is actually scoring
The score bundles signals a single rule cannot see: request headers and their order, TLS and HTTP fingerprints, address reputation, and how the request compares with known browser behaviour. None of those signals names a bot by itself. Together they estimate how closely this request resembles automation the network has seen before. Treating the output as a probability keeps you honest about the errors at both ends.
Login pages produce the worst false positives in that model. Password managers submit forms in ways that look scripted. Privacy browsers strip the very headers the model likes to see. Older marketplace seller apps send requests with thin fingerprints. A score of 18 on a product page and a score of 18 on a login submitted by your own seller app are different events, and your rules should know it.
Bands beat thresholds
Pick three bands and give each a job. The low band, roughly 1 to 29, gets a managed challenge or a proof of work step before the login attempt is even counted. The middle band gets logged and rate limited more tightly, but allowed through. The high band passes untouched. One hard threshold, block everything under 30, will eventually block a real seller at the worst possible moment, usually during a sale event.
Bands also give you a tuning dial that a threshold never does. When a stuffing campaign starts, the low band swells first. You can respond by challenging the middle band for an hour without changing the permanent rule set, then relax it when the swell passes. That temporary posture, written down in advance, is what stops a 2am decision from becoming a week of locked out sellers.
Score the path, not just the request
A login attempt means more next to its neighbours. Ten low score attempts against ten different seller accounts from rotating addresses is a list being tested. Ten attempts against one account is a targeted guessing run. The same score, two different responses: in the first case the defence is at the endpoint level, in the second it is account level throttling and a quiet alert to the account holder before anything succeeds.
Keep a per account view beside the network view. Marketplaces that only watch aggregate traffic miss the slow attacks, the ones deliberately kept under endpoint alarms by testing a handful of pairs per account per day. Those low and slow runs are exactly what leaked credential data makes profitable, and they only become visible when attempts are grouped by the account being tried.
Log the score band, the path, the account identifier hash, and the outcome for every login, and keep it long enough to compare a normal week with an attack week. Without that history every tuning debate becomes opinion. With it you can show that challenging the low band cut successful stuffing logins while seller login completion barely moved, which is the only argument that settles whether the rule stays.
What to log so the argument ends with data
Review the bands monthly, not daily. Scores drift as browsers update and as attacker tooling copies real fingerprints more closely. A band that was safe in spring can be crowded by autumn. The review is short work: sample successful logins from the low band, sample blocked attempts from the middle, and confirm both still look like what the band claims they are.
Frequently asked questions
Keep reading: Triangulation scams: the marketplace seller who never touches the goods, Fake tracking numbers: the acceptance scan that never happens.
Frequently asked questions
What bot score should I block at on a login page?
Block on score alone as rarely as you can. Challenge the lowest band, around 1 to 29, rate limit the middle band more tightly, and let the high band through. Blocking outright on a score will eventually catch password managers, privacy browsers, and your own seller app, all of which can score badly while being legitimate.
Why do password managers look like bots to scoring models?
They fill and submit forms programmatically, often without the mouse movement, timing, and header patterns a browser produces when a person types. To a fingerprint based model that looks like automation. It is one reason challenge first beats block first on any page where account holders sign in.
How do I spot a low and slow stuffing run?
Group login attempts by account, not just by address or endpoint. A slow run shows as a steady trickle of failed attempts across many accounts, each under the per address limits, spread over days. Aggregate dashboards hide it. An account level view, plus the leaked credential flag rate, exposes it.
How often should bot score rules be retuned?
Monthly is a sane rhythm for most marketplaces. Browser releases and attacker tooling both shift what a given score means, so a rule written once quietly degrades. Sample real successes and real blocks each month and confirm the bands still separate them before you change anything.