cross-site post form submissions are forbidden astro

cross-site post form submissions are forbidden astro

TL;DR

Astro rejects POST, PUT, and DELETE requests whose Origin header does not match your site, a CSRF defense built into its actions and API routes. The fix is usually on your side: make the form post to the same origin the page was served from (check scheme, www vs apex, and port). Only allow cross-origin posts deliberately, through a same-origin proxy or the checkOrigin escape hatch, never by accident.

cross-site post form submissions are forbidden astro

Use this when

• An Astro form or action POST returns 403 with this exact message
• The same form works on one domain but fails on another (www vs apex, staging vs prod)
• You embedded an Astro form or endpoint on a separate site or subdomain
• A deploy or proxy change suddenly broke previously working forms

Not for this skill when

• The error comes from Express, FastAPI, or another framework (different CORS setup)
• Django says "CSRF cookie not set" (different mechanism)
• The failure is on an OAuth or SSO redirect rather than a form POST

Steps

1. Reproduce and read the request headers. Open devtools, submit the form, and look at the failed request. Confirm the status is 403, the body is this exact message, and note the Origin header the browser sent. Expected: you can see the Origin value that Astro rejected, for example https://www.example.com posting to https://example.com.

2. Fix the self-inflicted origin mismatch. Compare the form's action URL against your site value in astro.config and the URL the page was actually served from. The usual culprits are http vs https, www vs apex, and a dev port. Make them agree so the POST is same-origin. Expected: the Origin header now matches the site origin and the form submits with 200 or 302.

3. If the cross-site POST is genuinely required, proxy it. Add a same-origin API route or action that forwards to the real destination server-side. The browser then talks only to your origin and Astro's check stays on. Expected: the form posts to your own origin (passes the check) and the server forwards the work.

4. As a last resort, scope the escape hatch. Astro's checkOrigin setting can be disabled, but that removes a CSRF layer for every route, so only do it if the endpoint has its own authentication and you have recorded why. Prefer disabling per-route over globally. Expected: the endpoint accepts the cross-origin POST, and you can point to the auth that replaced the origin check.

5. Verify with a hostile-origin test. Send a POST with a foreign Origin header and confirm it is still rejected everywhere you did not explicitly allow:

   curl -X POST https://example.com/api/contact -H "Origin: https://other.example" -d "name=test"

   Expected: 403 with the forbidden message for the foreign origin, success for your own.

Variant: Astro actions 403 on every form submit

Same error, but it fires even for same-site forms. That usually means a proxy or CDN is rewriting the Host header Astro sees, so check your forwarded-host configuration before touching the security setting.

Variant: checkOrigin in astro.config

Searchers looking for the setting itself want the tradeoff spelled out: it compares the Origin header against your site origin on state-changing requests. Keep it on unless you have a concrete cross-origin need and a replacement control.

Variant: works in dev, forbidden in production

Dev serves both page and endpoint from one origin, so the check never fires. Production splits them across domains or a CDN, and the mismatch appears. Align the origins or proxy, as in steps 2 and 3.

Variant: "Cross-site POST form submissions are forbidden" on API routes

Actions and API routes share the check. A mobile app or third-party webhook posting to your endpoint is not a browser form at all; give those callers a token-authenticated route instead of weakening the browser-facing check.

Why this happens

A cross-site POST is the textbook CSRF shape: some other page triggering a state-changing request with the victim's cookies attached. Astro compares the Origin header of incoming POST, PUT, and DELETE requests against the site's own origin and rejects mismatches before your code runs, so a malicious page cannot drive your actions.

Edge cases and pitfalls

• Browsers omit the Origin header on some same-origin GETs, but POSTs from forms carry it; a missing Origin on a POST is itself suspicious.
• Behind a reverse proxy, Astro may see the proxy's host instead of the public one. Forward the original host correctly or every form breaks.
• Disabling the check globally to fix one integration is the classic overcorrection. Scope it.
• Third-party scripts that hijack form submission can change the effective origin. Check what actually sent the request in devtools.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FPS2yqWt6X8GFj0fFIkCKw