- Status Closed
-
Assigned To
cbay - Private
Opened by waloodi_109 - 04.08.2026
Last edited by cbay - 05.08.2026
FS#432 - Improper Cache Control Enabling Sensitive Data Exposure via Mobile Swipe Navigation
Improper Cache Control Enabling Sensitive Data Exposure via Mobile Swipe Navigation
Target admin.alwaysdata.com
Vulnerability Class CWE-525: Use of Web Browser Cache Containing Sensitive Information / Improper Cache-Control
Report Date August 4, 2026
Reported By [ Waleed Anwar ]
Severity [ e.g. Medium — CVSS 3.1: . ]
Affected Endpoint(s) [ e.g. /dashboard, /account, /admin/* ]
Status [ New submission ]
1. Summary
The application at admin.alwaysdata.com fails to set adequate Cache-Control headers on pages containing session-authenticated or sensitive account data. On mobile browsers (iOS Safari / Android Chrome), swipe-based back/forward navigation restores a full-page snapshot from the browser's back-forward cache (bfcache) rather than issuing a fresh request to the server. As a result, sensitive content may remain visible to a subsequent user of the same device even after logout or session expiry.
2. Vulnerability Details
2.1 Root Cause
HTTP responses for authenticated pages do not include a strict no-store cache directive, or include a weaker directive that still permits browser-level storage of the rendered page. This allows swipe-gesture navigation on mobile browsers to render a cached snapshot of a previously authenticated state.
2.2 Observed Headers
GET /dashboard HTTP/1.1
Host: admin.alwaysdata.com
HTTP/1.1 200 OK
[ Cache-Control: <value observed, or note if header is absent> ]
[ Pragma: <value observed, or note if header is absent> ]
[ Expires: <value observed, or note if header is absent> ]
2.3 Expected / Recommended Headers
Cache-Control: no-store, no-cache, must-revalidate, private
Pragma: no-cache
3. Steps to Reproduce
• Log in to admin.alwaysdata.com on a mobile browser (iOS Safari or Android Chrome) Navigate to a sensitive/authenticated page.
• Log out of the application
• Perform a swipe-back gesture (iOS edge-swipe or Android back gesture)
• Observe[ sensitive data was exposed, while in login page email and password was also shown].
4. Impact
• Shared/public device exposure: a subsequent user of the same device may view a previous user's authenticated session data via swipe navigation
• Post-logout data persistence: sensitive account information remains visible after the session has ended
• [ Add any additional impact confirmed during testing, e.g. exposure of specific data fields, tokens, or admin functionality ]
6. Recommended Remediation
• Apply Cache-Control: no-store, no-cache, must-revalidate, private to all responses containing session-bound or sensitive data
• Include a Pragma: no-cache header for legacy HTTP/1.0 client compatibility
• Send a Clear-Site-Data header on logout to purge cached data client-side
• For single-page app views, listen for the pageshow event and check event.persisted to force re-authentication or a fresh data fetch when a page is restored from bfcache
• Re-test explicitly with swipe-back gestures on iOS Safari and Android Chrome after remediation, not solely the desktop back button, as bfcache behavior differs by platform and browser engine.
Thank You,
Waleed Anwar
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
az_recorder_20260804_163132.m...
Hello,
That report is bogus. First, the /dashboard endpoint doesn't even exist. Second, we do return the Cache-Control: no-store, no-cache, must-revalidate, private header.
Kind regards,
Cyril
Have you watched the video clearly?, take any endpoint when you login https://admin.alwaysdata.com/user/, while swiping you can clearly see that data is exposing.
It's a matter of post-logout information disclosure via BFCache restoration