Every Session Security Audit check

An inactivity timeout longer than 15 minutes on a financial application leaves an authenticated session open on an unattended device — a walk-up attacker can initiate a wire transfer, change account details, or exfiltrate account history without needing credentials. CWE-613 (Insufficient Session Expiration) and PCI-DSS 4.0 Req 8.2.8 both mandate short inactivity windows precisely because the attack surface is physical access, not network intrusion. NIST 800-63B also ties session lifetimes to assurance level — higher-value operations demand shorter windows. A 30-minute timeout means every unlocked laptop in a coffee shop is a potential account takeover waiting for an opportunist.

Why this severity: Critical because any unattended authenticated session with an oversized timeout window grants walk-up or remote session-hijack attackers full financial operation access without requiring credentials.

An inactivity timeout alone is insufficient if a sufficiently active user — or an attacker who has hijacked a session and keeps it alive with synthetic requests — can maintain access indefinitely. CWE-613 and PCI-DSS 4.0 Req 8.2.8 require an absolute wall-clock limit on session lifetime regardless of ongoing activity. Without an absolute cap, a compromised session token issued at 9 AM remains valid at 11 PM of the same day. NIST 800-63B (AC-12) explicitly calls for session termination after a maximum duration. The 8-hour ceiling corresponds to a full working day — sessions that outlast the workday create overnight exposure with no legitimate justification for financial applications.

Why this severity: High because an indefinitely active session allows a hijacked or stolen token to remain valid for days, enabling prolonged unauthorized access to financial operations that an inactivity timeout alone cannot prevent.

A logout that only clears client-side state — localStorage, React context, or a cookie set to Max-Age=0 without server-side destruction — leaves the server-side session record valid. Any actor who captured the session token (via network sniff, log file, browser extension, or XSS) can replay it after the user 'logged out' and regain full access. CWE-613 defines this as insufficient session expiration. OWASP A07 (Identification and Authentication Failures) and PCI-DSS Req 8.2.6 both require server-side invalidation. The consequence in a financial context is that post-logout token replay enables transfers, account changes, and data exfiltration on an account the user believed was secured.

Why this severity: High because a server-side session that survives client logout allows token replay attacks — any captured session token remains valid indefinitely, granting full financial account access after the user has explicitly signed out.

Storing session tokens in localStorage means they survive browser restart, tab close, and OS sleep. An attacker with brief physical access, an XSS payload, or a malicious browser extension can exfiltrate a localStorage token and replay it from any machine at any time — the user's network disconnect or tab close provides no protection. CWE-384 (Session Fixation) and CWE-287 (Improper Authentication) both apply when a stale persistent token is accepted as proof of identity. NIST 800-63B IA-11 specifically addresses re-authentication requirements after session interruption. Financial applications that auto-resume from disk-persisted tokens effectively eliminate the security benefit of inactivity timeouts.

Why this severity: Medium because the attack requires the token to be exfiltrated first (via XSS, physical access, or extension), but once captured, a localStorage-persisted token grants indefinite session resumption without any re-authentication barrier.

A session that expires silently while a user is mid-transaction forces an abrupt authentication failure — potentially losing form data, a partially entered transfer, or an in-flight payment. Without a warning, users either encounter jarring redirects or, worse, begin abandoning financial tasks they cannot complete. CWE-613 and PCI-DSS Req 8.2.8 require that session expiration be communicated to users. Beyond compliance, an unwarned expiry increases the probability that users disable session timeouts through workarounds, defeating the security control entirely. A 2-minute warning with an 'extend' option preserves both security and usability.

Why this severity: Medium because silent expiry during active financial tasks creates UX failures that drive users to circumvent session security controls, indirectly undermining the inactivity timeout that PCI-DSS Req 8.2.8 mandates.

Financial regulators, PCI-DSS Req 10.2, and NIST 800-63B (AU-2/AU-9) require that session lifecycle events — logins, logouts, timeouts, and extensions — be recorded in a tamper-resistant audit trail. Without immutable session logs, incident response is blind: there is no way to determine whether a specific session was active during a disputed transaction, whether a concurrent session was established from an unusual IP, or whether a session was extended unexpectedly. ISO 27001:2022 A.8.15 requires log integrity. Mutable logs stored in a writable database table are trivially altered to conceal unauthorized access.

Why this severity: Info severity because the absence of session logging does not directly enable attack, but it removes the forensic record needed to detect, investigate, and prove unauthorized session activity after the fact.

Different organizations within a multi-tenant financial platform have different risk tolerances and regulatory environments. A corporate treasury customer operating under SOC 2 Type II may be required to enforce shorter timeouts than a retail consumer. Hard-coding a global timeout at the application layer removes admin control and forces a binary choice: apply the strictest timeout everywhere and hurt UX, or apply a lenient one and fail to meet specific org-level compliance requirements. CWE-613 and PCI-DSS Req 8.2.8 do not preclude stricter controls — per-org configuration lets each tenant set a timeout at or below the maximum, enforcing the floor at the database level.

