TL;DR: Broken authentication in APIs lets attackers brute-force, stuff, or crack credentials, then take over accounts or machine sessions and reach whatever data the identity is entitled to access, according to Salt. The security problem is not just weak passwords but authentication flows that lack granular protection, sequencing checks, and rate-aware detection.
NHIMG editorial — based on content published by Salt: Authentication in APIs is a complex topic with broken authentication attack patterns
By the numbers:
- 70TB of data was scraped before the platform, platform was shut down on January 11, 2021.
- Broken authentication is the second most critical API security threat listed in the OWASP API Security Top 10.
Questions worth separating out
Q: How should security teams protect API authentication flows from brute-force and token guessing?
A: Treat authentication endpoints as high-risk identity services.
Q: Why do broken API authentication controls create such a large breach risk?
A: Broken API authentication is dangerous because a valid caller can be accepted before any deeper control has a chance to stop abuse.
Q: What do security teams get wrong about API perimeter controls?
A: They assume syntax inspection and request reputation are enough.
Practitioner guidance
- Harden authentication endpoints separately Apply additional protection to API authentication routes, including stricter rate limits, abuse detection, and flow-specific policy.
- Validate authentication sequence and context Build controls that detect missing credentials, out-of-sequence calls, and abnormal step order across the authentication flow.
- Reduce credential guessability and reuse Replace weak reset tokens, low-entropy secrets, and long-lived authentication material with stronger token design and shorter exposure windows.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- A closer walkthrough of broken authentication patterns in API design, including token guessing and reset-flow abuse.
- Specific examples of authentication misuse across web, IoT, and cloud-native API contexts.
- The article's full discussion of why traditional controls like WAFs and gateways miss sequence-aware attack behaviour.
- Salt's explanation of how to profile normal authentication sequences using production API traffic.
👉 Read Salt's analysis of broken API authentication and attack paths →
Broken API authentication: what IAM teams need to fix first?
Explore further
API authentication is now an identity governance problem, not only an application security problem. The article shows that broken authentication can expose user accounts, but the same control failure also exposes machine identities and workload sessions. That matters because IAM programmes often stop at provisioned identity and do not govern the authentication sequence itself. Practitioners should treat API auth flows as governed identity paths, not just application features.
A few things that frame the scale:
- 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, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: How do IAM and NHI teams know if API authentication is actually working?
A: Look for more than successful login counts. Check for low rates of reset-token enumeration, no repeated out-of-sequence calls, strong credential entropy, and rapid revocation of retired integrations. If authentication failures are rising or abuse patterns are repeating, the flow is likely being shaped by attackers rather than governed by policy.
👉 Read our full editorial: Broken API authentication exposes machine and user identity risk