PHPAML

Documentation · Chapitre 08

Prouver qu’une action
vient du vrai formulaire.

Une attaque CSRF pousse un navigateur déjà connecté à envoyer une action à l’insu de son utilisateur.

Nous sécurisons reading-list par couches, sans prétendre qu’une seule option suffit.

L’analogie du ticket assorti

À l’ouverture du formulaire, le serveur donne un ticket secret à la session. Au retour, le formulaire doit présenter exactement le même ticket. Un autre site peut provoquer une requête, mais ne connaît pas ce jeton.

Ajoutez le champ à chaque formulaire d’écriture

phpaml — zsh
<form method="post" action="/books">
    <?= $view->csrfField() ?>
    <!-- champs -->
    <button type="submit">Enregistrer</button>
</form>

Le middleware accepte _token dans le formulaire ou X-CSRF-Token dans l’en-tête. Sans correspondance sûre via hash_equals(), il retourne 419 et renouvelle l’en-tête du jeton.

Quelles requêtes sont contrôlées ?

GET / HEAD / OPTIONSlecture : pas de contrôle CSRF
POST / PUT / PATCH / DELETEmodification : jeton requis
Authorization: Bearer …authentification par jeton, pas par cookie
Préfixes API configurésexclus du middleware Web
CSRF ne remplace pas l’autorisation

Un jeton valide prouve l’origine du formulaire, pas le droit de supprimer un livre. Vérifiez aussi l’identité et les permissions.