Secure Session Settings

The attacker visits your site normally and receives a valid session ID: PHPSESSID=abc123. Nothing is logged in yet. Now the attacker gets the victim to load a URL carrying that same ID — https://shop.example/login?PHPSESSID=abc123 works whenever PHP accepts session IDs from the URL, and an attacker-supplied cookie or a crafted link to a sibling subdomain achieves the same trick. The victim logs in. The session record for abc123 now holds an authenticated user, and the attacker, who already knows the ID, is simply logged in too. No password, no XSS, no stolen cookie — the ID was fixed before authentication ever happened. This is session fixation, and it is the reason login is not just a write to $_SESSION.

PHP enabled this attack surface itself in older days: session.use_trans_sid transparently appended PHPSESSID= to every generated link when a cookie was missing, so a shared URL literally passed someone's session around. It defaults to off now and session.use_only_cookies=1 kills the URL channel entirely — but hand-built links that stash session_id() in a query string, or email campaigns that put IDs in tracking URLs, reintroduce the same hole by hand.

PHP gives you two independent defenses, and you want both:

// php.ini — refuse IDs the server never issued (PHP 5.5.2+)
session.use_strict_mode = 1

// in code — at the moment privileges change
if (loginSucceeds($user, $password)) {
    session_regenerate_id(true);   // new ID; old record deleted
    $_SESSION['user_id'] = $user->id;
}

session.use_strict_mode = 1 makes session_start() reject any ID the server did not generate itself: hand it an uninitialized value and it silently issues a fresh one. That closes the URL-parameter and attacker-set-cookie vectors at the source. session_regenerate_id(true) handles the other half — the ID your legitimate user was already carrying may be known to someone (it sat in a shared URL, a log file, a proxy cache), so at every privilege change you discard it. The true argument deletes the old session record; the default false leaves it behind, which means the attacker's copy of the old ID still works — a mistake that shows up in security reviews constantly.

Timing and scope are where implementations go wrong:

• Regenerate after the credentials verify, not before. Regenerating first then failing the login leaves the user on a known-to-attacker ID anyway if an error path reverts.
• Regenerate on login, on password change, on role elevation — not on every request. A new ID per request breaks every parallel tab the moment the browser presents a stale cookie, and it multiplies session files.
• session_regenerate_id() cannot run after output has been sent, same as session_start() — it belongs in the controller before rendering.

session_create_id() (PHP 7.1+) covers the rare case where you must mint an ID for a subsystem yourself — seeding a legacy session store during a migration, for example. It returns a fresh, prefixed ID without opening a session; adopting it still goes through session_id($newId) before start, which is precisely the dangerous call that strict mode exists to neutralize, so treat it as a migration tool and not a request-path primitive.

One caveat for interviews: regeneration protects the login transition. If an attacker steals the cookie after login (network capture, malware), only the cookie flags of the next chapter and server-side revocation of the last chapter limit the damage. Fixation defense is not theft defense — the two get conflated in write-ups all the time.

"What hardens a PHP login against session fixation?" is a near-certain security interview question. The full answer is three moves: use_strict_mode=1, session_regenerate_id(true) inside the success branch, and never accepting session identifiers from URLs (session.use_only_cookies=1, on by default since PHP 5.3).

The session cookie is a bearer token: whoever presents it is that user. Every hardening below exists to narrow who can read it, where it travels, and which requests replay it.

HttpOnly. With session.cookie_httponly = 1, the HttpOnly attribute is set on Set-Cookie and browsers refuse to expose the cookie to document.cookie or any script. That single flag turns an XSS bug from "attacker steals every session" into "attacker runs one page load." It is the highest-value session setting in PHP because it defaults off. What it does not do: prevent the attacker's injected script from acting as the user (CSRF territory), and it does nothing against non-browser clients.

Secure. session.cookie_secure = 1 sends the cookie only over HTTPS, so a user who once logged in over https: and later loads an http: page on the same site does not leak the token in plaintext. The classic development trap: flip it on locally and every session "randomly" dies over http://localhost because the cookie is never sent. Terminate TLS in local dev (Caddy, valet secure, mkcert) instead of disabling the flag.

SameSite. session.cookie_samesite = 'Lax' (PHP 7.3+) stops the cookie riding along on cross-site POSTs — the basic CSRF posture — while keeping normal top-level navigation working. Strict is stricter and breaks links from email clients and search results. None disables the protection and legally requires Secure; modern browsers reject SameSite=None without it.

Cookie prefixes. Two reserved names add origin guarantees that a rogue sibling subdomain cannot fake:

