Broken Authentication - OTP in Response

  1. Home

A Broken Authentication vulnerability occurs when the API returns the One-Time Password (OTP) directly in the response after a user requests it.

Intended flow:
User requests an OTP → OTP is sent via SMS, email, or app → User enters OTP → Server validates OTP

Vulnerable flow:
User requests an OTP → API responds with the OTP in the response body

Example:

{
  "status": "OTP sent successfully",
  "otp": "123456"
}

Any attacker who can view the API response (e.g., via a compromised mobile app, browser, or logs) can use the OTP to authenticate — without needing access to the actual delivery channel (SMS/email/etc.).

Broken Authentication - OTP in Response -img

Impact of the Vulnerability

1.Authentication Bypass

Anyone with access to the response (like a malicious app user or attacker using an intercepted token) can instantly retrieve the OTP and skip the verification process altogether.


2. Account Takeover Risk

If an attacker has or guesses valid usernames, they could generate OTPs on demand and use the returned values to gain unauthorized access to user accounts.


3. Easy Automation for Attackers

Attackers can script OTP generation using tools like curl, Burp Suite, or Postman to automate logins at scale — making the vulnerability much more exploitable


4. Legal and Compliance Violations

Sharing OTPs in responses may breach regulatory requirements such as GDPR, HIPAA, or PCI-DSS, leading to legal consequences or fines.

Solution to Fix the Vulnerability

To secure OTP-based workflows, consider the following best practices:

  1. Don’t Expose OTPs in API Responses:
    • Never return OTPs in client-visible responses.
    • Deliver them only via secured channels like SMS, email, or push notifications.

  2. Secure OTP Handling on the Backend:
    • Store OTPs temporarily on the server, and if possible, hash them just like passwords.
    • Only verify them once the user submits the input.

  3. Use Expiry Timers and Throttling:
    • Set OTPs to expire quickly (within 1–2 minutes).
    • Enforce rate limiting to prevent repeated requests or brute-force attempts.

  4. Context-Aware OTP Validation:
    • For stronger security, bind OTPs to metadata like user agent, IP address, or device ID to ensure OTPs are only valid in the original request context.

Exposing OTPs in API responses is a high-risk security flaw that can be exploited easily if overlooked. It’s simple to fix but requires attention to detail in API design and dev practices.