astro form actions 403

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Astro's CSRF middleware (checkOrigin, on by default since Astro 4.9) returns a 403 with this exact message when it rejects a form POST. Most of the time the submission is legitimate and only looks cross-site because the app runs behind a reverse proxy: declare your production domain in security.allowedDomains in astro.config so Astro trusts the proxy's forwarded headers, rebuild, and the forms go through.

Cross-site POST form submissions are forbidden

Use this when

• Every form POST 403s in production with this exact message while the same forms work in local dev
• The app sits behind Cloudflare, Cloud Run, Caddy, or any TLS-terminating proxy
• Login, sign-out, or contact forms fail but JSON posts work (the check only applies to form content types)

Not for this skill when

• JSON or API posts fail (checkOrigin only inspects form-encoded POST, PATCH, PUT, DELETE)
• The site uses static output (checkOrigin only runs for SSR/on-demand pages)
• You want the quick fix of disabling checkOrigin (dont; see below)

Steps

1. Confirm the pattern: 403 on form POSTs in production, fine in local dev. That means Astro is rejecting a legitimate same-origin POST, not an actual attack. Behind a proxy, Astro ignores X-Forwarded-Host and X-Forwarded-Proto unless your domain is allowlisted, so the Origin header no longer matches the URL Astro reconstructs.
2. In astro.config, add your real production hostname (requires Astro 5.14.2 or later):

security: {
  allowedDomains: [{ hostname: 'YOUR_SITE_HOST', protocol: 'https' }]
}

Match the hostname and protocol the browser actually uses. Serving several subdomains? List each one explicitly, or use a wildcard pattern like **.YOUR_SITE_HOST.

3. Rebuild and redeploy, then resubmit the form. Expected: the POST returns 200 or 302 instead of 403.
4. On Astro below 5.14.2, allowedDomains does not exist: upgrade instead of hunting for another config knob.

Do not disable checkOrigin

Setting checkOrigin to false globally clears the error by removing CSRF protection from every form in the app. It hides the misconfiguration instead of fixing it.

Variant phrasings

403 Cross-site POST form submissions are forbidden

The exact message; same fix as above.

Every form POST fails in production with a CSRF 403

Same root cause: the proxy hides the real origin from Astro's middleware.

Sign-out or login form blocked behind a proxy

The most common shape of this error: auth forms POST in production and 403 while everything else looks fine.

Why it happens

Astro's checkOrigin middleware compares the browser's Origin header against the URL Astro reconstructs for the request. Behind a proxy, the reconstruction uses the internal scheme and host, the Origin no longer matches, and every form-encoded write is rejected as cross-site. JSON posts are unaffected because the check only applies to form content types.

Edge cases

• The allowlist entry [{}] trusts any forwarded host, which reopens host-header injection: reserve it for trusted dev setups.
• Only on-demand rendered (SSR) pages run the check; static output never triggers this error.

Related skills

• cross-site post form submissions are forbidden astro (alternate coverage): https://vectle.com/skills/skl_c8OUWMxAb88csiXGJb0PjA

Provenance

Verified against the official docs: https://docs.astro.build/en/reference/configuration-reference/

Astro returns a 403 with this exact message when its CSRF middleware rejects a form POST. Most of the time the submission is legitimate and only looks cross-site because the app runs behind a reverse proxy: the fix is to declare your production domain in security.allowedDomains in astro.config so Astro trusts the proxy's forwarded headers. Verified resolution: 1. Confirm the pattern first: the 403 hits form POSTs in production (behind Cloudflare, Cloud Run, Caddy, or any TLS-terminating proxy) while the same forms work in local dev. 2. In astro.config, add your real production hostname (requires Astro 5.14.2 or later). Match the hostname and protocol the browser actually uses. 3. Rebuild and redeploy, then resubmit the form. Expected: the POST returns 200 or 302 instead of 403. Root cause: Astro's checkOrigin middleware compares the browser's Origin header against the URL Astro reconstructs for the request. Source: https://docs.astro.build/en/reference/configuration-reference/

Not specified by the original author.

TL;DR

The maintainer verified this on a production test site with Astro 7.3.3 and @astrojs/node 11.1.6, and the browser form submission succeeded.

Steps

1. The maintainer verified this on a production test site with Astro 7.3.3 and @astrojs/node 11.1.6, and the browser form submission succeeded.

When to use

You are seeing this: The maintainer verified this on a production test site with Astro 7.3.3 and @astrojs/node 11.1.6, and the browser form submission succeeded. Use this skill when you run into "Astro SSR: cross-site POST fails checkOrigin when served through Appwrite custom domain".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: Astro 7.3.3, astrojsnode 11.1.6. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Skill distilled from thread https://vectle.com/threads/thr_AG6VwAdesw9Fbn1yybgPWw