Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

You cannot reliably disable a browser’s Back button with PHP or ordinary page script. Instead, check authentication and authorization on every protected request, and set an appropriate cache policy for sensitive responses. After logout, this keeps protected data inaccessible even if the browser revisits its history; cache headers can influence what appears, but cannot guarantee that an old screen will never briefly reappear.

Why the Back button can still show a page

Browser history is controlled by the browser. A page may return from its back/forward cache as a saved snapshot rather than through a fresh request to PHP. MDN explains that the no-cache directive does not guarantee revalidation for history navigations, including Back-button use. That means even a carefully configured response cannot promise that a previously rendered screen will never appear again.

That visible behavior is separate from whether a user can access protected data or perform a protected action. Enforce those controls on the server whenever the resource is requested. A redirect to login after logout can improve the flow, but it does not erase history or replace access checks.

Protect every PHP endpoint on the server

Start the session, then verify the user is signed in and authorized for the specific resource before sending protected content. Apply the same checks to pages, downloads, API routes, and actions that change data; hiding a link or redirecting from one page is not sufficient.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
<?php
session_start();

if (empty($_SESSION['user_id'])) {
    header('Location: /login.php', true, 302);
    exit;
}

// Also check that this user is authorized for the requested resource.

This is an illustrative gate, not a complete login or logout system. Your application must invalidate the session during logout and define authorization checks appropriate to each resource. If a browser makes a new request after logout or session expiration, the server should deny it or redirect to login. If it restores an old snapshot without making a request, the server cannot control that display at that moment; protected operations still need server-side checks.

Choose cache headers for the sensitivity of the response

Cache directives affect whether responses may be stored and how they are reused. They are not a substitute for authorization. For sensitive authenticated pages, PHP’s session security guidance recommends the nocache session cache limiter. If you are choosing response directives yourself, understand the distinction between no-cache and no-store:

Directive Storage and reuse Practical trade-off
no-cache Allows storage, but requires validation before ordinary cache reuse. Does not guarantee revalidation on history navigation; a browser may restore a back/forward-cache snapshot. MDN also notes that must-revalidate does not guarantee revalidation for that navigation. See MDN’s Cache-Control reference.
no-store Instructs caches not to store the response. May be appropriate for particularly sensitive responses, but can forfeit browser features such as the back/forward cache. It cannot erase a representation that was already stored. See MDN’s Cache-Control reference.

Use a policy that matches the sensitivity and freshness needs of the page. Do not treat either directive as a Back-button lock or as proof that a user is authorized. MDN’s HTTP caching guide explains the broader caching behavior and trade-offs.

Configure PHP sessions before output

PHP documents session.cache_limiter as controlling cache-related headers for session pages. Its documented default is nocache; the available limiter values include nocache, private, private_no_expire, and public. PHP’s security guidance recommends nocache for authenticated sessions and warns that private caching can expose content on shared clients. See Securing Session INI Settings and Session Runtime Configuration.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  1. Set session configuration before session_start() and before any response body output. PHP’s documented default is nocache, but check the deployed configuration rather than assuming every route uses it.
  2. For an endpoint that needs a different policy, decide which layer owns the headers: PHP session settings, application or framework code, web server, reverse proxy, or CDN. Avoid conflicting or duplicate policies.
  3. Inspect the actual response headers in browser developer tools or with an HTTP client. PHP’s header() documentation covers sending response headers and their interaction with session cache limiting.
  4. Test logout and session expiration in the browsers your application supports. Verify both the visible history behavior and, more importantly, that protected requests and actions are denied after access ends.

Keep session-cookie protections separate from caching

Cookie and session settings help protect the session identifier; cache policy governs storage and reuse of page responses. PHP recommends using strict session mode and, for HTTPS-only sites, secure cookies. It also recommends HttpOnly and an appropriate SameSite setting. These controls strengthen session handling but do not make an already rendered page disappear. See PHP’s session security guidance.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Do not use JavaScript to fake a security boundary

Calling history.back() or history.go(-1) navigates history; it does not secure a page. MDN states that unprivileged code cannot clear session history or disable Back/Forward navigation. location.replace() can replace the current history entry when that is suitable for application flow, but it is not an access-control measure. Avoid redirect loops or scripts that continually rewrite history: users can still request protected URLs directly, and server-side checks remain necessary.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.