Broken authentication refers to vulnerabilities in API authentication mechanisms that allow attackers to impersonate users, access sensitive information, or perform actions as another user. This can stem from improper validation, weak credential management, or lack of security controls such as rate limiting or multi-factor authentication (MFA). Examples include APIs that allow brute-force attacks, use weak token validation, or do not enforce password policies.

In this lesson, you will learn how broken authentication can compromise an API's security. You will explore how attackers exploit these vulnerabilities, understand the technical causes, and implement effective mitigation strategies to secure your APIs.

Meet Eva, a software engineer at an e-commerce company. She is testing an API that handles user logins. During testing, she discovers that the API allows unlimited password attempts without account lockout or rate limiting. Let's take a look!

Let's break down the bash script above

Eva’s findings revealed several critical vulnerabilities within the API, with the lack of rate limiting being a major issue. However, the investigation also uncovered other significant flaws that could compromise the system’s security.

Weak token validation

The API demonstrated weak token validation by accepting expired or unsigned JWTs. This flaw exposes the system to the risk of session hijacking, where attackers can impersonate legitimate users and gain unauthorized access to sensitive data or operations.

Unencrypted password transmission

Passwords were being transmitted over plaintext HTTP instead of the secure HTTPS protocol. This practice leaves user credentials vulnerable to interception by malicious actors who can exploit unencrypted network traffic to steal sensitive information.

Missing multi-factor authentication

Critical operations, such as password resets, lacked the implementation of multi-factor authentication (MFA). Without an additional verification step, the system fails to confirm the user’s identity, making it easier for attackers to compromise user accounts.

Predictable session tokens

The API used sequential or easily guessable session identifiers. This predictability allows attackers to manipulate or guess session tokens, facilitating session hijacking and unauthorized access to user accounts.

Each of these vulnerabilities stems from a failure to implement robust authentication mechanisms and to adhere to security best practices, leaving the API open to exploitation.

Here is an example of what the vulnerable backend code may have looked like when Eva was able to send unlimited requests. This example lacks rate limiting functionality.

This JavaScript example illustrates a vulnerable login implementation commonly found in APIs. While functional, it lacks critical defences against malicious actors, making it susceptible to brute-force attacks.

The JavaScript code snippet defines a login endpoint at /api/login. It uses the findUser function to retrieve a user's details based on the provided username from the request body. The password is then compared directly to the stored password in the user object. If the credentials match, a token is generated via the generateToken(user) function and sent back in the response. Otherwise, it returns a 401 status with an "Invalid credentials" message.

This implementation is vulnerable because it does not impose rate-limiting measures. For example, the findUser function can be repeatedly called without restriction, allowing an attacker to brute-force the password field. Each failed login attempt incurs no penalty, and the lack of IP throttling or request limiting makes this API a prime target for abuse.

Here is a Python example of a login endpoint that handles user authentication. Although it processes requests effectively, the absence of proper security measures leaves the system open to exploitation.

In this Python code, the login function is mapped to the /api/login route. The user’s credentials are extracted using request.get_json(), and the find_user function retrieves the user’s data. If the stored password matches the password field in the request data, the generate_token(user) function generates a token that is sent back as a JSON response. Failed attempts result in a "401 Unauthorized" response with the message "Invalid credentials."

The vulnerability lies in the unrestricted access to the login function. The find_user call is unprotected against repeated requests from the same client or IP. An attacker can brute-force the password field without facing rate limits, delays, or account lockouts, enabling them to exploit the system until valid credentials are discovered.

This PHP code snippet demonstrates a simple login mechanism for validating user credentials. However, its design omits essential safeguards, exposing it to potential abuse.

This PHP snippet handles login requests by decoding the JSON input from the php://input stream. The find_user function is used to locate the user, and the password field is directly compared using the === operator. If the credentials match, the generate_token($user) function generates a token, which is sent as a JSON response. For invalid credentials, the script returns a 401 status and the message "Invalid credentials."

The vulnerability is evident in the lack of restrictions around the find_user function and the $_SERVER['REQUEST_METHOD'] block. Because there is no mechanism to limit the number of times this code is executed, attackers can make unlimited requests with different passwords, using brute force to gain unauthorized access.

This C# example provides a straightforward implementation of an authentication endpoint. While it fulfills its purpose, the lack of protections against repeated login attempts poses a serious security risk.

