To stop session fixation in PHP, call session_regenerate_id(), or the timestamp-based rotation shown below, whenever a user’s privilege changes. Do it before you store the authenticated user in $_SESSION. Don’t destroy the old session on the spot. Mark it with a timestamp and refuse it after a short grace period, and enforce your own idle and absolute timeouts, because PHP’s garbage collector is not a timeout. That is what PHP’s own manual asks for. Below is a helper that follows it, tested against a fixation attack, plus the one shortcut in the manual’s example that brings the attack back if you use it at login.

Every behaviour here was run on PHP 8.3.6 CLI with the built-in web server (php -S) and curl, using the default files save handler. The cookie flags and php.ini settings that go with this code are covered in our php.ini security hardening guide. This article is about the session lifecycle in your application code.

The attack strict mode doesn’t stop

session.use_strict_mode=1 makes PHP reject a session ID it never issued. That stops an attacker inventing an ID such as PHPSESSID=123456. But the PHP manual is explicit about the gap: “an attacker can force users to use an initialized session ID which has been created by an attacker.” The attacker visits your site, receives a real ID, and plants it in the victim’s browser. The manual describes two routes: setting a cookie that the browser’s precedence rules let override yours (for example from another subdomain), and JavaScript injection. If your login code keeps that ID, the attacker now holds an authenticated session.

We reproduced it with a minimal app whose login does only $_SESSION['uid'] = 42;, run with strict mode on:

$ PHPFLAGS="-d session.use_strict_mode=1" ./test.sh naive 8090
attacker ID: pmq468mni64u18nhukmh7vqe1v
logged in
ID after login: unchanged
attacker replays old ID: account page for uid 42

The test script fetches / to get a real ID, sends /login with that ID as the victim, then replays the ID as the attacker.

What PHP’s manual requires

The session security chapter is unusually prescriptive. The rules that matter for application code:

• Rotate on privilege change, before writing auth state. “Session IDs must be regenerated when user privileges are elevated, such as after authenticating. session_regenerate_id must be called prior to setting the authentication information to $_SESSION.” Rotate again on any later privilege change, such as entering an admin area or completing step-up authentication. The OWASP Session Management Cheat Sheet makes the same point: renew the ID “after any privilege level change”.
• Don’t delete active sessions immediately. “session_regenerate_id(true); and session_destroy must never be called together for an active session.” Deleting right away loses sessions when requests overlap or the new cookie never arrives. It also removes your chance to notice that someone used an old ID.
• Use timestamps instead. Set “a short-term expiration time (timestamp) in $_SESSION” on the old session and refuse it later: “a few seconds later for stable networks… and a few minutes later for unstable networks such as cell phones or Wi-Fi.”
• Don’t rely on session.gc_maxlifetime for expiry. “Attackers may access a victim’s session ID periodically to prevent its expiration and keep exploiting it.” The setting only controls when data “will be seen as ‘garbage’ and potentially cleaned up” (default 1440 seconds).
• Treat obsolete-ID access as a signal. When an expired ID is used, the manual recommends removing “authenticated status from all of the user’s sessions” and forcing re-authentication.

The session_regenerate_id() page has two example implementations. Both are labelled “not fully working code, but an example!”

A tested rotation helper

session_guard.php follows the manual’s pattern, with two corrections we found in testing (explained after the code). It targets PHP 8.1 or later (session_create_id() exists from 7.1, and the cookie-options array for setcookie() from 7.3).

<?php
// session_guard.php: timestamp-based session ID rotation, adapted from the
// pattern in the PHP manual's session_regenerate_id() page.
declare(strict_types=1);

defined('SESSION_GRACE')    || define('SESSION_GRACE', 60);     // old ID usable after rotation (s)
defined('SESSION_IDLE')     || define('SESSION_IDLE', 1800);    // idle timeout (s)
defined('SESSION_ABSOLUTE') || define('SESSION_ABSOLUTE', 28800); // absolute timeout (s)
defined('SESSION_ROTATE')   || define('SESSION_ROTATE', 900);   // periodic rotation (s)

final class ObsoleteSessionAccess extends RuntimeException {}

