Credential Stuffing on APIs: Detection Signals That Work

Every data breach adds to a growing arsenal. Attackers collect leaked username and password pairs and replay them against other services. Because people reuse passwords, this works more often than you would expect. This is credential stuffing, and your login API is the target.

How do you detect credential stuffing on an API?

Look across accounts, not at one account. Credential stuffing looks like many ordinary failed logins spread across many accounts, often one attempt each. Watch the login endpoint for failures spread over many usernames from the same sources, a rise in unknown usernames, anonymiser traffic, and the occasional success hidden inside a run of failures.

How credential stuffing works

The attack is simple. Attackers obtain credentials from breaches, freely shared or bought. They automate login attempts across many sites. When a pair works, they have taken over an account.

The lists are large and cheap. Automation tests them quickly, so even a tiny success rate across a large list yields a meaningful number of compromised accounts. MITRE catalogues the pattern as CAPEC-600.

APIs make it easier. No CAPTCHAs, no JavaScript challenges, consistent response formats. API login endpoints are a preferred target over web forms.

Stuffing vs spraying vs brute force

Credential stuffing, password spraying and brute force are often conflated. They are different attacks, and each leaves a different shape in your logs.

	Credential stuffing	Password spraying	Brute force
What the attacker has	Real username and password pairs leaked elsewhere	A list of usernames and a few common passwords	One target account
Pattern	Many accounts, usually one password each	Many accounts, the same password across all of them	One account, many passwords
Failures per account	One or two	One per round of passwords	Many
What gives it away	Failures spread across many usernames, many unknown usernames, a few successes	The same password tried against many accounts, in slow waves	Repeated failures on a single account
Catalogued as	CAPEC-600	CAPEC-565	CAPEC-49
First defence	Multi-factor authentication and breached-password checks	Block common passwords; multi-factor authentication	Account-level throttling and lockout

This distinction matters for detection. Brute force trips “too many failed logins for user X”. Credential stuffing may show only one or two failures per account, across thousands of accounts. Per-account limits never fire.

Password spraying against an API is quieter still. The attacker tries one common password against every username, waits, then tries the next. Each account sees a single failure per round, so the signal only appears when you count failures for the same password across accounts.

Detection signals that work

Effective detection looks for patterns that separate automated attacks from real users. These signals work on any API:

• Failure distribution. Failed logins spread across many usernames rather than concentrated on one.
• Unknown usernames. A rise in attempts against accounts that never existed. Leaked lists come from someone else’s user base.
• Velocity and rhythm. Steady, mechanical request rates. People are irregular; scripts are not.
• Source reputation. Hosting providers, anonymisers and addresses already known for abuse.
• Client fingerprints. Missing user agents, or the same user agent across thousands of requests.
• Success inside failure. A login that succeeds within a run of failures from the same source. Check that account first.
• What happens next. A new session that immediately changes the email address, password or payout details.

Set your limits from your own baseline. A fixed number that suits one login endpoint fails on another, and a published number tells attackers how slowly to go.

Signals that mislead

Some legitimate traffic looks like an attack at first glance. Know these before you tune anything:

• Shared addresses. Corporate networks, mobile carriers and universities put many real users behind one address. Failures from one address across many accounts can be a busy office on a Monday morning.
• Password changes. After a forced reset, saved passwords in browsers and apps fail in a burst until people update them.
• Launches and campaigns. A marketing push or an app release can double login volume in an hour.
• Integrations. A partner’s service account retrying with an expired secret produces steady, mechanical failures.

Counting failures across accounts and comparing them with each endpoint’s own baseline keeps these from becoming false alarms, without letting a real attack hide among them.

What Cyron watches on your login endpoints

Cyron API Security names these attacks as detections: brute force, credential stuffing and password spraying, alongside JWT attacks, tokens in URLs and leaked tokens. Behavioural intelligence adds per-endpoint baselines and 13 session-level rules, on Essential and above, including authentication probing, credential stuffing and rate abuse.

Anonymiser traffic on login endpoints is flagged. Cyron draws on seven supported threat-intelligence feeds, and an address is marked malicious only when sources agree. Thresholds stay unpublished.

Credential stuffing sits under API2, broken authentication, in the OWASP API Security Top 10 checklist.

Prevention layers

No single control stops credential stuffing. Effective defence combines several layers.

Rate limiting. Cap login attempts per address, per account and per time window. Make bulk testing slow and expensive.

Account lockout. Temporarily lock accounts after repeated failures. Balance security against denial of service, because attackers can lock out real users on purpose.

Multi-factor authentication. Stolen passwords become useless when a second factor is required. Prioritise it for high-value accounts.

Breached-password checks. Check new passwords against known breach lists, and tell users when their credentials appear in one. The OWASP Credential Stuffing Prevention Cheat Sheet covers this and more.

Bot detection. Analyse request patterns for automation, and challenge suspicious traffic where your clients can respond.

Response playbook

When you detect credential stuffing, respond in order.

Immediately: Block the attack sources. Watch authentication endpoints more closely.

Short term: Find accounts that may be compromised: successful logins from attack sources. Force password resets for them. Review recent activity on each.

Communication: Tell affected users. Recommend password managers and unique passwords.

After the incident: Study the attack pattern to improve detection. Check how well each control held. Update rate limits based on what you observed.

Why APIs need specific protection

Web applications can add friction: CAPTCHAs, JavaScript fingerprinting, invisible challenges. APIs can’t. They are built for machine-to-machine traffic.

That makes behavioural analysis essential. Without visual challenges, detecting credential stuffing relies on traffic patterns, request timing and anomaly detection across accounts.

Traditional WAFs see individual HTTP requests but miss the patterns that separate legitimate API traffic from automated attacks. Purpose-built API security fills that gap.

Steps you can take today

1. Count failed logins per source across all accounts, not only per account.
2. Track the share of login attempts against usernames that do not exist.
3. Add breached-password checks at sign-up and password change.
4. Turn on multi-factor authentication for administrators and high-value accounts.
5. Write the response playbook above into your on-call runbook.

Stop credential stuffing at your API

Cyron API Security detects credential stuffing, password spraying and brute force on live traffic, out of band, with no code changes.

Start free

Updated 1 October 2026: new title, a stuffing vs spraying vs brute force comparison, the detection signals by name and current product details.