Why this severity: Info severity because a hard-coded global timeout is not inherently insecure if it meets the 15-minute minimum, but the absence of per-org configuration prevents compliance-driven customers from enforcing stricter controls required by their own policies.

Session security controls only work if their efficacy is monitored. Without quarterly review of session analytics — login frequency, timeout event rates, concurrent session warnings, suspicious activity triggers — patterns that signal active attacks or policy drift go undetected for months. PCI-DSS Req 10.7 requires review of security logs and events on a regular schedule. NIST 800-63B AU-6 mandates log analysis. A spike in timeout events might indicate session hijacking attempts keeping a stolen session alive; a drop in concurrent-session warnings might mean the control stopped firing. Quarterly reviews convert raw session data into actionable security posture assessments.

Why this severity: Info severity because the lack of a review schedule does not disable any session security control, but it ensures that control failures, attack patterns, and policy drift remain invisible until a breach forces a retrospective investigation.

A session token that grants access to wire transfers and payments is the highest-value credential in a financial application. If that token is stolen — via XSS, network interception, or session fixation — the attacker can execute high-value transactions without any additional authentication barrier. Step-up authentication requires a second proof-of-identity at the moment the sensitive operation is initiated, so a stolen token alone is insufficient. CWE-306 (Missing Authentication for Critical Function), OWASP A07, PCI-DSS Req 8.4, and NIST 800-63B IA-11 all address this gap. Without server-side step-up enforcement, client-side UI guards are trivially bypassed with a direct API call.

Why this severity: High because an absent server-side step-up on financial endpoints means any actor possessing a valid session token — regardless of how it was obtained — can initiate transfers, wires, and payments with no additional authentication challenge.

Step-up authentication is only meaningful if the challenge it presents is at least as hard to satisfy as the initial login. Downgrading from a password+biometric login to a plain OTP step-up means the attacker who cannot replicate the biometric at login can instead wait for the step-up prompt and satisfy it with a weaker factor. CWE-287 (Improper Authentication) and NIST 800-63B AAL2 both require that step-up methods match or exceed the assurance level of the authenticating session. OWASP A07 identifies authentication downgrade as a category-defining failure. In practice, a strength mismatch turns step-up into a false signal — it appears to add security while actually lowering the bar.

Why this severity: Medium because strength downgrade does not eliminate the step-up challenge but renders it easier to satisfy than the original login, reducing the additional security margin that step-up is supposed to provide.

Forcing an OTP step-up on top of a WebAuthn biometric verification on a user's own trusted single device creates friction without adding meaningful security — both factors already verify possession of the same device. NIST 800-63B AAL2 recognizes biometric verification on a bound authenticator as a sufficient second factor when the device is enrolled and trusted. Requiring an additional OTP in this context defeats the purpose of trusted-device enrollment and trains users to disable or circumvent step-up prompts. Correctly tiered step-up — biometric-sufficient on trusted single devices, OTP-required elsewhere — maintains security while reducing friction for compliant users.

Why this severity: Low because the failure mode is usability friction rather than a security gap — requiring excessive OTPs on trusted biometric devices drives step-up bypass attempts rather than enabling direct attack.

Not all users have biometric hardware — older laptops, shared workstations, and most desktop web browsers lack TouchID or FaceID. If biometric is the only step-up path on multi-device or web contexts, users without capable hardware are either blocked from completing financial operations or silently bypassed by the application. CWE-308 (Use of Single-Factor Authentication) applies when a required step-up factor is unavailable to a meaningful portion of users. PCI-DSS Req 8.4 requires that multi-factor authentication be available for all applicable users. At least two fallback methods — OTP-SMS, OTP-email, or TOTP — ensures step-up is universally enforced rather than selectively applied based on hardware.

Why this severity: Low because users without biometric hardware on multi-device contexts lose step-up protection entirely, effectively removing an authentication control for a predictable subset of the user population.

Unlimited concurrent sessions mean a stolen session token can be used in parallel with the legitimate user's session — the account owner has no indication the account is being accessed simultaneously from a different location. CWE-613 covers this under insufficient session expiration. PCI-DSS Req 8.2.8 and NIST AC-10 both address concurrent session controls. In financial applications, the attack pattern is: steal session token, establish parallel session, initiate transfer while the legitimate user is actively transacting and won't notice a concurrent login warning. Limiting concurrent sessions to one and notifying on new logins closes this window — the attacker's session either terminates or the user receives a warning.

Why this severity: High because unlimited concurrent sessions allow a stolen token to establish a parallel, invisible session that can execute financial operations at the same time as the legitimate user with no signal to either party.

Users who cannot see their active sessions cannot detect unauthorized access. If an attacker establishes a session from an unfamiliar IP or device, the account owner has no mechanism to discover it or revoke it — they must wait for the application to enforce concurrent session limits or for a timeout. CWE-613 and OWASP A07 identify session visibility as a component of proper session management. Giving users a self-service session management page transforms passive victims into active defenders: they can see an unexpected location, terminate the session, and change their credentials before the attacker completes a transaction.

