By securing session related INI settings, you can improve session security.
Some of important INI settings do not have recommended settings. You
are responsible to hardening session settings.
0 have special meaning. It tells browsers not to store cookie to
permanent storage. Therefore, when browser is terminated, session
ID cookie is deleted immediately. If developer set other than 0, it may
allow other users to use the session ID. Most applications should
use "0" for this.
If auto login feature is required, implement your own secure auto login
feature. Do not use long life session ID for it.
Although HTTP cookie has some problems, cookie is preferred way to
manage session ID. Use only cookies for session ID management when
it is possible. Most applications should use cookie for session
session module will use session ID values set by GET/POST/URL when
session ID cookie is not initialized already.
Although, enabling session.use_strict_mode is
mandatory. It is not enabled by default.
This prevents session module to use uninitialized session ID. In
other word, session module only accepts valid session ID generated
by session module. It rejects session ID supplied by
Because of cookie spec, attackers are able to set undeletable session ID
session.use_strict_mode can prevent attacker
initialized session ID being used.
Attackers may initialize session ID by their device and may set the
session ID to victim. They must keep the session ID active to abuse.
Attackers require additional steps to perform attack with this attack
scenario. Therefore, session.use_strict_mode works
as the mitigation.
It is possible to use session ID as CSRF protection key, but this is not
recommended. For example, HTML source may be saved and sent to
other users. Developer should not write session ID in web pages for
better security. Almost all applications must use httponly attribute for
session ID cookie.
CSRF protection token should be renewed periodically just like
Allows access to session ID cookie only when protocol is HTTPS. If
your web site is HTTPS only web site, you must enable this
HSTS should be considered for HTTPS only web site.
session.gc_maxlifetime=[choose smallest possible]
is setting for deleting obsolete session ID. Reliance on this setting
is NOT recommend. You should manage session life time by time-stamp
Session GC(garbage collection) is better to be performed by session_gc().
session_gc() function is better to be executed by task
managers. e.g. cron on UNIX like systems.
GC is performed by probability by default. This setting does not
guarantee old session deletion. Although developer cannot rely
on this setting, setting this to smallest possible value is
recommended. Adjust session.gc_probability
and session.gc_divisor so
that obsolete sessions are deleted by appropriate frequency. If
auto login feature is required, implement your own secure auto
login feature. Never use long life session ID for it.
Some session save handler modules do not use this setting for
probability based expiration . e.g. memcached, memcache.
Refer to session save handler documentation for details.
Use of transparent session ID management is not prohibited. You
may use it when it is needed. However, disabling transparent
session ID management would improve general session ID security by
removing possibility of session ID injection and session ID leak.
Session ID may leak from bookmarked URL, e-mailed URL, saved HTML
(PHP 7.1.0 >=) You should not rewrite unneeded HTML tags. Default
would be good enough for most usage. Older PHP uses
url_rewriter.tags for this.
(PHP 7.1.0 >=) This INI defines whitelist hosts that allows trans sid
rewrite. Never add untrusted host. Session module allow only $_SERVER['HTTP_HOST']
when this setting is empty.
session.referer_check=[your originating URL]
It reduces risk of session ID injection. If your site is
http://example.com/, set http://example.com/ to it. Note that when
HTTPS is used the browser will not send the referrer header. Browsers may
not send the referrer header by configuration. Use of this
setting is recommended Therefore, this setting
is not reliable security measure.
Make sure HTTP contents are not cached for authenticated
session. Allow caching only when contents are not private.
Otherwise, contents may be exposed. "private" may be used
if HTTP content does not include security sensitive data. Note
that "private" may leave private data cached by shared
clients. "public" may be used only when HTTP content does not
contain any private data at all.
(PHP 7.1.0 >=) Longer session ID results in stronger session
ID. Developer should consider session ID length 32 chars or more. At
least 26 chars is required when
(PHP 7.1.0 >=) The more bits in a session ID char, session module
generates stronger session ID for the same session ID length.
(PHP 7.1.0 <) Stronger hash function will generates stronger session
ID. Although hash collision is unlikely even with MD5 hash, developers
should use SHA-2 or stronger hash functions for the task. Developers may
use stronger hashes like sha384 and sha512. Make sure you feed long
enough entropy for
the hash function used.