Why GLPI session cookie security settings matter for your team
This section explains why the session cookie settings for a self-hosted GLPI instance deserve a deliberate review, and what should trigger that review. A GLPI instance holds asset records, tickets, user accounts and configuration, and the browser session is what keeps a signed-in administrator signed in. Anyone who obtains a valid session cookie can act as that user until the session ends, so the cookie's attributes and the transport it travels over are part of your access control, not a detail for the web server team to set once and forget.
GLPI relies on PHP sessions to track a signed-in user across requests. The settings that govern those sessions, including how the session cookie is marked for secure transport, whether scripts in the browser can read it, and how it behaves on cross-site requests, are set in PHP and in the web server that fronts GLPI. GLPI's own installation and security documentation is the reference to confirm the exact keys and recommended values for your GLPI version, and you should not rely on the defaults of your distribution or hosting image without checking them. Review these settings at a few points: a new deployment, any change to a reverse proxy or load balancer, an SSO rollout that adds redirects between your identity provider and GLPI, and any decision to expose GLPI to a wider network than its original users.
Ask your team to write down, before the change window, which PHP and web server files hold the session settings, who owns each one, and how the values will be verified after each upgrade or proxy change. Your platform team should also confirm which of your users reach GLPI through HTTPS only and whether any internal tool embeds GLPI pages in a frame, because the cookie choices that protect administrators can also stop those pages from working. The steps that follow in this page cover each setting and its trade-offs.
How GLPI sets and checks the session before enforcing cookie flags
PHP issues the session identifier, not GLPI's own login code, and it does so when the application starts a session after a successful sign-in. PHP sends that identifier to the browser in a Set-Cookie header, and the browser returns it on every later request. Whatever flags end up on that cookie are decided by PHP's session configuration (for example session.cookie_secure, session.cookie_httponly and session.cookie_samesite) and by any code that overrides it at runtime. Before you change those values, confirm in your own installation which session settings are in effect, for instance with a phpinfo() page on a test host, and which php.ini or pool file loads them. Also confirm that the GLPI release you run supports the setting you plan to use, since the documentation you have to work from is the installation documentation for your release line.
PHP only sees HTTPS if the request reaching PHP is HTTPS. When a load balancer, reverse proxy or ingress terminates TLS and forwards plain HTTP to the web server, PHP believes the connection is insecure. A secure cookie flag set on that basis can stop the browser from returning the session at all, and a redirect that checks the scheme can loop. The usual fix is to pass the original scheme through a forwarded header and configure the web server and PHP to trust that header only from your proxy addresses. Decide where TLS ends, write that decision down, and test sign-in from a browser through the full path, not only from inside the network.
The web server layout also matters. GLPI's installation documentation requires the document root to point to the public directory, not the installation root, with URL rewriting routing requests through index.php, on Apache, Nginx, lighttpd or IIS. If the root is wrong, configuration files and session-related code can be reachable over the web, which undermines any cookie setting. PHP support depends on the GLPI line: the README on the main branch lists PHP 8.3 or later, while the installation docs list PHP 8.2 or later for GLPI 11.0. Match the PHP version to the release you deploy, and plan a PHP upgrade alongside any GLPI version change.
Setting session cookie flags on a self-hosted GLPI instance
This sequence sets the PHP session cookie options that GLPI depends on, so the session cookie is sent only over HTTPS, is hidden from page scripts and carries a deliberate SameSite value. The team that runs the GLPI web tier performs it, and it ends with a browser-level check of the cookie attributes and a tested rollback path.
Back up config and keys first
Before any configuration change, back up the database, the application files and the config directory, including glpi.key and glpicrypt.key, as the GLPI update documentation lists. Store the copy outside the web root and record the GLPI and PHP versions in the change ticket. The step is done when the backup restores to a test host and the key files match the originals by checksum.
Confirm HTTPS termination and proxy headers
Identify where TLS ends: at a load balancer, a reverse proxy or the web server itself. If TLS ends in front of GLPI, confirm that the proxy forwards the original scheme and that the application sees HTTPS requests, because browsers will not store a Secure cookie received over plain HTTP. Ask the network team to confirm the forwarded protocol header and its value. The step is done when the public login address is served over HTTPS and the plain HTTP address redirects to it.
Confirm document root and rewrite rules
Check that the web server's document root points to GLPI's public directory and that URL rewriting routes requests through index.php, as the installation prerequisites describe for Apache, Nginx, lighttpd or IIS. Request a known file under the installation root from a browser and expect a refusal or a not-found response. The step is done when only the public directory is served and the login page loads through rewritten URLs.
Set session cookie options for the pool
Edit the PHP configuration that serves GLPI requests, such as the pool file for PHP-FPM or the module configuration for Apache. The command-line configuration used by bin/console is a separate file and should be checked on its own. Set the Secure, HttpOnly and SameSite session cookie options using the directive names in the PHP session documentation for your PHP version, and confirm each name before editing. The step is done when the file is saved and the configuration test reports no syntax errors.
Reload the PHP runtime and re-sign in
Reload PHP-FPM or restart the web server so new worker processes load the changed settings. Sessions issued before the change keep their old cookie attributes until the browser receives a new Set-Cookie response, so expect users to sign in again. Check the service log for worker errors during the first login after the reload. The step is done when a fresh sign-in returns a session cookie under the new settings.
Verify cookie attributes in developer tools
Sign in to GLPI over HTTPS in a clean browser profile, open the cookies view in the browser developer tools and select the session cookie for the GLPI host. Confirm that it shows Secure, HttpOnly and the SameSite value set in the previous step. Repeat the check in a second browser to rule out cached state. The step is done when the attributes match the change record. If an attribute is missing, the setting did not reach the pool that serves GLPI, and the configuration path needs review.
Test embedded views and sign-in flows
Load every page where GLPI appears inside another site's frame, such as a portal or dashboard, along with every single sign-on and callback flow. Cookies marked Secure with SameSite=None or Lax behave differently in cross-site frames, so embedded views may show a login prompt or empty content. Record each failure and decide whether to change the SameSite value or move the embed to a same-site hostname. The step is done when each embedded view has a pass or fail result and its owner has accepted it.
Roll back if checks fail
If sign-in, API calls or embedded views fail, restore the previous PHP configuration from the backup or version control, then reload the runtime as in the earlier step. Confirm that a test sign-in succeeds on the restored configuration. Keep the failed settings and the observed fault in the change record so the next attempt starts from evidence. The step is done when the restored file matches its pre-change checksum and a test sign-in succeeds.
What breaks when GLPI is embedded in iframes or used across sites
When a user opens GLPI in a top-level browser tab on the same site as the address they typed, the browser treats every request as first-party. Under the SameSite values most teams consider, the session cookie should be sent on top-level navigation and on same-site requests, so a normal sign-in should hold without special settings. This case is the baseline that the embedded and cross-site cases are measured against.
- Top-level navigation: Following links between GLPI pages from a bookmark or a typed URL should keep the session under Strict and Lax.
- Hostname consistency: Moving between the canonical GLPI hostname and an alternate or bare hostname creates a separate cookie scope, which users often report as a logout.
- Protocol changes: A session started over plain HTTP may not carry over cleanly once you force HTTPS, so test the redirect path from the old address.
- Clean profile test: Sign in from a fresh browser profile and confirm that navigation between several GLPI modules does not prompt a second login.
Confirm these results in your own environment before you test any embedded case, because a failure here points to hostname or redirect configuration rather than to SameSite.
When a page on your intranet embeds GLPI in a frame and both pages share the same registrable domain, the browser generally treats the frame as same-site. Results still depend on the SameSite value, the browser and how the request is initiated inside the frame. Confirm the behavior in each browser your users run before you assume the embedded page will work.
- Same site, different subdomain: Site is judged by scheme and registrable domain, so an intranet page on one subdomain embedding GLPI on another is usually same-site, while different registrable domains are not.
- Strict inside frames: Strict is the most restrictive value, so test whether the frame load, and any form submission started from inside it, still carries the session cookie.
- Lax inside frames: Lax covers top-level navigation, so subresource requests and some frame-initiated requests are where users are most likely to see blank content.
- Reported symptoms: A blank frame, the login page repeating inside the frame, or a session that ends when the parent page reloads all point to cookies that were withheld in the frame context.
For each embedding page, test with a logged-in session and a logged-out session, and record which requests lose the cookie in the browser developer tools.
When a third-party portal or a partner intranet on another registrable domain embeds GLPI, the browser classifies GLPI requests as cross-site. Under Strict and Lax, the session cookie is generally not sent in that context, so GLPI often sees an anonymous visitor. SameSite None with the Secure attribute is the value that allows the cookie to travel in a cross-site frame, and it requires GLPI to be served over HTTPS.
- Silent logouts: Each frame load can start unauthenticated, so users appear signed out when they move between pages of the embedded application.
- Login loops: GLPI sends the frame to the login page, the sign-in sets a cookie that the browser then withholds, and the cycle repeats.
- Browser and privacy restrictions: Some browsers and privacy settings block third-party cookies even when the attributes are correct, so one successful test does not confirm the setup for every user.
- Available options: Keep GLPI top-level by opening it in a new tab, serve it from a hostname on the portal's own domain, or accept SameSite None with Secure after a documented risk review.
Ask the portal owner which domain serves the frame, then test with the browsers and privacy settings your users actually use.
Single sign-on moves the browser through the identity provider's domain and back to GLPI. The return to GLPI is a cross-site navigation from the identity provider's perspective, so the SameSite value decides whether cookies that GLPI sets or expects during the flow are sent back. The session cookie written at the end of the callback must also be sent on the next request, which makes the redirect path a common source of login loops.
- Strict on return: A redirect from an identity provider domain can cause the browser to withhold cookies that GLPI needs when the callback arrives, so the sign-in restarts.
- Lax on callback: Lax generally allows cookies on top-level GET navigations, but callbacks that use POST need separate testing.
- Embedded sign-in: If the sign-in starts inside a frame, the identity provider may restrict framing or behave differently from a top-level login.
- Diagnosing the failure: Compare the callback response in the browser network log with the next request. A Set-Cookie header that does not appear in the next request points to a SameSite decision.
Test the full sign-in from a clean browser profile for each identity provider you connect, including the callback and the first authenticated page.
Security risks these settings reduce and the ones they do not
Cookie flags shrink a specific set of browser-side risks, but they sit beside identity, patching and transport controls rather than replacing them. The cards below separate what each setting reduces from what needs a different control, so you can plan the rest of your GLPI hardening alongside these settings.
Script access to the session cookie
The HttpOnly flag stops browser scripts from reading the session cookie. If a cross-site scripting flaw appears in GLPI or in a plugin, a script that runs in the page cannot copy the session identifier directly. Check the effective value after deployment by inspecting the Set-Cookie header on a login response, and confirm that your reverse proxy does not strip or rewrite it. HttpOnly does not stop the script from acting as the logged-in user while the page is open.
Cookie exposure over plain HTTP
The Secure flag tells the browser to send the session cookie only over HTTPS. Without it, a cookie set during a request made over plain HTTP can travel in clear text on the network. Confirm that HTTP requests to GLPI redirect to HTTPS before users reach the login page, and that the Secure attribute is present on every session cookie the application sets. The flag is only as useful as the HTTPS setup behind it.
Cross-site request and framing abuse
The SameSite attribute limits when the browser attaches the session cookie to requests started from other sites. It reduces the risk of cross-site request forgery and of a hostile page driving an authenticated GLPI session. Test your chosen value against every flow your users rely on, including single sign-on callbacks and links from email, because stricter values can drop the cookie on legitimate cross-site navigation. Pair it with the anti-framing headers your web server sends.
Session fixation and long-lived sessions
Session fixation happens when an attacker sets or learns a session identifier before a user logs in, then reuses it afterward. Cookie flags do not fix this. Check that GLPI issues a new session identifier at login and that idle and absolute lifetimes match your policy. Long-lived sessions widen the window in which a stolen identifier remains usable, so set the session timeout deliberately and document it for administrators.
Revoking sessions and step-up authentication
Revocation and step-up authentication are separate controls. GLPI 12.0.0 release notes list a view of active user sessions with the ability to revoke them, and the same release lists step-up authentication for certain administrative actions. Revocation ends a session you already know is risky. Step-up asks for fresh proof before a sensitive change. Neither is delivered by a cookie attribute, so plan both explicitly and test them with a named administrator group.
What cookie flags alone cannot cover
Cookie settings do not replace strong identity controls such as multi-factor authentication, patching GLPI and its plugins, or a correct TLS configuration with current protocols and certificates. A stolen password, an unpatched vulnerability or a weak cipher suite can expose a session regardless of its flags. Treat the cookie settings as one layer, and confirm the other three areas in your own environment before you call the application hardened.
Questions teams ask before changing GLPI session cookie settings
How much effort does changing GLPI session cookie settings take?
The change itself is a small set of PHP session settings, but the effort depends on how requests reach GLPI. The main drivers are the proxy layout (whether TLS terminates at a load balancer, a reverse proxy or the web server itself), how many sites or portals embed GLPI in frames, and whether SSO sits in front of it. Each of these changes which cookie attributes are safe and what must be tested. Ask any partner for a written scope that lists each access path, each embedding site and each SSO flow, since those lists set the work more than the settings do.
Can our internal team change GLPI session cookies without outside help?
Yes, if your team already runs the web server and PHP configuration for GLPI and can test changes outside production. The work is mostly configuration and verification, not code. Teams usually struggle with the parts they have not seen before: confirming which hostnames serve HTTPS, checking what the reverse proxy forwards, and verifying login behavior for each user path. If those skills are thin, an external implementation partner can plan and verify the change under a fixed written scope, while your team keeps ownership of the production systems.
What access and preparation do we need before changing session cookies?
Plan for four things before the change window opens:
- Administrative access to the web server, reverse proxy and PHP configuration files used by GLPI.
- A test environment that matches production in PHP version, web server layout and identity provider setup.
- A current backup of the database and the files, including the config directory with
glpi.keyandglpicrypt.key. - A named change window, a rollback plan and users told which sessions will end.
Confirm each item with your own platform owners, because the exact file locations depend on your installation method.
Do session cookie settings need retesting after a GLPI upgrade or plugin change?
Yes. Retest after any GLPI upgrade and after any plugin install, update or reactivation, because an upgrade can change how sessions are created and because plugins can send their own pages or embed content. GLPI's update procedure requires a backup, replacing the application files and running php bin/console db:update, and since GLPI 11.0 plugins are suspended when a new version is detected and must be reactivated after major updates. Include a cookie and login check in that test pass, along with any iframe-based pages.
What breaks for users when session cookies are hardened, and how should we tell them?
The most common breaks are logins that stop working on HTTP-only addresses, SSO redirects that fail behind a proxy, and GLPI pages embedded in another site inside an iframe, because stricter SameSite values can block the cookie in cross-site frames. Tell users which address to use, that they will need to sign in again, and which embedded pages may stop loading. Give them a named contact and a short window to report problems, and record what you changed so support staff can match reports to the change.
Do session cookie settings count as an audit control on their own?
No. Cookie settings are one technical safeguard that supports access and session controls, but they do not satisfy a control by themselves and they do not produce an audit result. An independent auditor or certification body decides whether your controls meet a framework. What you can provide is evidence: the configuration as implemented, the change record, the test results and the review of exceptions. Ask your assessor which evidence they expect before you make the change.
Should we hardening session cookies before or after SSO and HTTPS are in place?
Set HTTPS-only access first, because the Secure attribute only protects cookies that travel over TLS. Then decide SSO, since SSO redirects and identity provider sessions change which SameSite value works. Making cookie changes before the access path is settled usually means testing twice. Confirm your access path with the GLPI installation and web server guidance, then apply the cookie settings and test each sign-in method in turn.
Limits to confirm in your environment before you change cookies
Cookie flags only protect a session if they reach the browser intact. The PHP runtime, the reverse proxy, the GLPI release, the plugins and the client policies all sit between your setting and the browser, so each one needs a check before you change anything in production.
PHP version and ini handling
Confirm which PHP version runs GLPI and where its session settings come from. Packaged PHP, a Docker image and a hand-built stack often load different php.ini files, and some images set session options in their own entrypoint scripts. Use a phpinfo check or a small test page served by the same PHP-FPM pool to read the effective values, not the values in the file you edited. GLPI requires PHP 8.2 or later for GLPI 11.0 and PHP 8.3 or later on the main branch, so confirm the version against the release you run.
HTTPS state passed to PHP
A reverse proxy often terminates TLS, so PHP sees plain HTTP and a secure cookie flag can stop the browser from returning the session. Check that the proxy sends the scheme and forwarded headers that GLPI and PHP read, and that the public URL in GLPI matches the HTTPS address users type. Test a login from a clean browser profile after each change, because a session that is set but never returned looks like a repeated login prompt.
GLPI version and session behavior
Session handling differs between GLPI 10, 11 and 12, and the GLPI 12 release adds a view of active user sessions with the ability to revoke them, plus step-up authentication for certain administrative actions. Confirm in the release notes for your exact version whether any session feature overlaps with your cookie settings. Do not assume a behavior from one major release applies to another, and record the version you tested against.
Cross-site redirects in plugins and SSO
A SameSite=Strict cookie is not sent on requests that arrive from another site, including the redirect back from an external identity provider. Check every SSO flow, OAuth2 callback and plugin that redirects users into GLPI or opens GLPI inside another page. Ask your identity provider team which login method they use and test it end to end. Plugins that embed GLPI pages in iframes need separate review, since the browser may block the cookie in that context.
Browsers and client policies
Browsers handle cookie attributes differently, and enterprise policies can block third-party cookies, force specific cookie behavior or limit which sites run in embedded frames. List the browsers and versions your staff use, including any managed builds, and test each one with an administrator account and a standard user account. Record the results so the change has evidence behind it.
Image or distribution session defaults
Some Docker images, distribution packages and control panels set session options by default, and a later rebuild or package update can change them. Compare the effective cookie settings before and after each image or package update, and keep your own configuration under version control so a rebuild does not silently remove your change. Ask your platform team who owns that file and how updates are reviewed.
How DeployOpen works on this
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For GLPI session cookie settings, we start from your current cookie, HTTPS and embedding requirements, then change and verify them in your environment.
How we scope
- We review your GLPI version, web server layout and how users reach the instance, including any iframe embedding.
- We list which cookie attributes, HTTPS redirects and session settings change, and which integrations they could affect.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any change is made.
How we build
- We apply the agreed PHP session and web server settings in a staging copy of your GLPI instance first.
- We test login, SSO callbacks, API clients and any embedded views against the new cookie attributes.
- We record each change so it can be reverted during a maintenance window if a dependency breaks.
How we hand over
- You receive the configuration files, a before and after test record, and a runbook for the cookie and HTTPS settings.
- We document known breakages, such as cross-site iframe behavior, with the workarounds you approved.
- Your administrators walk through the verification steps so they can repeat them after future GLPI upgrades.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover rechecking session settings when you move to a new GLPI release, such as the GLPI 11 or 12 path.
- Ask any provider to confirm which PHP and web server settings they will verify against your GLPI version.
