ASVS 5.0 V7.5.3: Step Up Authentication for Sensitive Operations

ASVS 5.0 V7.5.3 (Level 3) requires that the application asks for further authentication with at least one factor, or a secondary verification, before performing highly sensitive transactions or operations. A logged in session is not enough for the actions where a mistake or a hijack is expensive.

Why it matters

Sessions are long lived by design, and they can be stolen. For ordinary browsing that risk is tolerable. For moving money, exporting a customer database, changing a payee, rotating production keys or granting admin rights, it is not. A step up check limits what a stolen or abandoned session can do.

It also protects against the user's own mistakes and against coerced clicks. A prompt that names the action makes people stop and read.

How to implement it

First decide what counts as highly sensitive. Write the list, get it reviewed, and keep it short enough that users do not learn to ignore the prompt. Typical entries are payouts above a threshold, bulk data export, permission changes, API key creation and security setting changes.

Then enforce step up on the server for those routes.

function requireStepUp(action) {
  return async (req, res, next) => {
    const grant = await db.stepUps.findOne({
      sessionId: req.session.id,
      action,
      used: false,
      expiresAt: { $gt: new Date() },
    });
    if (!grant) {
      return res.status(403).json({ error: "step_up_required", action });
    }
    await db.stepUps.updateOne({ _id: grant._id }, { $set: { used: true } });
    next();
  };
}

app.post("/payouts", requireSession, requireStepUp("payout"), createPayout);

Key properties of a good grant:

• Short lived, a few minutes at most.
• Bound to the session and to the named action, and ideally to the amount or target.
• Single use, so one approval cannot cover a second operation.
• Created only after a fresh factor: a TOTP or WebAuthn assertion, a push approval with number matching, or a verified one time code to a trusted channel.

For SSO, request a stronger or fresher authentication from the identity provider and verify the returned assurance claims, rather than trusting the browser to say it happened.

Show the user what they are approving, such as the payee and amount, so the verification means something. Log every step up with the result.

How to test it

• Call each sensitive endpoint with a normal session and no step up. Expect a 403 with a clear error.
• Complete step up for action A and try to use it for action B. Expect denial.
• Reuse the same grant twice. The second call must fail.
• Wait out the expiry and retry.
• Try changing the amount after approval if the grant is bound to it.
• Call the API directly, skipping the interface, to prove the control is not UI only.

Common mistakes

• Prompting in the front end while the API accepts the call without proof.
• Grants that last an hour or apply to every sensitive action.
• A factor that is weaker than the one used at login, such as an SMS code to a number that can be changed without reauthentication (see V7.5.1).
• Labeling everything sensitive, which trains users to click through.
• No audit trail for who approved what.

Try it yourself

List your five riskiest operations. For each one, answer: what would a hijacked session do here, and what extra proof would stop it? Implement the single use grant for the top one and run the tests above.

Quick check

Sources

• OWASP Application Security Verification Standard
• OWASP Authorization Cheat Sheet