function secure_session_start(): void
{
    ini_set('session.use_strict_mode', '1');
    session_start();
    $now = time();

    // 1. Old ID after rotation: allow a short grace period, then refuse.
    if (isset($_SESSION['destroyed'])) {
        if ($_SESSION['destroyed'] < $now - SESSION_GRACE) {
            throw new ObsoleteSessionAccess('obsolete session ID used');
        }
        if (isset($_SESSION['new_session_id'])) {
            // Cookie for the new ID was probably lost: move the client over.
            session_commit();
            session_id($_SESSION['new_session_id']);
            session_start();
            return;
        }
    }

    // 2. Idle and absolute timeouts, enforced in application code.
    if (isset($_SESSION['uid'])) {
        if ($now - ($_SESSION['last_seen'] ?? 0) > SESSION_IDLE
            || $now - ($_SESSION['created'] ?? 0) > SESSION_ABSOLUTE) {
            secure_logout();
            session_start();
            return;
        }
        $_SESSION['last_seen'] = $now;
        if ($now - ($_SESSION['rotated'] ?? 0) > SESSION_ROTATE) {
            secure_regenerate(true);
        }
    }
}

// $forward: let a client still holding the old ID be moved to the new one
// during the grace period (lost Set-Cookie on a flaky network). Never forward
// on a privilege change: whoever holds the old ID would be handed the new one.
function secure_regenerate(bool $forward): void
{
    $data = $_SESSION;                      // session_start() below loads an empty session
    $new = session_create_id();
    if ($forward) {
        $_SESSION['new_session_id'] = $new;
    }
    $_SESSION['destroyed'] = time();
    session_commit();                       // old session keeps the markers

    session_id($new);
    ini_set('session.use_strict_mode', '0'); // let session_start() accept $new
    session_start();
    ini_set('session.use_strict_mode', '1');
    $_SESSION = $data;
    $_SESSION['rotated'] = time();
}

function secure_login(int $uid): void
{
    secure_regenerate(false);               // rotate BEFORE marking authenticated
    $_SESSION['uid'] = $uid;
    $_SESSION['created'] = $_SESSION['last_seen'] = time();
}

function secure_logout(): void
{
    $_SESSION = [];
    $p = session_get_cookie_params();
    setcookie(session_name(), '', [
        'expires' => time() - 3600, 'path' => $p['path'], 'domain' => $p['domain'],
        'secure' => $p['secure'], 'httponly' => $p['httponly'], 'samesite' => $p['samesite'] ?: 'Lax',
    ]);
    session_destroy();
}

Wire it in by calling secure_session_start() instead of session_start(), secure_login($userId) after you have verified the password and any second factor, and secure_logout() from your logout handler. On ObsoleteSessionAccess, return 401 and log the event.

What we tested

Against the same attack, with the helper in place:

$ ./test.sh guard 8086
attacker ID: jt6upaht8b1i3hcuuk743hivm5
logged in
ID after login: 24qohqtgd4trsgfuov1tjn20nm
attacker replays old ID: anonymous

Periodic rotation, with rotation forced on every request and a 2-second grace period:

$ ./test2.sh
account page for uid 42
login ID 10d0f50p49pto2ocoffotrbsv3 rotated to r4428iae8369vin9533ubpb292
old ID inside grace: account page for uid 42
old ID after grace:  401 obsolete session
logout with current ID: logged out
current ID after logout: anonymous

With a 1-second idle timeout, a request made 3 seconds after login came back anonymous with a new session cookie, and the logged-in session’s file was gone from session.save_path. The pre-login session stayed on disk, marked as destroyed, until garbage collection, as the manual intends.

Correction 1: never forward an old ID after login

The manual’s second example deals with lost cookies: if the old ID comes back during the grace period, it switches the client to the new ID it stored in the old session. That is reasonable for periodic rotation, where the person holding the old ID is almost always the legitimate user. At login it is a hole. The attacker holds the old, pre-login ID, so forwarding hands them the new, authenticated one.

Our first draft forwarded in both cases, and the fixation test failed: the attacker’s replay returned account page for uid 42. The manual hints at this in a comment (“Do not try to set session ID again if you would like to remove authentication flag”). The helper makes it explicit: secure_regenerate(false) at login, secure_regenerate(true) only for timed rotation. The trade-off is that a user whose login response is lost has to log in again.

Correction 2: carry the session data across

