PHP 8.6 Finally Makes Session Cookies Secure by Default

PHP 8.6 is approaching its soft feature freeze on August 11, 2026, with beta 1 following two days later. Alpha 3 shipped July 30. Between now and the freeze, the RFC list for 8.6 is effectively locked in, and one accepted change deserves more attention than it has gotten: the Secure Session Configuration Defaults RFC flips three long-standing php.ini defaults from insecure to secure. It passed 27 to 0 with zero abstentions, which is a strange thing to say about a change that sat rejected for nearly a decade.

The three settings that change

The RFC, authored by Jorg Sowa and merged into php-src this year, changes three defaults:

session.use_strict_mode: 0 to 1
session.cookie_httponly: 0 to 1
session.cookie_samesite: "" (unset) to "Lax"

None of these are new settings. All three have existed in PHP for years, cookie_httponly since PHP 5.2.0 in 2006. What changes in 8.6 is only the default value a fresh install starts with. If your php.ini already sets these explicitly, nothing changes for you. If you have never touched them, a new PHP 8.6 install behaves differently than PHP 8.5 did out of the box.

Why each one matters

session.use_strict_mode closes a session fixation hole. Without it, PHP will happily accept any session ID a client sends, including one an attacker planted in a victim’s browser before that victim logs in. Once the victim authenticates, the attacker’s pre-set ID becomes a valid, authenticated session, and the attacker already knows the ID because they chose it. With strict mode on, PHP validates a proposed session ID before accepting it. The built-in files session handler checks whether a file for that ID already exists on disk. An attacker-supplied ID that was never legitimately issued has no such file, so PHP discards it and generates a fresh, unpredictable one instead.

session.cookie_httponly keeps JavaScript out of the session cookie entirely. It is defined in RFC 6265 and has been supported by every major browser since Internet Explorer 6. With the flag set, document.cookie in the browser simply does not include the session cookie, whether the script reading it is your own first-party code or something an attacker injected through an XSS bug. It does not stop XSS itself, but it neutralizes the single most common payload attackers reach for once they land one: stealing the session cookie and replaying it elsewhere.

session.cookie_samesite set to Lax tells the browser not to attach the session cookie to cross-site requests, with one carve-out: top-level navigations using safe methods, meaning a user clicking a link into your site still arrives logged in if they already had a session. What it blocks is the cross-site POST a CSRF attack depends on, since that request will simply arrive without the session cookie attached and get treated as anonymous.

Individually these are not new ideas. The OWASP Session Management Cheat Sheet has recommended all three for years. What is new is that PHP itself now agrees with its own security guidance out of the box.

Testing it yourself

If you want to see the new defaults before GA, PHP 8.6.0alpha3 is available now, with beta 1 due August 13. A quick way to confirm the values without installing anything permanent is php -i against a build compiled from a fresh php.ini:

php -i | grep -E 'session\.(use_strict_mode|cookie_httponly|cookie_samesite)'

On 8.5 and earlier, that produces Off, Off, and a blank value. On an 8.6 build with an untouched php.ini, it produces On, On, and Lax.

What this means for existing applications

The RFC only changes what a fresh php.ini ships with. It does not retroactively touch a configuration file that already sets these directives, and most production php.ini files inherited from distro packages or Docker base images already have explicit values written in, often the old insecure ones, copied forward from install to install for a decade. Upgrading to 8.6 will not fix that file for you.

If you are running raw PHP sessions without a framework, it is worth checking what you actually have rather than assuming a recent PHP version means secure defaults:

; php.ini
session.use_strict_mode = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

Or, if you cannot touch php.ini on a shared host, set them at runtime before session_start():

ini_set('session.use_strict_mode', '1');
ini_set('session.cookie_httponly', '1');
ini_set('session.cookie_samesite', 'Lax');

session_start();

Laravel and Symfony users are already covered, mostly

If you build on Laravel, config/session.php has shipped with 'http_only' => true and 'same_site' => 'lax' as defaults for a long time already, so the framework has been ahead of raw PHP here regardless of what version you run. Laravel’s session driver also does not depend on PHP’s native session extension by default, so the use_strict_mode change does not apply the same way. It is still worth opening that config file and confirming those two values have not been overridden in your project, since a .env override or an old config publish from years back can quietly reintroduce the old behavior.

Symfony’s framework.yaml session configuration defaults to cookie_httponly: true as well, and recent Symfony versions default cookie_samesite to lax. Same advice applies: check, do not assume.

Where the PHP-level default actually matters most is smaller, framework-free applications, legacy codebases running plain session_start(), and any internal tool nobody has touched since it was written. Those are exactly the applications least likely to get an explicit audit, and exactly where “the language default just got safer” pays off.

A decade-long backstory, briefly

The use_strict_mode default was proposed once before, back in 2016, and it was rejected. This year’s RFC covers the same ground plus cookie_httponly and adds cookie_samesite on top, and it passed without a single vote against. Sowa has been working through ext/session for a while, with over twenty merged pull requests focused on making the extension’s behavior predictable rather than merely legacy-compatible. This RFC is one piece of that broader cleanup, not an isolated fix.

Bottom line

None of these three settings are exotic. Every serious PHP security guide has recommended them for years, and most experienced teams already set them explicitly. What changes in PHP 8.6 is the floor: a brand-new install, with a default php.ini, and zero security review, is now measurably harder to attack out of the box than it was on 8.5. That is a good trade for three lines nobody has to remember to write.