Slide 15 of 28
Part 3 · Attack ScenariosSlide 15
Slide 15 · Scenario 2
A stolen token is a stolen account.
OWASP Scenario #2 — account takeover via email change without re-authentication.
📄 OWASP API Security Top 10 · 2023 · API2 · Scenario 2
SETUP
The API lets you change your email with just a token.

An API allows updating account details via PUT /account. The only requirement: a valid Bearer token in the Authorization header. No password confirmation required.

The developer reasoned: if you have a valid token, you're logged in, so you can edit your account. Seems logical. But it ignores what happens when a token is stolen.

The flaw: A session token proves you were authenticated at some point. It doesn't prove you're the legitimate user right now. Sensitive operations need fresh proof of identity.
THE ATTACK
Token stolen. Account gone. Four steps.

Step 1: Attacker obtains a valid token — via phishing, XSS, a log leak, or a token exposed in a URL.

Step 2: PUT /account with body {"email": "attacker@evil.com"}. No password asked. Request succeeds.

Step 3: Attacker triggers "Forgot Password" for the account.

Step 4: Password reset link arrives at attacker@evil.com. Attacker sets a new password. The original owner is permanently locked out.

Why it works: The email is the recovery mechanism. Control the email, control the account. No password needed — just a token that was valid long enough to change one field.
← Back Real incident: Parler →