Credential stuffing against APIs: why existing IAM controls fall short

At a glance

What this is: This is an analysis of credential stuffing against API-backed authentication and how automation, throttling, and reused credentials let attackers reach account takeover.

Why it matters: It matters because IAM and API security teams need controls that distinguish malicious login automation from legitimate traffic without breaking user experience or machine-to-machine access.

By the numbers:

• A hidden link analysis report from Recorded Future suggests that 92% of suspicious IPs are not blacklisted.

👉 Read Salt's analysis of credential stuffing attacks against API login flows

Context

Credential stuffing is a login abuse pattern that uses stolen username and password pairs rather than guessing credentials one by one. In API-driven environments, that matters because authentication and authorization are often exposed through the same interfaces attackers target, which makes identity controls part of the attack surface, not just the defence layer.

The practical problem is that the attack can look normal at scale. Automated login attempts can be throttled, distributed across cloud IP ranges, and tuned to avoid lockouts, while legitimate traffic, mobile clients, and machine-to-machine patterns make simple blocking rules unreliable. For IAM teams, this is a governance problem as much as a detection problem.

The article shows that a conventional control stack built around password reuse assumptions, rate limits, and client-side friction is brittle when attackers can blend into API traffic. That is typical of modern credential stuffing campaigns, not an edge case.

Key questions

Q: How should security teams reduce credential stuffing risk in customer login flows?

A: Start with risk-based authentication and bot detection on the highest-volume login surfaces, then add step-up controls where attack volume and account value justify the friction. Also screen for breached passwords, shorten the usefulness of exposed credentials through rapid invalidation, and correlate sign-in behaviour with downstream actions such as profile edits or payment attempts.

Q: Why do lockouts and CAPTCHA often fail against credential stuffing?

A: Attackers throttle attempts, rotate infrastructure, and shift to headless or direct API traffic to stay below obvious thresholds. Lockouts can be avoided by pacing attempts, while CAPTCHA is weaker when the attacker is not relying on a human-facing browser. These controls help, but they do not provide reliable detection on their own.

Q: What signals indicate credential stuffing is succeeding before account takeover occurs?

A: Watch for repeated login attempts from distributed sources, unusual success and failure patterns, and post-authentication actions that do not match the account's normal behaviour. A valid login is only the midpoint. The earliest reliable signs often appear in session behaviour, token use, and downstream API calls.

Q: Who is accountable when credential stuffing leads to account takeover?

A: Accountability typically sits with the organisation that controls the authentication system, because it owns the risk decisions around MFA, password policy, detection, and abuse response. Regulators and auditors increasingly expect documented controls for access management and incident handling. For sensitive accounts, the relevant standard is not whether the user behaved perfectly, but whether the organisation made takeover materially harder.

Technical breakdown

How credential stuffing differs from brute force against APIs

Credential stuffing does not try random password combinations. It reuses real username and password pairs harvested from prior breaches, then drives them through login APIs at volume. Because the credentials once worked somewhere else, the attacker is testing identity reuse rather than password strength. That makes success dependent on user behaviour and the organisation's control design, not on guessing complexity. In API environments, this is especially effective because login flows are often built for speed and availability, which gives attackers room to distribute attempts and blend into ordinary authentication traffic.

Practical implication: treat reused credentials as an identity risk signal and not just a password hygiene problem.

Why lockouts, CAPTCHA, and IP deny lists fail under automation

Traditional defences assume a visible, repeatable attack pattern. Credential stuffing campaigns are often throttled, rotated across IP addresses, and tuned to avoid triggering account lockouts or rate limits. CAPTCHA helps only when the attacker must solve a browser challenge, but it is weaker against headless automation and direct API calls. IP deny lists also degrade quickly because cloud hosts and residential proxies make source addresses disposable. The result is a control gap between what the defender can easily measure and what the attacker can easily change.

Practical implication: do not rely on one control layer to stop automated login abuse across distributed API traffic.

Why behavioural analytics is the core control for credential stuffing

Behavioural analytics works by building a baseline of normal activity across users, devices, and APIs, then flagging deviations such as unusual login cadence, abnormal token use, and data movement that follows a successful authentication event. In practice, this shifts defence from static rules to context-aware detection. It is most valuable where application traffic is naturally high and where legitimate automation makes simple allow and deny logic too noisy. For identity teams, the mechanism matters because the attack often ends at authenticated context, which is where many perimeter-style controls stop looking.

Practical implication: baseline authentication, token, and post-login behaviour together so account takeover is visible before abuse spreads.

Threat narrative

Attacker objective: The attacker wants authenticated access that can be monetised through account takeover, downstream data theft, or abuse of application functionality.

