Safeguard
Application Security•

ASVS 5.0 V7.4.5: Let Admins Terminate User Sessions

ASVS V7.4.5 requires administrators to be able to end one user's sessions or everyone's. Build the controls, audit them and test the kill switch.

Safeguard Security Team
2 min read

ASVS 5.0 V7.4.5 (Level 2) requires that application administrators can terminate active sessions for an individual user or for all users. It is the incident response lever for compromised accounts and for a leaked signing key.

Why it matters

When something goes wrong at 2 a.m., waiting for sessions to time out is not an option. You need a supported, tested way to cut access now, without editing the database by hand or restarting the fleet.

How to implement it

Provide two administrative actions:

  • Terminate sessions for user X.
  • Terminate all sessions, or all sessions issued before a given time.

With a server side session store this is a flag update. With self contained tokens, use a per user or global "not before" value that validation checks.

def admin_revoke_user(db, admin, target_user_id):
    require_permission(admin, "sessions:revoke")
    db.execute("UPDATE sessions SET revoked = 1 WHERE user_id = ?", (target_user_id,))
    audit(admin.id, "revoke_user_sessions", target_user_id)

def admin_revoke_all(db, admin):
    require_permission(admin, "sessions:revoke_all")
    db.execute("UPDATE settings SET sessions_valid_after = CURRENT_TIMESTAMP")
    audit(admin.id, "revoke_all_sessions", None)

Protect these endpoints with their own permission, require recent reauthentication, and log who did it. Make sure the actions also clear refresh tokens and any cached validation results, since a cache can keep a revoked session alive.

How to test it

  • Sign in as a test user, then revoke as an admin, and confirm the user is rejected immediately.
  • Run the global action in a staging environment and confirm all clients must sign in again, including the admin who triggered it if designed so.
  • Verify a non admin receives a 403 on both endpoints.
  • Check the audit log entry.

Common mistakes

  • Revocation that waits for a cache to expire.
  • No permission separation, so any admin can log everyone out.
  • Never rehearsing the global action until the incident.

Quick check

Do signed tokens block this requirement?

No, but you need a mechanism such as a not before timestamp or key rotation, since you cannot delete a token that lives on the client.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.