Skip to main content
2 min read Intermediate Web

Back button attack

Back Button Attack

AspectDetails
DescriptionAfter a user logs out (or on a shared device), pressing the browser Back button or reopening cached pages reveals sensitive data or restores an authenticated view. This happens when the server lets responses be cached and does not fully invalidate the session.
Conditions to be Vulnerable- Sensitive pages served with caching enabled.
- Session not invalidated server-side on logout.
- Missing Cache-Control: no-store on authenticated responses.
Where to Find- Post-login dashboards, account pages, and transaction confirmation pages.
- Logout flows on shared or public computers.
Common Exploits- Viewing cached private data after logout via Back navigation.
- Resubmitting forms or replaying actions from cached pages.
- Session restoration if the token remains valid server-side.
ExampleA user logs out of a banking app on a public PC. The next person presses Back and the cached account summary page renders with balances still visible.
How to Test1. Log in, browse sensitive pages, then log out.
2. Press the browser Back button and reload from cache (offline if needed).
3. Check whether sensitive data renders and whether the old session token still works in Burp Repeater.
ToolsBurp Suite, OWASP ZAP, browser DevTools, curl
Mitigation- Send Cache-Control: no-store, no-cache and Pragma: no-cache on authenticated pages.
- Invalidate the session server-side on logout.
- Avoid putting sensitive data in cacheable GET responses.

Resources

CreditURL
OWASP WSTG - Testing for Logout Functionalityhttps://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/06-Testing_for_Logout_Functionality
OWASP Cheat Sheet - Session Managementhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
MDN - Cache-Controlhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control