Require a fresh password or second factor before actions that could lock the real owner out or move money: changing email, changing a phone number used for 2FA, changing the password, and adding new credentials. OWASP lists this under preventing broken authentication.
The attack it stops
OWASP's second scenario in API2:2023 is an account update endpoint that lets a user change their email address with only a bearer token, with no current password required. An attacker who obtains the token changes the victim's email, then runs the password reset flow and takes the whole account.
The token theft might be brief. Without re-authentication, a short window becomes permanent loss.
The rule from OWASP
The prevention list says to require re-authentication for sensitive actions, such as changing an email address or a 2FA phone number. It also notes an API is vulnerable if it changes sensitive data without confirming the user's password.
A way to choose actions
Ask of each action: if an attacker did this with a stolen session, could the owner recover?
- Change email: Reauthenticate?: Yes; Why: Feeds password reset
- Change phone or 2FA device: Reauthenticate?: Yes; Why: Controls second factor
- Change password: Reauthenticate?: Yes; Why: Direct takeover
- Add an API key or token: Reauthenticate?: Yes; Why: Creates a new persistent credential
- Change payout details: Reauthenticate?: Yes; Why: Money movement
- Download all data: Reauthenticate?: Usually; Why: Large exposure
- Update display name: Reauthenticate?: No; Why: Low impact
- Read own profile: Reauthenticate?: No; Why: Normal use
How to implement it
- Keep a field on the session for time of last strong authentication.
- For sensitive endpoints, require that time to be within a short window, for example a few minutes. Pick the window yourself based on risk.
- If it is stale, return a response that tells the client to prompt for the password or a code, then retry.
- Verify the credential on the server. A flag sent by the client proves nothing.
- Notify the old email or phone when something sensitive changes, so the real owner has a chance to react.
Pair it with reset protections
Re-authentication closes the change path. The reset path needs its own limits. See throttling reset and OTP endpoints.
Do not block automation unfairly
Service accounts cannot answer a password prompt. For machine credentials, use separate controls: narrow scopes, approval workflows and key rotation, not interactive prompts.
Quick check
Is a short session lifetime a substitute?
No. A short session limits the window but does not stop an attacker acting inside it. Re-authentication checks the person at the moment of the risky act.
Should the check be client side?
No. The server must verify the password or code, since anything the client sends can be forged.
Safeguard's agent identity and policy features cover how automated actors are controlled, and the free scan at gold.safeguard.sh/scan checks dependencies. The re-authentication logic belongs in your application.
Sources
Last reviewed: 19 October 2026.