With session.name = '__Host-PHPSESSID', a compromised evil.example.com cannot overwrite the main app's cookie with Domain=.example.com, because the browser rejects any __Host- cookie carrying a Domain attribute.

The hardened configuration, all of it settable per start:

session_set_cookie_params([
    'lifetime' => 0,
    'path'     => '/',
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);
session_name('__Host-PHPSESSID');
session_start();

Verify the flags the way an attacker would — read the raw response header:

curl -skI https://localhost/login | grep -i set-cookie
# Set-Cookie: __Host-PHPSESSID=4f8a...; path=/; HttpOnly; Secure; SameSite=Lax

A missing attribute in that one line outranks any framework config file, because middleware can silently drop params set earlier in the stack. Reverse proxies add their own trap: when TLS terminates at nginx or the platform router, PHP sees plain HTTP, and any conditional that keys off $_SERVER['HTTPS'] turns Secure off in production exactly when you need it. Forward the proxy's X-Forwarded-Proto (from trusted proxies only) or set the flag unconditionally outside local development. Pairing these flags with a Content-Security-Policy shrinks the XSS window further, but the policy itself belongs to the output-escaping story.

Frameworks set these by default in new projects; auditing a legacy app's php.ini against this list is a realistic review task. One boundary worth stating in interviews: cookie flags harden the token, but the server still trusts anyone who presents a valid ID. The only way to invalidate a stolen cookie before it expires is to change what the server accepts — which is the next chapter's problem, and the reason Session Start and Configuration alone is not a security story.

A stolen cookie is valid until something server-side says otherwise. With default settings that means forever — gc_maxlifetime refreshes on every request, so an attacker replaying the cookie keeps the session alive indefinitely. Real hardening gives sessions an end date the attacker cannot push back.

Idle timeout. Track the last activity inside the session and evict when the gap grows too large:

session_start();
$now = time();
if (isset($_SESSION['last_activity']) && $now - $_SESSION['last_activity'] > 1800) {
    // 30 minutes idle: behave like a logout
    $_SESSION = [];
    session_destroy();
    // ...redirect to login with a "timed out" message
}
$_SESSION['last_activity'] = $now;

Absolute timeout. The idle check alone cannot stop a busy attacker: any request resets last_activity. An absolute window needs the login moment frozen at authentication:

// at login
$_SESSION['auth_at'] = time();

// on every authenticated request
if (time() - $_SESSION['auth_at'] > 43200) { // 12 hours
    $_SESSION = [];
    session_destroy();
    // ...force re-authentication
}

The two checks answer different questions — "has this session gone quiet?" versus "has this session lived too long?" — and production systems run both. Align the cookie's own lifetime with the idle window so the browser stops replaying a dead ID: session_set_cookie_params(['lifetime' => 1800, ...]).

Revocation. Neither timeout helps the user who clicks "log out everywhere" after a theft. The durable pattern is a per-user version counter stored server-side:

// each request, after loading the user
if (($_SESSION['ver'] ?? null) !== $user->session_version) {
    session_destroy();          // stale session: every device logged out
}
// "log out all devices": UPDATE users SET session_version = session_version + 1

Because session data is server-side, you can also inspect and destroy records directly — list the sess_* files for a user's known IDs, or query the Redis/DB handler. That is the asymmetry to state in interviews: you cannot revoke a cookie, but you can revoke what the cookie points at.

Remember-me tokens. "Stay logged in for 30 days" cannot be a long-lived session cookie — that is a theft target with a month of shelf life. The standard design stores only a hash of a random token on the user record, puts user_id:token in the long-lived cookie, looks the record up on presentation, compares with hash_equals(), and rotates the token on every use so a captured cookie dies after one replay. Remember-me and sessions are different mechanisms with different lifetimes; conflating them is how 30-day cookies end up in production.

Login throttling does not belong in the session either. A session-scoped attempt counter resets whenever the attacker changes their session ID — which they control for free. Count failures server-side, per account and per IP, in a table or your framework's rate limiter; keep the session copy only for UX niceties like a remaining-attempts display.

Two fashionable add-ons deserve skepticism, and knowing the trade-off is the interview payoff. Binding sessions to a user-agent or IP breaks legitimate users the moment a mobile network rotates addresses, and it does not stop an attacker behind the same browser profile. Session fingerprinting heuristics raise the bar slightly and cost real false-positive rates. The core four — regenerate at login, HttpOnly+Secure+Lax, idle and absolute timeouts, server-side revocation — cover the actual attack surface; everything else is a supplement.