In the manual’s example, the new session is started with session_id($new); session_start();. In our test on PHP 8.3.6, that started an empty $_SESSION: the authenticated user vanished on the first periodic rotation. The helper copies the data before committing the old session and restores it after starting the new one. At login this also keeps pre-login state, such as a cart.

Other session rules worth enforcing

• Timeouts. OWASP gives common idle timeouts of “2-5 minutes for high-value applications and 15-30 minutes for low risk applications”. Every session should also have an absolute timeout “regardless of session activity”. The helper’s defaults (30 minutes idle, 8 hours absolute) are examples; set your own.
• Locking. PHP locks session data per request, which attackers can abuse to tie up workers. The manual suggests session_start(['read_and_close' => true]) for requests that only read the session, and session_commit() as soon as you have finished writing.
• Remember-me is not a long session. The manual says not to “use long life session IDs for auto-login”. Use a separate, single-use random token in its own cookie, and replace it each time it is used.
• Track active sessions if you need “log out everywhere” or the manual’s response to obsolete-ID access. PHP doesn’t do this for you. The manual suggests a user-ID-prefixed ID from session_create_id(), which “is vital” to pair with strict mode. Don’t use a confidential value as the prefix.
• Sessions don’t stop CSRF. “Sessions and authentication do not protect against CSRF attacks.” See our CSRF defences comparison.
• Session files are an attack surface. October’s PHP2Shell attempts tried to plant code through session files. See the PHP2Shell patch-and-hunt guide.

Common mistakes

Limits of this article

The helper is a tested example, not a drop-in library. It assumes PHP’s default files handler. A custom or Redis save handler must implement session ID validation for strict mode to work, as the manual notes for user-defined handlers. It does not implement the cross-session “remove authentication from all of the user’s sessions” response, which needs an active-session registry. If you use a framework, prefer its session layer to this helper, and check that it rotates the ID at login and enforces timeouts. Our tests ran on a single PHP process. We did not load-test concurrent requests during rotation.

Sources and verification

To harden PHP for production, start from php.ini-production, then change six settings it leaves permissive: turn off expose_php, turn on session.use_strict_mode, set the session cookie’s HttpOnly, Secure and SameSite flags, and turn off allow_url_fopen if your code never reads URLs as files. Apply them in php.ini or with php_admin_value in the PHP-FPM pool so applications cannot undo them, and do not treat disable_functions or open_basedir as a sandbox.

Everything below was checked against PHP 8.4.27’s php.ini-production and the PHP manual, and every behaviour we describe was run on PHP 8.3 CLI (Ubuntu 24.04 package). Where a setting behaves differently under PHP-FPM or Apache, we say so.

The baseline

“Built-in default” is what PHP uses with no php.ini at all (php -n). Bold marks the six settings where the production template differs from the hardened value. We measured both columns with the audit script at the end of this article.

Where to set them so they stick

PHP settings come from several layers, and the later ones can override the earlier ones for directives that allow it: php.ini and its scan directory, web server or FPM pool configuration, .user.ini files in the document root, and ini_set() in code. Each directive has a changeable mode. INI_SYSTEM settings such as disable_functions, allow_url_fopen and allow_url_include can only be set in php.ini or server configuration.

For PHP-FPM, use php_admin_value and php_admin_flag for anything security-relevant. The PHP-FPM documentation says: “Settings defined with php_admin_value and php_admin_flag cannot be overridden with ini_set.” Plain php_value and php_flag can be.

; /etc/php/8.3/fpm/pool.d/app.conf (path varies by distribution)
[app]
user = app
group = app
listen = /run/php/app.sock

php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php/app-error.log
php_admin_flag[allow_url_fopen] = off
php_admin_value[session.use_strict_mode] = 1
php_admin_value[session.cookie_httponly] = 1
php_admin_value[session.cookie_secure] = 1
php_admin_value[session.cookie_samesite] = Lax

; Only execute .php files (the default also allows .phar)
security.limit_extensions = .php

This is illustrative: we validated the directive names and values against the PHP-FPM documentation and our CLI tests, but did not run this pool file. Restart the pool after editing. For Apache with mod_php, the equivalent is php_admin_value and php_admin_flag in the virtual host.

You can see runtime locking in action. With disable_functions set in configuration, ini_set('disable_functions', '') returns false and changes nothing. With open_basedir set, an attempt to widen it to / also returns false.

Stop advertising your PHP version

