La valeur 0 a une signification importante. Elle informe les navigateurs de ne pas stocker le cookie dans un espace de stockage permanent. Aussi, lorsque le navigateur se ferme, le cookie d'identification de session est supprimé immédiatement. Si les développeurs définissent une valeur différente de 0, cela permet aux autres utilisateurs d'utiliser l'identifiant de session. La plupart des applications devraient utiliser "0" comme valeur.

Si une fonctionnalité d'auto-identification est désirée, les développeurs doivent implémenter leur propre système d'auto-identification sécurisé. Ne pas utiliser d'identifiants de session à longue durée pour cela. Pour plus d'informations, se rapporter à la bonne section de cette documentation.

session.use_only_cookies=On

Bien que les cookies HTTP souffrent de soucis techniques, ils restent la façon préférée de gérer les identifiants de sessions. N'utiliser que les cookies pour la gestion des identifiants de sessions lorsque cela est possible. La plupart des applications doivent utiliser un cookie pour l'identifiant de session.

Si session.use_only_cookies=Off, le module de session utilisera les valeurs de l'identifiant de sessions définies par les variables GET ou POST fournies, et le cookie de l'identifiant de session ne sera pas initialisé.

session.use_strict_mode=On

Bien que l'activation de session.use_strict_mode soit obligatoire pour la sécurité des sessions, cette directive est désactivée par défaut.

Ce mode évite que le module de session utilise un identifiant de session non initialisé. Dit différemment, le module de session ne va accepter que les identifiants de sessions valides générés par le module de session. Il va rejeter tous les identifiants de session fournis par les utilisateurs.

En raison de la spécification des cookies, les attaquants sont capables de placer des cookies contenant les identifiants de sessions en configurant localement une base de données de cookie ou par injections Javascript. session.use_strict_mode peut éviter qu'un attaquant n'initialise un identifiant de session.

Note:
Les attaquants peuvent initialiser un identifiant de session avec leur propre périphérique, et peuvent définir l'identifiant de session de leur victime. Ils doivent alors conserver l'identifiant de session actif pour pouvoir en abuser. Les attaquants doivent passer par bien d'autres étapes pour réussir leur attaque dans ce scénario. Aussi, l'utilisation de la directive session.use_strict_mode permet de limiter les risques.

session.cookie_httponly=On

Permet de refuser l'accès à un cookie de session depuis javascript. Cette configuration évite qu'un cookie ne soit corrompu par une injection Javascript.

Il est possible d'utiliser un identifiant de session comme jeton CSRF, mais ce n'est pas recommandé. Par exemple, des sources HTML peuvent être sauvegardées et envoyées à d'autres utilisateurs. Les développeurs ne doivent pas écrire les identifiants de session dans les pages web pour des raisons de sécurité. Toutes les applications web doivent utiliser l'attribut httponly pour le cookie contenant l'identifiant de session.

Note:
Le jeton CSRF doit être renouvelé périodiquement, tout comme l'identifiant de session.

session.cookie_secure=On

Permet d'accéder au cookie d'identifiant de session uniquement lorsque le protocole est HTTPS. Si un site web n'est accessible que par HTTPS, cette directive doit être activée.

HSTS doit être utilisé pour les sites web accessibles que par HTTPS.

session.cookie_samesite="Lax" ou session.cookie_samesite="Strict"

À partir de PHP 7.3, l'attribut "SameSite" peut être défini pour le cookie d'identifiant de session. Cet attribut est une façon de mitiger les attaques CSRF (Cross Site Request Forgery).

La différence entre Lax et Strict est l'accessibilité du cookie dans les requêtes originaires d'autres domaines employant la méthode HTTP GET. Les cookies utilisant Lax seront accessibles via une requête GET originaire d'un autre domaine, alors que les cookies utilisant Strict ne le seront pas.

session.gc_maxlifetime=[choisissez le plus petit possible]

session.gc_maxlifetime est une configuration pour supprimer l'identifiant de session obsolète. Le fait de se reposer entièrement sur cette configuration n'est pas recommandé. Les développeurs doivent gérer la durée de vie des sessions avec un timestamp par eux-mêmes.

