L'application accepte la requête parce que des identifiants comme les cookies l'accompagnent automatiquement, sans confirmer suffisamment que l'utilisateur voulait l'action. L'impact est limité par les privilèges de l'utilisateur et l'opération vulnérable.
Les défenses doivent distinguer les actions intentionnelles au sein de la même application des requêtes initiées ou influencées ailleurs. Une protection fournie par le framework est préférable lorsque son périmètre et sa configuration sont compris, et les actions sensibles peuvent aussi exiger une réauthentification ou une confirmation explicite.
Points clés
Intégrité des requêtesUtiliser des jetons anti-CSRF imprévisibles liés à la session de l'utilisateur et les valider côté serveur sur les requêtes qui changent l'état, ou utiliser un autre motif pris en charge par le framework aux propriétés équivalentes.
Signaux du navigateurConfigurer les cookies SameSite de manière appropriée et valider Origin, Fetch Metadata ou les en-têtes personnalisés attendus lorsque c'est adapté ; les traiter comme des signaux en couches avec une compatibilité et un comportement de proxy documentés.
Conception des fluxNe pas permettre à des méthodes de requête nominalement en lecture seule de changer l'état, exiger l'autorisation courante pour chaque action, limiter privilèges et durée de session, et ajouter des contrôles renforcés pour les opérations à forte conséquence.
Limite importanteLes cookies SameSite ou la présence d'un jeton seuls ne garantissent pas la protection. Les jetons peuvent fuiter, être prévisibles ou mal liés, et le cross-site scripting (XSS) au sein de l'application fiable peut vaincre de nombreuses défenses CSRF.