php.ini-production ships with expose_php = On. Its comment says the header “is no security threat in any way”, and that is fair: hiding the version does not fix anything. But the header tells every scanner which PHP release you run, which turns mass scanning for a new CVE into a simple header match. We ran PHP’s built-in server with each value:

$ curl -sI http://127.0.0.1:8099/index.php | grep -i x-powered   # expose_php=1
X-Powered-By: PHP/8.3.6
$ curl -sI http://127.0.0.1:8099/index.php | grep -i x-powered   # expose_php=0
$

Frameworks and reverse proxies can add their own version headers, so check the response at the edge too. Our guide to HTTP security headers covers the headers you do want to send.

Log errors, never display them

The production template sets display_errors = Off and log_errors = On, and its comment explains why: displayed errors could leak “sensitive information … such as database usernames and passwords or worse.” The built-in defaults are the opposite, so a server that runs PHP without loading a php.ini (a misconfigured container is the usual case) will print errors to users. Point error_log at a file or stderr that your logging pipeline collects.

Turn off URL includes and, if you can, URL file reads

allow_url_include lets include and require load code from a URL. It is off by default and the PHP manual marks it “Deprecated as of PHP 7.4.0”; enabling it now prints a deprecation notice at startup. Keep it off.

allow_url_fopen is broader: it lets file_get_contents(), fopen() and similar functions open http:// and ftp:// URLs. If your application only makes HTTP requests through cURL or an HTTP client library, turning it off removes one way for user input passed to a file function to become an outbound request. It does not stop server-side request forgery through your HTTP client; see our SSRF guide for that. Test before you change it: some libraries and package managers rely on it.

Session settings

PHP’s session defaults favour compatibility. Four changes matter.

Strict mode

The PHP manual is blunt: “Enabling session.use_strict_mode is mandatory for general session security. All sites are advised to enable this.” Without it, PHP accepts any session ID the browser sends, even one the server never issued, which enables session fixation. We simulated a browser sending an attacker-chosen PHPSESSID cookie:

<?php
// strict.php: run with `php -d session.use_strict_mode=0|1 strict.php`
ini_set('session.save_path', __DIR__);
$_COOKIE[session_name()] = 'attackerchosenid123456';
session_start();
printf("use_strict_mode=%s -> session_id=%s\n", ini_get('session.use_strict_mode'), session_id());

$ php -d session.use_strict_mode=0 strict.php
use_strict_mode=0 -> session_id=attackerchosenid123456
$ php -d session.use_strict_mode=1 strict.php
use_strict_mode=1 -> session_id=3e4393b3059589b68078c6a9f5c4fe34

Strict mode does not replace calling session_regenerate_id(true) after login; do both.

Cookie flags

• session.cookie_httponly = 1 makes the cookie inaccessible to JavaScript. The manual says it “can effectively help to reduce identity theft through XSS attacks”. It does not stop an XSS payload from making requests as the user.
• session.cookie_secure = 1 sends the cookie only over HTTPS. The manual notes that with it on, “sessions only work with HTTPS connections”. If TLS terminates at a load balancer, that means the browser’s connection: the flag is a cookie attribute the browser enforces, so it works as long as users reach you over HTTPS.
• session.cookie_samesite = Lax stops the browser sending the session cookie on most cross-site subrequests and form posts. It reduces CSRF exposure but does not remove the need for tokens; we compare the options in CSRF protection: SameSite, tokens and Fetch Metadata.

These cookie protections address token theft through the browser. They do nothing about a cookie stolen from the endpoint itself, which our explainer on token theft and MFA covers.

Request size and resource limits

post_max_size (8M in both defaults), upload_max_filesize (2M), max_input_vars (1000), memory_limit (128M) and max_execution_time (30 seconds) are mainly availability controls. Set them to what your application needs, not higher, and enforce body size limits at the web server or proxy as well, because those apply before PHP parses anything.

These limits briefly became security-critical in October 2026. PHP’s stopgap advice for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) included a low post_max_size, memory_limit=-1 set non-overridably and session.upload_progress.enabled=0. Those were emergency measures for unpatched servers and PHP said they “do not make an installation safe”. Once patched, keep a finite memory_limit unless you have a container or cgroup limit doing that job. Note that session.upload_progress.enabled is on by default and in the production template; if your application does not show upload progress bars, turning it off removes a feature you do not use.

What not to rely on