Le GC des sessions (garbage collection) est mieux réalisé en utilisant la fonction session_gc(). La fonction session_gc() doit être exécutée par un gestionnaire de tâches ; c.-à-d. un cron sur les systèmes Unix.

GC est exécuté par probabilité, par défaut. Cette configuration ne garantit pas que les anciennes sessions soient supprimées. Bien que les développeurs ne doivent pas s'appuyer sur ce paramètre, il est recommandé tout de même de le définir à une valeur la plus petite possible. Il convient d'ajuster les directives session.gc_probability et session.gc_divisor de sorte à ce que les sessions obsolètes soient supprimées à fréquence appropriée. Si la fonctionnalité d'auto-identification est nécessaire, les développeurs doivent implémenter leur propre fonctionnalité d'auto-identification sécurisée ; voir ci-dessous pour plus d'informations. N'utiliser jamais l'identifiant de session de longue durée pour réaliser ce genre de fonctionnalité.

Note:
Quelques modules de gestion de sauvegarde des sessions n'utilisent pas cette fonctionnalité basée sur l'expiration et sur la probabilité ; c.-à-d. memcached, memcache. Se référer à la documentation de ces gestionnaires de sauvegarde des sessions pour plus de détails.

session.use_trans_sid=Off

La désactivation de la gestion transparente des identifiants de session permet de sécuriser un peu plus les identifiants de session en éliminant la possibilité d'une injection d'identifiant de session ou de fuite de cet identifiant.

Avertissement

Activer session.use_trans_sid est obsolète à partir de PHP 8.4.0.

Note:
L'identifiant de session peut fuiter depuis des URLs sauvegardées, des URLs dans des emails, d'une source HTML sauvegardée, etc.

session.trans_sid_tags="a=href,area=href,frame=src,form="

Les balises HTML non nécessaires ne devraient pas être réécrites. La valeur par défaut est suffisante pour la plupart des utilisations. Pour les versions de PHP plus anciennes, utiliser plutôt url_rewriter.tags.

Avertissement

Modifier session.trans_sid_tags par rapport à sa valeur par défaut est obsolète à partir de PHP 8.4.0.

session.trans_sid_hosts=""

Ce paramètre liste les hôtes pour lesquels l'identifiant de session peut être ajouté aux URL. Il ne faut jamais y ajouter d'hôte qui n'est pas de confiance. Lorsqu'il est vide, le module de session autorise uniquement $_SERVER['HTTP_HOST'].

Avertissement

Définir session.trans_sid_hosts à une valeur non vide est obsolète à partir de PHP 8.4.0.

session.referer_check=""

Lorsque le paramètre session.use_trans_sid est actif, une valeur non vide réduit les risques d'injection d'identifiant de session : l'identifiant de session envoyé par le client est ignoré à moins que l'en-tête Referer ne contienne cette valeur. Il est à noter qu'en HTTPS les navigateurs n'envoient pas l'en-tête Referer, et que les navigateurs peuvent l'omettre de par leur propre configuration. Aussi, ce paramètre ne peut pas être considéré comme une mesure fiable de sécurité.

Avertissement

Définir session.referer_check à une valeur non vide est obsolète à partir de PHP 8.4.0.

session.cache_limiter=nocache

S'assure que le contenu HTTP n'est pas mis en cache pour les sessions authentifiées. Permet la mise en cache que pour les contenus qui ne sont pas privés. Sinon, le contenu sera exposé. La valeur "private" doit être employée si le contenu HTTP n'inclut pas des données sensibles d'un point de vue sécurité. Il est à noter que "private" peut transmettre des données privées mises en cache pour les clients partagés. "public" doit être uniquement utilisé lorsque le contenu HTML ne contient aucune donnée privée.

session.save_path=[dossier non lisible par tout le monde]

Si ce paramètre est défini à un dossier accessible en lecture par tout le monde, comme /tmp (par défaut), les autres utilisateurs du serveur seront capables de récupérer les sessions en listant les fichiers présents dans ce répertoire.

Sécurisation des configurations INI de session