Cookie Login Is More Than Just Checking HTTPS: How to Secure Sessions in PHP and WordPress

HTTPS is important, but it is not the only guardian of user accounts. After someone logs in, the website typically stores an identifier in the browser in the form of a session cookie. This cookie allows users to avoid entering their password on every page.

The problem is that anyone who obtains a valid session cookie can be considered that user. Therefore, session security needs to be treated like home key security: it’s not just about how the key is sent, but also how the key is created, stored, changed, and revoked.

What is a session cookie?

A session cookie is a small piece of data sent from the server to the browser after a user opens or logs into an application. Its content usually does not include a password, but rather a random ID that refers to session data on the server.

For example, the server can store information that ID abc123 belongs to a specific user. The browser then sends this ID in the next request. If this ID is leaked, an attacker does not need to know the password to attempt to take over the session.

That’s why session IDs should not be included in URLs, stored carelessly on pages, or printed in application logs. URLs can enter browser history, analytics, server logs, and even the referer header.

Three cookie attributes that must be checked

Secure: only over HTTPS

The Secure attribute ensures that the browser only sends cookies over HTTPS connections. This reduces the risk of session IDs being visible when users are on an untrusted network.

However, Secure is not a substitute for HTTPS. Websites must still enforce the entire site to use HTTPS and should not mix secure pages with resources still sent over HTTP.

HttpOnly: do not allow JavaScript to read cookies

HttpOnly prevents cookies from being read through JavaScript APIs like document.cookie. This helps limit cookie theft when XSS or Cross-Site Scripting occurs, which is when malicious code successfully enters and runs on a website page.

This attribute does not make XSS harmless. Malicious scripts can still send requests on behalf of the user from the active browser. Therefore, XSS prevention and CSRF protection are still necessary.

SameSite: limit cross-site sending

SameSite controls whether cookies can be sent when requests come from other sites. For many websites, Lax is a practical choice. Strict provides stricter limitations but can disrupt certain login flows or navigation.

Do not rely solely on SameSite for CSRF protection. For critical actions like changing email, password, or deleting data, always use CSRF tokens and server-side validation.

Regenerate session after login

One common mistake is using the same session ID before and after login. This pattern opens the door to session fixation: an attacker tries to make the victim use a specific session ID, then hopes that ID remains active after the victim successfully logs in.

The solution is simple: change the session ID when there is a change in access rights, especially after login. In PHP, the basic pattern can look like this:

<?php
session_start();

if ($login_successful) {
    session_regenerate_id(true);
    $_SESSION['user_id'] = $user_id;
    $_SESSION['login_at'] = time();
}
?>

Regeneration should also be considered after password changes, account recovery, or privilege escalation. Do not rely solely on IP address or user-agent to bind sessions; both can change and are not always strong indicators of identity.

Example session configuration in PHP

Cookie configuration must be set before session_start(). In modern PHP, the settings can be written as follows:

<?php
session_set_cookie_params([
    'lifetime' => 0,
    'path' => '/',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax'
]);

session_start();
?>

lifetime is set to zero to make the cookie a session cookie that typically expires when the browser is closed. For applications that require a “remember me” feature, use a limited duration, separate tokens, and a token revocation mechanism. Do not create permanent login sessions without a clear reason.

If the website is behind a reverse proxy or CDN, ensure the application can recognize that the original request is using HTTPS. Incorrect configuration can cause cookies not to have the Secure attribute or make HTTPS redirects work inconsistently.

What about WordPress?

WordPress handles authentication through several cookies and internal tokens. Website administrators should not replace the login mechanism with custom code without understanding the flow of cookies, nonces, and user capability validation.

Practical steps include ensuring the WordPress Address and Site Address use HTTPS, updating the core and plugins, removing unused plugins, and not installing code that disables built-in security checks. For custom login features, use the WordPress API and server-side validation, not just hiding buttons on the page.

The “remember me” feature also needs to be understood. Persistent cookies are convenient, but they extend the time when accounts can be accessed from lost or borrowed devices. For administrator accounts, consider shorter login durations and additional authentication.

Logout is not just redirecting to the login page

Proper logout must invalidate the session on the server, delete the associated cookies, and ensure old tokens cannot be reused. Redirecting users to the login page without revoking the session is not true logout.

For applications that store sensitive data, use headers like Cache-Control: no-store on certain responses to prevent private pages from being cached in the browser or intermediaries. After logout, users should also not be able to return to view account pages just by pressing the Back button and loading an old cached copy.

What you can do now

1. Check login cookies through the browser's Developer Tools. Ensure there are Secure, HttpOnly, and SameSite.
2. Ensure session IDs do not appear in URLs, HTML, error messages, or logs that are too accessible to many people.
3. Regenerate sessions after login and changes in access rights.
4. Limit session duration, especially for admin panels.
5. Ensure logout invalidates the session on the server, not just removes the cookie display.
6. Retest the login flow after enabling HTTPS, CDN, reverse proxy, or security plugins.

Session security is not a one-time feature that is installed once. It is a series of small complementary decisions: encrypted transport, cookies with the right attributes, IDs that change when status changes, reasonable timeouts, and logout that truly revokes access.

Sources & further reading

• OWASP Session Management Cheat Sheet
• PHP Manual: session_set_cookie_params
• PHP Manual: Securing Session INI Settings
• WordPress Developer Resources: wp_set_auth_cookie()

– Rio Yotto @rioyotto