1. Entry begins with attackers collecting stolen username and password pairs from prior breaches and selecting high-value login APIs to test.
2. Escalation occurs when automated login attempts are throttled, distributed across cloud sources, and tuned to bypass lockouts and rate limits until one set of credentials succeeds.
3. Impact follows when the attacker obtains authenticated session access and pivots to account takeover, data exfiltration, or further abuse of application functionality.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential stuffing is an identity reuse failure, not a password strength problem. The attack succeeds because organisations still treat reused credentials as a user mistake rather than a systemic identity exposure. Once stolen pairs can be replayed through API-backed login flows, authentication becomes a probabilistic filter instead of a trust boundary. Practitioners should therefore frame the problem as account integrity and session abuse, not just authentication failure.

API login paths have become the preferred control bypass because they were built for scale, not scrutiny. The article shows how attackers use throttling, distribution, and traffic blending to stay below the threshold of traditional rate limits. That means the security model is failing at the point where identity, application logic, and transport behaviour intersect. IAM teams need to treat login APIs as governed attack surfaces, not merely functional endpoints.

Behavioural baselining is the named concept that matters here. Static controls assume a fixed attacker pattern, while credential stuffing adapts around lockouts, CAPTCHAs, and IP blocks. Baselines that correlate login cadence, token use, and post-authentication actions are the only controls that preserve signal when traffic volume is high. The practitioner conclusion is simple: if you cannot distinguish normal API identity behaviour, you cannot reliably detect account takeover.

Credential stuffing is also a governance problem for machine-to-machine environments. The article notes that device fingerprinting and user profiling do not work well in direct API communications. That exposes a broader assumption: many identity controls still depend on browser-visible human behaviour. As more access moves through APIs, the boundary between human IAM and NHI-related authentication abuse becomes operationally blurred, so teams need shared visibility across both domains.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader lens on recurring identity failure modes, see the 52 NHI breaches Report for breach patterns and root cause detail.

What this signals

Credential stuffing is becoming an identity governance test, not just a fraud or abuse problem. When attackers can replay compromised credentials through API login flows, the controls that matter are the ones that observe behaviour after authentication. The governance lesson is that login success no longer proves trust, especially when the same account may be legitimate in one context and compromised in another.

Behavioural baselining should now sit alongside account policy as a core identity control. If the organisation cannot distinguish ordinary API traffic from automated login abuse, the rest of the detection stack will be noisy or late. That is why API security and IAM teams need shared telemetry, not separate views of the same authentication event.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, identity exposure is no longer limited to first-party accounts. The same visibility gap that hides risky NHI connections also makes replayed credentials harder to detect across distributed login paths. Practitioners should prepare for a unified abuse model that spans human accounts, machine access, and delegated application identity.

For practitioners

• Baseline authentication behaviour across APIs Measure login cadence, source diversity, token reuse, and post-login activity so you can separate normal authentication patterns from automated credential replay. Use those baselines to tune detections before account takeover reaches downstream systems.
• Reduce credential reuse exposure Require unique usernames where possible, prioritise MFA for sensitive applications, and monitor for compromised credential pairs that match active accounts. This reduces the value of breached password lists and narrows the blast radius of reused identities.
• Treat login APIs as high-risk attack surfaces Apply stronger anomaly detection and tighter abuse monitoring to authentication endpoints than to ordinary application traffic. Attackers target the login path because it offers the fastest route to authenticated context.
• De-emphasise brittle source-based controls Use IP deny lists, CAPTCHA, and regional rate limits only as supporting controls, not primary defences. Cloud infrastructure, headless browsers, and proxy rotation make these measures easy to work around.
• Instrument post-authentication abuse signals Alert on abnormal data movement, token manipulation, and unusual API parameter changes after a successful login. Credential stuffing is only the first step; the real loss often happens after the session is established.

Key takeaways

• Credential stuffing succeeds because reused credentials and automation let attackers turn API login flows into an account takeover channel.
• Static defences such as lockouts, CAPTCHA, and IP blocking are easy to evade when attacks are throttled and distributed across disposable infrastructure.
• Behavioural baselining and post-authentication monitoring are the controls that most directly change detection and containment outcomes.

Key terms

• Credential Stuffing: Credential stuffing is an attack that uses stolen username and password pairs from previous breaches to try logging into other services. It works because many people reuse credentials, and because the login attempt uses valid information, it can look ordinary until the surrounding behavior gives it away.
• Account Takeover: Account takeover is unauthorized use of a legitimate account after an attacker obtains valid access through stolen credentials, tokens, or trusted integrations. The key security problem is that the resulting activity often looks normal to logs and controls, which makes containment and attribution harder than in a forced-entry breach.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• API Authentication Surface: The API authentication surface is the set of login, token, and session endpoints that establish identity for an application. It is where identity governance becomes operational, because attackers can abuse the same endpoints that legitimate users and services rely on for access.

What's in the full article

Salt's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step attacker workflow for recon, credential compilation, throttling, and login execution against APIs.
• Defensive guidance on behavioural analytics, MFA, CAPTCHA, device fingerprinting, and IP-based controls in practice.
• Examples of how detection context and incident timelines help teams respond faster to account takeover attempts.
• Salt's explanation of how its platform correlates user and machine behaviour across API activity.

👉 The full Salt article covers the attack sequence, defence trade-offs, and API security detection context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.