Why this severity: Low because the attacker still needs a valid session token to exploit the gap, but the absence of session visibility removes the user's only self-service mechanism for detecting and revoking unauthorized concurrent access.

Login location tracking is the baseline dataset for detecting impossible travel, account sharing, and unauthorized access patterns. Without it, there is no ground truth for anomaly detection — you cannot identify a login from Russia 10 minutes after a login from New York if no location is recorded. PCI-DSS Req 10.2.1 requires that access attempts include origin context. NIST AU-3 mandates that audit records capture location where applicable. ISO 27001:2022 A.8.15 requires traceability of access events. In financial fraud investigations, login location records are often the primary evidence used to distinguish legitimate from unauthorized transactions.

Why this severity: Low because location tracking does not prevent unauthorized access on its own, but without it, anomaly detection, fraud investigation, and incident response lose the geographic context needed to identify suspicious login patterns.

Session fixation (CWE-384) is an attack where an adversary pre-sets a known session ID — via a URL parameter, cookie injection, or a shared link — then waits for the victim to authenticate. If the server preserves the pre-authentication session ID after login, the attacker's known ID becomes an authenticated session without any credential theft. OWASP A07 and CAPEC-61 document this attack class. NIST IA-2 requires unique session identification per authenticated principal. In a financial application, a fixation attack grants the attacker a fully authenticated session capable of initiating transfers. The fix is a single call to `session.regenerate()` on every login path — omitting it is the entire vulnerability.

Why this severity: Critical because session fixation allows an attacker to pre-establish a known session ID and convert it into an authenticated financial session without ever stealing credentials — purely by exploiting a missing regeneration call on login.

Session tokens stored in localStorage or accessible JavaScript variables are exfiltrable by any XSS payload on any page of the application. A single reflected or stored XSS vulnerability anywhere on the domain becomes a full session hijack with no additional effort. CWE-614 (Sensitive Cookie Without 'Secure' Attribute) and CWE-1004 (Sensitive Cookie Without 'HttpOnly' Flag) define these as distinct failures. OWASP A07 and PCI-DSS Req 6.4.1 mandate that session tokens be inaccessible to client-side scripts. In a financial application, exfiltrating a session token from localStorage via `document.cookie` or XSS requires zero CSRF bypass — the token is already JavaScript-readable and portable.

Why this severity: High because a session token in localStorage or a cookie missing HttpOnly is a single XSS vulnerability away from full account compromise — the attacker does not need to break HTTPS or defeat SameSite protections to extract and replay it.

Password and OTP credentials are portable — they can be phished, replayed from a different device, or used by a credential-sharing household member. Device fingerprinting adds a possession factor derived from the actual browser and hardware environment, making a stolen credential set insufficient on an unrecognized device. CWE-287 (Improper Authentication) and OWASP A07 identify the gap between credential verification and device trust. NIST 800-63B IA-3 addresses device identification requirements. In financial fraud patterns, credential stuffing attacks typically originate from devices that have never logged into the account — fingerprinting flags this at first login from a new device and triggers step-up before any transaction is possible.

Why this severity: Medium because stolen credentials alone are sufficient to authenticate from an unrecognized device without triggering any additional verification, converting a phishing success directly into financial account access.

Impossible travel, rapid transaction sequences, and unusually large transfer amounts are established signals of account compromise or fraud. Without anomaly detection, an attacker who obtains a valid session token — through phishing, session fixation, or XSS — can execute transactions that would immediately appear suspicious to any human reviewer but proceed unchallenged by the application. CWE-307 (Improper Restriction of Excessive Authentication Attempts) and NIST SI-4 (System Monitoring) address active threat detection requirements. PCI-DSS Req 10.7 requires that anomalies trigger alerts. Suspicious activity step-up provides a dynamic second factor that activates precisely when risk is highest, without adding friction to normal user behavior.

Why this severity: Low because suspicious activity detection is a defense-in-depth layer — its absence does not enable initial access, but it removes the runtime signal that would detect and interrupt an active attack on an already-compromised session.

localStorage persists across browser restarts, operating system sleeps, and shared-device sessions. Any XSS vulnerability on any page of the application — including third-party scripts loaded on marketing pages — can read `localStorage` across the entire origin and exfiltrate every stored token. CWE-922 (Insecure Storage of Sensitive Information) and CWE-312 (Cleartext Storage of Sensitive Information) both apply. OWASP A02 (Cryptographic Failures) addresses insecure data at rest. PCI-DSS Req 6.4.1 forbids storing sensitive authentication data where scripts can access it. In a financial application, a single-line `localStorage.getItem('authToken')` in an XSS payload yields a portable, replayable session credential.

Why this severity: Low because the attacker requires a co-located XSS vulnerability to exploit localStorage exposure, but when that condition is met, every session token stored there is immediately and silently exfiltrable to an external server.