This C# code implements a login route using the [HttpPost("api/login")] annotation. The Login method accepts a LoginRequest object containing Username and Password. The FindUser method retrieves the user’s data, and a direct comparison is made between the request.Password and user.Password. If the credentials match, the GenerateToken(user) method creates a token that is returned in the HTTP response. Otherwise, an unauthorized status and the message "Invalid credentials" are returned.

The code is vulnerable due to its unrestricted access to the Login method and the FindUser function. Without rate limiting, this implementation allows repeated calls to the endpoint, enabling attackers to attempt numerous username-password combinations. This lack of safeguards, such as IP blocking or a retry delay, leaves the application open to brute-force attacks.

This Go example outlines the implementation of a login handler. Although it performs basic authentication tasks, its lack of defensive measures makes it vulnerable to automated attacks.

In this Go example, the loginHandler function processes login requests at the /api/login route. It decodes the JSON input into a LoginRequest struct with Username and Password fields. The findUser function retrieves the user's data, and the Password field is validated against the stored password. If successful, a token is generated using the generateToken(user) function and returned as a JSON response. Otherwise, the http.Error method sends a "401 Unauthorized" response.

The vulnerability stems from the absence of restrictions around the loginHandler function. The findUser function is repeatedly called for each request, and there is no mechanism to detect or mitigate brute-force attempts. Attackers can exploit this by automating credential guessing without encountering rate limits or account lockouts.

This Java code snippet shows a typical login endpoint setup in a REST API. Despite being functional, the lack of safeguards against malicious activity leaves it open to significant risks.

This Java code defines a POST endpoint at /api/login using the @PostMapping annotation. The login method accepts a LoginRequest object and retrieves user data via the findUser method. It compares the request.getPassword() value with the stored password using the equals method. If they match, the generateToken(user) method creates a token, which is returned in the response. Otherwise, an unauthorized HTTP status is sent with the message "Invalid credentials."

The vulnerability arises from the unrestricted execution of the findUser method and the login logic. Without rate-limiting protections, attackers can submit unlimited login attempts, exploiting the API to guess request.getPassword(). The lack of safeguards, such as IP throttling or temporary account lockouts, makes this endpoint a straightforward target for brute-force attacks.

Broken authentication vulnerabilities can lead to severe and far-reaching consequences for organizations and their users. When authentication mechanisms are compromised, attackers can bypass security controls and gain unauthorized system access, leading to multiple serious impacts.

Account takeover (ATO) represents one of the most severe consequences. Once attackers successfully exploit weak authentication, they gain complete control over user accounts. This allows them to modify account settings, make unauthorized purchases, and change credentials at will. High-privilege accounts like administrators are particularly attractive targets, as compromising these accounts enables attackers to cause maximum damage. Compromised accounts are also frequently used as launching points for internal attacks or sophisticated phishing campaigns targeting other users.

Data breaches often follow successful authentication attacks. Attackers can access sensitive personal information, potentially exposing everything from basic contact details to complete identity information. Financial data, including credit card numbers and banking details, becomes vulnerable to theft.

Service disruption represents another critical impact of broken authentication. Large-scale attacks can overwhelm authentication systems with countless login attempts. This abuse of system resources consumes excessive bandwidth and processing power, potentially bringing services to a halt. Legitimate users often find themselves locked out of their accounts during attack mitigation.

Because of these severe consequences, organizations must implement robust authentication controls. Multi-factor authentication, rate limiting, and well-designed account lockout policies serve as critical security measures to prevent these attacks and their devastating impacts.

Enforce Strong Password Policies

Passwords should adhere to complexity requirements, such as including uppercase and lowercase letters, numbers, and special characters. Additionally, password validation should be implemented to ensure users are not using common patterns or compromised passwords. This minimizes the risk of brute-force attacks or credential stuffing.

Implement Rate Limiting

Rate limiting is essential to restrict the number of login attempts allowed per account or IP address. By setting a limit on repeated requests within a specified time frame, you can significantly reduce the likelihood of brute-force attacks. For added security, consider temporarily locking accounts after a certain number of failed login attempts or using CAPTCHA challenges to identify legitimate users.

Use Secure Token Practices