Two directives look like sandboxes and are not.

disable_functions removes named internal functions. With system, exec and shell_exec disabled, calling system() raises Error: Call to undefined function system(), which defeats the laziest webshells. But the PHP manual says plainly: “This directive can be circumvented and should not be considered a sufficient security measure for shared hosting environments.” It only covers internal functions you thought to list, and in PHP 8 a disabled function’s name can be redefined by userland code.

open_basedir limits which paths PHP’s file functions can open, and the manual says symlinks are resolved so they cannot be used to escape it. It is still not an isolation boundary. The same manual notes that “With dynamic loading, it’s possible to ignore all open_basedir restrictions”, which is one reason to keep enable_dl off, and the restriction only applies to PHP’s own file access, not to anything a spawned process does. It also disables PHP’s realpath cache, which has a performance cost.

If you host more than one application, or code you do not fully trust, isolate them at the operating system level: a separate PHP-FPM pool per application running as its own Unix user, with file permissions that stop one user reading another’s files, or separate containers. That is the boundary; the two directives above are defence in depth inside it.

Audit what is actually running

The settings that matter are the ones the serving process loaded, which may not be the php.ini you edited. The CLI and FPM usually read different files (on Debian and Ubuntu, /etc/php/<version>/cli/ and /etc/php/<version>/fpm/). This script prints the effective values against the baseline above. Run it under the SAPI you care about: from the command line for the CLI, or temporarily as a web request for FPM or mod_php (then delete it, since it reveals configuration).

<?php
// ini-audit.php: compare effective settings with a hardened baseline.
$baseline = [
    'expose_php'               => '0',
    'display_errors'           => '0',
    'display_startup_errors'   => '0',
    'log_errors'               => '1',
    'allow_url_include'        => '0',
    'allow_url_fopen'          => '0',   // only if the app never opens URLs with file functions
    'enable_dl'                => '0',
    'session.use_strict_mode'  => '1',
    'session.use_only_cookies' => '1',
    'session.cookie_httponly'  => '1',
    'session.cookie_secure'    => '1',
    'session.cookie_samesite'  => 'Lax',
    'session.use_trans_sid'    => '0',
];
$norm = fn($v) => match (strtolower((string)$v)) {
    'on', 'true', 'yes' => '1', 'off', 'false', 'no', '' => '0', default => (string)$v };

$fail = 0;
foreach ($baseline as $key => $want) {
    $have = ini_get($key);
    $ok = ($key === 'session.cookie_samesite')
        ? in_array($have, ['Lax', 'Strict'], true)
        : $norm($have) === $want;
    $fail += $ok ? 0 : 1;
    printf("%-26s %-6s want %-5s %s\n", $key, var_export($have, true), $want, $ok ? 'ok' : 'CHECK');
}
printf("\n%d setting(s) differ from the baseline (SAPI: %s, ini: %s)\n",
    $fail, PHP_SAPI, php_ini_loaded_file() ?: 'none');

Run against PHP 8.4.27’s php.ini-production with php -c php.ini-production ini-audit.php on PHP 8.3 CLI, it reported:

expose_php                 '1'    want 0     CHECK
display_errors             ''     want 0     ok
display_startup_errors     ''     want 0     ok
log_errors                 '1'    want 1     ok
allow_url_include          ''     want 0     ok
allow_url_fopen            '1'    want 0     CHECK
enable_dl                  ''     want 0     ok
session.use_strict_mode    '0'    want 1     CHECK
session.use_only_cookies   '1'    want 1     ok
session.cookie_httponly    ''     want 1     CHECK
session.cookie_secure      '0'    want 1     CHECK
session.cookie_samesite    ''     want Lax   CHECK
session.use_trans_sid      '0'    want 0     ok

6 setting(s) differ from the baseline (SAPI: cli, ini: php.ini-production)

With no php.ini at all (php -n), 10 of the 13 differed. With the hardened values applied, none did.

Limits of this article

This covers PHP’s own configuration, not your web server, framework or application code. We tested behaviour on PHP 8.3 CLI and read defaults from PHP 8.4.27’s template; check the manual for your version, since defaults and deprecations change between releases. The PHP-FPM pool example was not run. The baseline is a starting point for a typical web application: turning off allow_url_fopen in particular can break code that depends on it, so test in staging first.

Sources and verification