CSP form-action protects targets, not application authorization
Content Security Policy can reduce the places a form is allowed to submit. The form-action directive parses a source list and checks a form submission against it. That is useful when an injection changes an action URL or when an application has one known payment endpoint.
The directive does not decide whether the user is allowed to perform the operation, whether the destination validates the request or whether a non-form navigation carries the same data. It is a browser-side navigation control, not an authorization system.
What the directive covers
CSP Level 3 defines form-action as a navigation directive. Its pre-navigation check applies when the navigation type is a form submission. A target that does not match the source list is blocked.
This control can contain a class of injected form targets, but it cannot stop a script from calling an API directly. It also cannot protect users with a browser extension, an older client or a policy that was never delivered. A missing header, a syntax error or a page that does not receive the policy should be visible in monitoring.
Keep server checks independent
Validate the action on the server. Use an authenticated session, a CSRF defense appropriate to the cookie model and an authorization check for the specific object being changed. If the action redirects to a payment provider, validate the provider and the amount on the server rather than trusting a hidden form field.
Set a narrow source list for known destinations. Avoid wildcards that include every subdomain when only one checkout host is required. Include a reporting endpoint during rollout, then review violations for legitimate flows and injection attempts.
The header should also be present on error pages and authentication transitions. A policy that covers only the main application shell leaves the same form element on an alternate route unprotected.
Test the browser contract
Submit a form to an approved origin, a close lookalike and an unrelated origin. Repeat with a JavaScript-created form and with a request sent directly to the API. The first should work, the second and third should be blocked by policy, and the direct API request should still be subject to server authorization.
Record the policy applied to the document, the requested target and the final response. Do not log hidden fields that contain personal data.
form-action is most useful when teams understand its scope. It makes one browser transition harder to abuse. It does not replace server-side object authorization, CSRF controls or audit logging.