Tokens are a critical part of modern authentication, but they must be managed securely. Always validate tokens for expiration to prevent the reuse of outdated credentials. Additionally, ensure the token signature is valid and that audience claims align with the expected application context. These practices help prevent unauthorized access using stolen or manipulated tokens.

Require Re-authentication for Sensitive Actions

For particularly sensitive actions, such as password resets or email changes, require users to re-authenticate themselves. This ensures that even if a session is compromised, an attacker cannot make critical changes without additional verification. This step protects the integrity of user accounts and prevents unauthorized modifications.

Enable Multi-Factor authentication (MFA)

Multi-factor authentication (MFA) provides an extra layer of security by requiring users to present two or more verification factors, such as a password and a one-time code. Enabling MFA for all users significantly enhances account protection, even if passwords are stolen or compromised. This additional safeguard makes unauthorized access much harder to achieve.

Below you will find some mitigated code. It's best to use a reputable third party to implement rate limiting, but similar logic will apply:

This JavaScript implementation addresses the issue of rate limiting using an in-memory Map object to track login attempts. Before processing the login, the rateLimiter checks the current time and the number of recent attempts associated with the username. If a user exceeds five attempts within a minute, the endpoint responds with a 429 status, indicating too many requests. Upon successful authentication, the rateLimiter.delete(username) call resets the user's attempt count, allowing future logins.

This mitigated approach effectively prevents brute-force attacks by limiting the rate at which requests can be made. Unlike the vulnerable version, this code ensures that attackers cannot repeatedly attempt to guess passwords without facing delays or blocks.

The Python implementation utilizes the Flask-Limiter library to enforce rate limiting. The @limiter.limit("5 per minute") decorator restricts each IP address to five login attempts per minute, automatically managing throttling and tracking without requiring custom logic. authentication proceeds only if the user’s credentials match those stored in the system.

By using Flask-Limiter, this code makes brute-force attacks infeasible because repeated login attempts from the same IP address are blocked. This eliminates the unrestricted access seen in the vulnerable implementation, providing robust protection with minimal additional code.

In this PHP implementation, rate limiting is enforced through the session variables $_SESSION['attempts'] and $_SESSION['last_attempt']. Each login attempt increments the attempt counter, and if a user exceeds five attempts within 60 seconds, further requests are blocked with a 429 status. Successful authentication resets the attempt counter to zero.

This mitigated code prevents brute-force attacks by tracking login attempts per session and ensuring users cannot overwhelm the endpoint with repeated requests. The implementation also ensures that the system automatically resets restrictions for legitimate users after successful logins.

This C# example implements a RateLimiter dictionary to track login attempts for each username. Before processing the request, the method checks if the user has exceeded five attempts within a one-minute window using the LastAttempt and Attempts values. If the user is blocked, a 429 status is returned. On successful login, the RateLimiter.Remove(request.Username) call clears the attempt record.

This implementation mitigates brute-force vulnerabilities by adding robust controls to limit repeated login attempts. Resetting the counter after successful authentication maintains usability for legitimate users while preventing abuse.

In this Go implementation, a thread-safe rateLimiter structure is used to track login attempts. For each request, the code locks the rateLimiter to verify whether the user has exceeded five attempts within one minute. If so, the handler responds with a 429 status. Successful authentication resets the rate limiter entry using delete(rateLimiter.attempts, req.Username).

This code mitigates vulnerabilities by ensuring that brute-force attacks are slowed or blocked entirely. The use of a mutex for thread safety ensures reliable performance even in concurrent environments, addressing potential race conditions while maintaining security.

The Java implementation introduces a ConcurrentHashMap to track login attempts per username. The rateLimiter.compute method updates the count and timestamp for each user. If a user exceeds five attempts within one minute, a ResponseStatusException is thrown, returning a 429 status. Successful authentication removes the user’s entry from the rateLimiter, resetting their attempt counter.

This approach resolves the vulnerabilities by enforcing strict rate-limiting policies, ensuring that attackers cannot exploit the login endpoint with automated brute-force attempts. At the same time, it provides legitimate users with a seamless experience by clearing restrictions after successful logins.

Learn more about broken authentication with these resources:

• OWASP authentication cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• Snyk API Security Guide
• Snyk How to Secure a REST API
• OWASP Top 10 API #2 broken authentication: https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/