PHP sessions allow a website to remember user data between page requests, such as login status or a shopping cart. However, default settings aren’t always secure enough for production environments. In this article you’ll learn how sessions work, which php.ini settings matter, and which concrete measures protect sessions against hijacking and fixation.
How PHP sessions work
When a visitor accesses a website that uses sessions, PHP creates a unique session ID. This ID is usually stored in a cookie (PHPSESSID) on the visitor’s device and used to retrieve the associated data on the server, for example in a file or database. With each subsequent request, the browser sends this cookie along, so the server knows which session data belongs to which visitor.
The problem arises when this session ID is intercepted or guessed. An attacker who obtains the ID can impersonate the logged-in user without needing a password. Proper session configuration is therefore just as important as a strong password policy.
Important php.ini settings
The following settings in php.ini (or in a .user.ini file on shared hosting) determine how securely sessions work:
session.cookie_httponly = 1– prevents JavaScript from accessing the session cookie, making cross-site scripting (XSS) less dangerous.session.cookie_secure = 1– ensures the cookie is only sent over HTTPS, never unencrypted.session.cookie_samesite = StrictorLax– limits the cookie being sent with requests from other sites, reducing CSRF risks.session.use_strict_mode = 1– prevents PHP from accepting a session ID made up by an attacker.session.gc_maxlifetime– determines how long an inactive session remains valid before being cleaned up.session.name– change the default name PHPSESSID to something unique, making it harder for automated scanning tools to recognise which technology you use.
Securing sessions against hijacking and fixation
In addition to php.ini settings, there are measures you can implement in your own application code:
Regenerate the session ID after login
Call session_regenerate_id(true) immediately after a successful login. This prevents session fixation, where an attacker gets a visitor to use a predetermined session ID in advance.
Check the IP address and user agent
Store the IP address and user agent when starting a session and compare them with each request. If an unexpected change occurs, you can expire the session.
Set a reasonable timeout
Let sessions expire automatically after a period of inactivity, both via session.gc_maxlifetime and a custom timestamp check in your code.
Destroy sessions properly on logout
Use session_unset(), session_destroy() and explicitly remove the cookie, so no residual data remains.
Always enforce HTTPS
Without a valid SSL certificate, a session cookie can be intercepted on unsecured connections. Make sure your site is only accessible via HTTPS.
Configuring sessions in Plesk
With Plesk hosting, you can apply custom PHP settings per domain via the subscription’s PHP settings, or via your own php.ini in the hosting settings. This allows you to set different values for cookie_secure, cookie_samesite or gc_maxlifetime per website without changing the server-wide configuration. On NVMe storage with LiteSpeed, these settings are processed instantly, without noticeable delay for visitors.
Not sure whether your current hosting environment supports good PHP security? Check out the options for web hosting with fixed prices and free SSL, or read how switching to Tandata works if your session security isn’t properly arranged right now.
Frequently Asked Questions
Why don’t my sessions work after enabling cookie_secure?
If your site still runs over HTTP instead of HTTPS, the cookie won’t be sent once cookie_secure is enabled. Check whether your SSL certificate is active and valid.
Is using sessions more secure than JWT tokens?
Both have advantages and disadvantages. Sessions are easier to revoke server-side, while JWT tokens are stateless. For most regular websites, properly configured sessions are secure enough.
How long should I set session.gc_maxlifetime?
This depends on your application. For a webshop or informational site, a shorter lifespan is often sufficient, while a dashboard where users stay logged in for a long time can use a longer value.
Can I also store session files in a database?
Yes, with a custom session handler you can store session data in, for example, MySQL instead of files. This is useful for load balancing across multiple servers.
Where can I find more information about server settings?
The knowledge base contains more articles about PHP configuration, SSL and server management.
Conclusion
Properly configured PHP sessions protect user data against hijacking and fixation. Make sure you have the right php.ini settings, regenerate session IDs after login, enforce HTTPS, and destroy sessions correctly on logout. With the right hosting environment, you can apply these settings easily without compromising on speed.