Safeguard
Application Security•

ASVS 5.0 V7.1.2: Document Concurrent Session Limits

ASVS V7.1.2 wants your documentation to say how many parallel sessions one account may hold and what happens at the limit. A short policy and a test make it provable.

Safeguard Security Team
2 min read

ASVS 5.0 V7.1.2 (Level 2) requires documentation that states how many concurrent sessions one account can have, and what the application does when that maximum is reached: refuse the new login, end the oldest session, or ask the user to choose.

Why it matters

Unlimited parallel sessions make stolen credentials quiet. An attacker can sit in one session while the owner uses another, and neither sees the other. A defined limit, plus a visible reaction when it is hit, turns that into a signal.

The documentation matters because the behavior is a product decision. A shared analyst account, a family plan and a single admin seat all deserve different answers.

How to implement it

Pick a limit and an action per account type, then write them down:

  • Limit: for example 5 for standard users, 1 for privileged roles.
  • Action at the limit: reject the new login, revoke the oldest session, or prompt.
  • Notification: whether the user is emailed when a session is revoked.
  • Where the count is enforced (server session store, not the client).

A server side sketch in Python with a session table:

MAX_SESSIONS = 5

def create_session(db, user_id, new_token_hash):
    rows = db.execute(
        "SELECT id FROM sessions WHERE user_id = ? AND revoked = 0 "
        "ORDER BY created_at ASC", (user_id,)
    ).fetchall()
    while len(rows) >= MAX_SESSIONS:
        oldest = rows.pop(0)
        db.execute("UPDATE sessions SET revoked = 1 WHERE id = ?", (oldest["id"],))
    db.execute(
        "INSERT INTO sessions (user_id, token_hash, created_at, revoked) "
        "VALUES (?, ?, CURRENT_TIMESTAMP, 0)", (user_id, new_token_hash)
    )

How to test it

Log in as one user from limit plus one browsers or curl cookie jars. Confirm the documented behavior happens: the oldest cookie stops working, or the final login is refused. Check the privileged role separately.

Common mistakes

  • Documenting a limit that is only enforced in the UI.
  • Counting expired sessions toward the limit, which locks users out.
  • Not saying what happens at the limit, so support improvises.

Quick check

Can the limit be unlimited?

Only if you document it as a deliberate decision with the reasoning. The requirement is that the behavior is defined, not that it is strict.

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.