HTTP, formulaires, sessions et uploads

Comprendre le mécanisme

HTTP transporte des requêtes indépendantes ; une session ajoute un état serveur associé à un identifiant. Un cookie reçu reste une donnée du client, même si son nom semble interne. Secure limite l’envoi du cookie à HTTPS et HttpOnly son accès direct par JavaScript ; aucun de ces attributs ne décide des autorisations métier. Après une authentification ou une élévation de privilèges, prévoyez une rotation de l’identifiant avec gestion des requêtes concurrentes.

Raisonner et vérifier

Les superglobales contiennent des entrées non fiables. Validez taille, forme et droits avant toute opération. Pour un upload, contrôlez l’erreur de transfert, la taille réelle, le type détecté et le contenu attendu ; générez un nom serveur et empêchez l’exécution dans le répertoire de stockage. Réduisez la durée du verrou de session en fermant la session dès que les modifications utiles sont enregistrées.

Une session est un état accepté par le serveur

Le cookie de session transporte souvent une référence opaque, pas une preuve autonome de tous les droits. Le serveur résout cette référence et applique ses règles de validité, d’expiration et d’activation du compte. Définissez les limites de durée et ce qui arrive après une désactivation. Une date côté navigateur ne suffit pas : un détenteur d’une ancienne copie peut encore présenter la même référence à un autre client.

Changer de contexte d’identité

Le passage d’une session anonyme à une session authentifiée change les capacités associées à son identifiant. Une politique de rotation doit empêcher qu’un identifiant choisi ou conservé par un tiers devienne une capacité privilégiée. Vérifiez l’ancien et le nouvel identifiant après la transition. Le succès du formulaire de connexion ne prouve pas, à lui seul, que l’ancienne référence a perdu tous les usages interdits.

Une lecture ne doit pas demander une annulation

GET sert à demander une représentation selon une sémantique sûre. Les navigateurs, outils de préchargement et robots peuvent effectuer cette lecture sans clic volontaire d’annulation. Placez les mutations derrière une méthode et un contrat adaptés, puis vérifiez identité, permission et état métier. Changer seulement le texte d’un lien ne corrige pas une route GET dont le serveur continue à supprimer une ressource.

La défense CSRF précède l’effet

Un navigateur peut envoyer automatiquement son cookie lors d’un parcours déclenché ailleurs. Le serveur doit donc distinguer une demande conforme à son contexte de formulaire d’une demande forgée. Vérifiez le jeton CSRF et les autres contrôles requis avant l’écriture. Les tests doivent fournir valeur correcte, valeur absente et valeur incorrecte, puis vérifier le statut et l’absence de mutation dans les deux derniers cas.

Portée précise de HttpOnly

HttpOnly limite la lecture directe du cookie par les API JavaScript habituelles. Cette propriété réduit une voie de vol, mais ne neutralise pas toutes les conséquences d’un script hostile exécuté dans l’origine. Le script peut encore demander des actions au serveur. Conservez donc prévention XSS, contrôles d’autorisation et politique de session ; ne traduisez pas un attribut de cookie en garantie générale de sécurité du navigateur.

Transport sécurisé et capacité sensible

Secure demande un envoi du cookie dans les conditions de transport sécurisé prévues par le navigateur. Le contenu opaque reste une capacité sensible s’il peut être rejoué. L’attribut ne dit rien sur le propriétaire d’une réservation ni sur la validité actuelle du compte. Vérifiez la réponse réellement déployée et le contexte proxy : une mauvaise perception du schéma peut influencer les cookies et URL générés.

Construire la réponse et servir les fichiers

Les en-têtes appartiennent au message HTTP et doivent être construits avant l’émission incompatible du corps selon le contexte PHP. Utilisez les API du framework pour statuts, cookies et téléchargements. Pour un upload destiné au public, choisissez un nom généré côté serveur et un espace sans exécution de code. Le nom fourni par le client ne doit pas devenir librement un chemin de stockage ou une règle de présentation.

Statuts et chemins d’erreur

Un statut donne une information protocolaire utile aux clients et à la supervision. Ne transformez pas toute panne en réponse 200. Définissez un schéma d’erreur public et une corrélation privée sans exposer les détails internes. Un refus de droit, une entrée invalide et une dépendance indisponible n’impliquent pas toujours la même reprise. Testez le corps autant que le statut, notamment sur les erreurs qui contournent le chemin nominal.

Session, concurrence et cache

Une session peut introduire une contention si son mécanisme de stockage conserve un verrou pendant un traitement long. Une fois la lecture et les écritures de session utiles terminées, fermer tôt la session peut réduire l’attente des requêtes parallèles ; vérifiez le contrat du handler utilisé. Séparez cette question de celle du cache : une réponse personnalisée ne doit pas être distribuée à un autre compte par une clé trop générale.

Le logout n’est pas une suppression universelle

Effacer un cookie sur un navigateur retire cette copie locale. Cela ne prouve pas le retrait des autres copies ni de tous les états de validation. Définissez ce que le logout doit invalider côté serveur et mesurez sa propagation si plusieurs instances participent. Un test avec deux clients permet de vérifier la distinction : fermer le premier ne suffit pas à démontrer que le second ne peut plus utiliser l’ancienne capacité.

Atelier guidé : lire, expliquer et vérifier le code

<?php
declare(strict_types=1);
$expected = 'lab-A';
$provided = 'lab-B';
$writes = 0;
if (hash_equals($expected, $provided)) { ++$writes; }
echo $writes;

Le petit programme de validation CSRF compare deux chaînes distinctes. La branche contenant l’incrément n’est pas exécutée et writes reste égal à zéro. Le point important est l’ordre : aucune écriture ne précède la comparaison. Remplacer la réponse finale par un statut de refus après un incrément ne donnerait pas la même propriété, même si le navigateur affichait une erreur.

Déplacez volontairement l’effet avant la garde dans une copie de laboratoire et écrivez un test qui observe le compteur. Ce test doit échouer sur la version incorrecte. Ajoutez ensuite un contrôle d’autorisation indépendant : un token valide ne doit pas permettre à un acteur d’annuler une réservation d’un autre compte. Vous aurez alors deux preuves séparées pour deux frontières différentes.