Report Date: 2024-06-20 | Reported By: Senior QA Analyst | System: Project Management Platform

BUG-047: Session Timeout Not Firing Consistently

Summary

Users remain authenticated beyond the 30-minute session timeout threshold. Timeout is supposed to trigger after 30 minutes of inactivity, but it fires inconsistently or not at all. This can result in unauthorized access if a user leaves their device unattended.

Security Impact: ⚠️ MEDIUM — Could allow unauthorized access to unattended sessions on shared devices.

Environment

Field	Value
Environment	QA Staging (prod-like)
OS/Browser	macOS Ventura, Chrome 123
Date Found	2024-06-15
Reproducibility	Intermittent (60% of attempts)
Build/Version	v2.3.1-beta

Steps to Reproduce

1. Log in with valid credentials (test.user@example.com / ValidPass123!)
2. Dashboard loads; user authenticated
3. Close all browser tabs; do NOT click logout
4. Wait exactly 30 minutes without any user action
5. Return to browser; open new tab and navigate to app URL
6. Expected: Redirected to login page (session expired)
7. Actual: Dashboard loads; user still authenticated ❌

Detailed Reproduction

Test 1 (Successful timeout — 20% of runs):

14:00 - Login successful
14:30 - Inactivity threshold reached
14:30 - Attempt to access dashboard
14:30 - Redirected to login page ✓ (timeout worked)

Test 2 (Failed timeout — 80% of runs):

14:00 - Login successful
14:30 - Inactivity threshold reached
14:30 - Attempt to access dashboard
14:30 - Dashboard loads; still authenticated ❌ (timeout failed)

Actual Behavior

• User session persists beyond 30-minute timeout
• No logout/redirect occurs
• Session remains valid for subsequent API requests
• No error message or warning shown to user

Expected Behavior

• After 30 minutes of inactivity, session should expire
• User navigating to app should be redirected to login page
• API requests with expired token should return 401 Unauthorized
• Session data should be cleared from backend database

Root Cause Analysis (Pending)

Hypothesis 1:

Background API calls refreshing session timer

• App makes background calls (polling, sync) that reset the inactivity timer
• Investigation: Check network logs for unexpected API calls during "inactivity"

Hypothesis 2:

Session timeout logic has race condition

• Multiple processes checking/updating session state simultaneously
• Investigation: Database lock contention or async/await timing issues

Hypothesis 3:

Client-side session manager not honoring server-side expiration

• Server marks session as expired, but client doesn't check until API error
• Investigation: Review client token refresh logic

Attachments

Network Logs (Charles Proxy capture):

[14:00:05] POST /api/auth/login → 200 OK
[14:00:10] session_id=abc123def456 (set in cookies)
[14:15:00] GET /api/dashboard → 200 OK (unexpected API call during "inactivity")
[14:30:00] Attempted logout request (never sent)

Database Query Results:

-- Session table at 14:30
SELECT * FROM sessions WHERE user_id=123;
-- Result: session still exists; expires_at is in future (incorrect)

Impact Assessment

• Affected Users: All users
• Frequency: Intermittent (60–80% of cases)
• User Impact: Security risk on shared devices; potential data exposure if device left unattended; user may not realize they're still logged in
• Business Impact: Regulatory compliance risk (SOC2, GDPR); potential customer escalation if sensitive data accessed; must be fixed before release

Workaround

• For QA: Log out manually instead of relying on timeout.
• For Users: No workaround; security vulnerability requires fix.

Questions for Developer

1. Are background sync/polling calls updating the session timestamp?
2. Does the token refresh logic check server-side expiration?
3. Is there a race condition in the session check logic?
4. Can you enable debug logging to trace session lifecycle?

Next Steps

1. Developer to investigate root cause (prioritize Hypothesis 1 & 2)
2. Provide debug logs and code review findings
3. QA to validate fix with additional edge case testing
4. Security team to assess compliance implications
5. Customer communication if production impact exists