# form-action (/fr/docs/web-security/policies/content-security-policy/directives/form-action) La directive `form-action` contrôle vers quelles URL un [`
`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/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 : ```http Content-Security-Policy: form-action 'self' ``` ## Chaîne de repli [#chaîne-de-repli] `form-action` n'a pas de repli. [`default-src`](/fr/docs/web-security/policies/content-security-policy/directives/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 [#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). | Valeur | Statut | Description | | -------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `'none'` | ✅ Bon | Bloque toutes les soumissions de formulaire, y compris les envois same-origin. | | `'self'` | ✅ Bon | N'autorise les soumissions que vers l'origine du document. | | Source d'hôte ou de schéma | ✅ Bon | Autorise les soumissions vers une [source d'hôte](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source) ou [source de schéma](/fr/docs/web-security/policies/content-security-policy/values/csp-scheme-source) correspondante, par exemple un hôte de paiement dédié. | 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 [#exemples] Autoriser un formulaire de paiement qui poste vers un hôte de paiement dédié : ```http Content-Security-Policy: form-action 'self' https://pay.example.com ``` Bloquer toutes les soumissions sur une page qui ne devrait jamais poster de formulaire : ```http Content-Security-Policy: form-action 'none' ``` Dans une politique plus complète, elle accompagne les autres contrôles de navigation : ```http Content-Security-Policy: default-src 'self'; base-uri 'none'; form-action 'self'; frame-ancestors 'none' ``` ## Notes de sécurité [#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 `` 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 [#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](https://github.com/w3c/webappsec-csp/issues/8) 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`](/fr/docs/web-security/policies/content-security-policy/directives/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](/tools/csp-evaluator) pour faire remonter un `form-action` manquant ou trop large. ## Recommandation [#recommandation] ```http 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](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html). 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 [#reporting] Quand la directive bloque une soumission, le navigateur émet un [report `csp-violation`](/fr/docs/web-security/reporting-api/reports/csp-violation) nommant `form-action` comme directive effective. Configurez la livraison avec la [directive `report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) et le [header `Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints). ## Prise en charge par les navigateurs [#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](#contournements-et-risques-connus). ## FAQ [#faq] ### Que fait form-action ? [#que-fait-form-action-] `form-action` contrôle vers quelles URL un `` 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 ? [#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 [#voir-aussi] * [default-src](/fr/docs/web-security/policies/content-security-policy/directives/default-src) * [base-uri](/fr/docs/web-security/policies/content-security-policy/directives/base-uri) * [frame-ancestors](/fr/docs/web-security/policies/content-security-policy/directives/frame-ancestors) * [connect-src](/fr/docs/web-security/policies/content-security-policy/directives/connect-src) * [navigate-to](/fr/docs/web-security/policies/content-security-policy/directives/navigate-to), la directive retirée qui aurait couvert la navigation par lien et par script * [Valeurs mot-clé CSP](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) ## Sources [#sources] * [MDN, CSP form-action](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/form-action) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/) * [OWASP, Content Security Policy cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) * [W3C webappsec-csp issue 8, form-action and redirects](https://github.com/w3c/webappsec-csp/issues/8)