Credential stuffing shows up in logs as many different accounts attempted from one source or a tight cluster of sources, with a low success rate and bot like timing. Log every login attempt with account, source and outcome, then watch failures per source, accounts per source and success after failure.
Definitions first
OWASP defines credential stuffing as testing username and password pairs obtained from the breach of another site. It differs from brute force, which tries many passwords against one account, and from password spraying, which tries one weak password against many accounts.
The log patterns differ too, which is why a single rule for failed logins per account misses stuffing. Each account sees only one or two attempts. The signal is across accounts.
What to log on every attempt
You cannot detect what you do not record. Following the OWASP logging guidance on authentication events, capture:
- Timestamp in UTC.
- The account identifier used, or a keyed hash of it if you want to limit exposure.
- Outcome: success, failure, locked, MFA required, MFA failed.
- Verified client IP, as covered in which client IP to log behind a proxy.
- User agent and, if you have it, a device or connection fingerprint.
- Request ID.
Never log the password, even when it was wrong. A mistyped password is often a real password for another site.
Signals OWASP lists
The OWASP Credential Stuffing Prevention Cheat Sheet names these detection signals:
| Signal | What to query |
|---|---|
| One IP attempting many accounts | Distinct accounts per source over 10 minutes |
| Login from a new browser, device or IP | First seen device or address for the account |
| Unusual country or location | Geography change since the last success |
| IP tied to proxy, VPN or hosting ranges | Join with an IP classification list |
| Bot like volume from one IP or subnet | Attempts per minute per source and per subnet |
| Client claims do not match connection | Mobile user agent with a script like connection signature |
| Headless browser indicators | User agent and header patterns |
The sheet also reminds teams to look for low volume traffic spread across many IPs, so thresholds should cover short bursts and long periods alike.
A simple first set of queries
- Failures grouped by source over 15 minutes, flagging sources that touch more than a set number of distinct accounts.
- Success after several failures from the same source on different accounts, which suggests a hit.
- Logins succeeding from a never seen device right after a burst of failures elsewhere.
- Overall failure ratio compared with the same hour last week. A sharp rise is a campaign even when no single source stands out.
Tune thresholds on your own traffic. Offices and mobile carriers share addresses, so a busy legitimate network can look like an attacker.
Responding
OWASP calls multi factor authentication the best defense and recommends graduated responses rather than one fixed volume limit. It says IP blocking alone is insufficient and blocks should be temporary. It also suggests notifying users about meaningful events, such as a correct password followed by a failed MFA check, and letting them review recent logins and active sessions.
For breached accounts, force a reset and invalidate sessions. See authentication events to log for the full list.
Quick check
How is this different from brute force detection?
Brute force concentrates on one account. Stuffing spreads across many accounts, so group by source and by outcome, not only by account.
Is rate limiting enough?
No. OWASP does not treat it as a standalone control. Combine it with MFA, device signals and monitoring.
Safeguard does not replace your login monitoring, but its SBOM and dependency scanning keeps the authentication libraries you rely on checked. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
