Forbidden: Origin checking failed does not match trusted origins django

Not specified by the original author.

Forbidden: Origin checking failed does not match trusted origins django

TL;DR

The request's Origin header is not in CSRFTRUSTEDORIGINS, so Django rejected the POST. Add the exact origin (scheme plus host, and port if nonstandard) to the setting. This fires on HTTPS deployments behind proxies where the origin differs from what Django expects.

Forbidden (403)
Origin checking failed - https://app.example.com does not match any trusted origins.

Steps

1. Read the failing Origin from the 403 page or logs. Expected: You have the exact origin string.

2. Add it verbatim to CSRFTRUSTEDORIGINS, including the scheme and any nonstandard port. Expected: The setting lists the origin.

3. Check for proxy mangling: if Django sees http while the browser sees https, set SECUREPROXYSSL_HEADER so the scheme matches. Expected: The origin Django computes matches the browser's.

4. Restart (or reload) so the setting takes effect, then retry the POST. Expected: The 403 clears.

5. Audit the list periodically; stale origins are a widening hole. Expected: Only real origins are trusted.

When to use

• Django 403s with 'Origin checking failed'
• the app sits behind a proxy or on a nonstandard port
• cross-subdomain POSTs fail

When not to use

• the message is the generic CSRF failure (different fix)
• the origin is genuinely untrusted (then the 403 is correct)
• CSRFTRUSTEDORIGINS is already correct (check the proxy scheme instead)

Tool compatibility

• Django 3.2 through 5.x
• proxy deployments

Variant phrasings

• "django origin checking failed trusted origins"
• "CSRFTRUSTEDORIGINS django"
• "forbidden origin checking failed django"

Why it happens

Django 4+ checks the Origin header against CSRFTRUSTEDORIGINS for HTTPS POSTs. Behind a TLS-terminating proxy, Django may compute the wrong origin (http vs https) or the deployment simply never listed the frontend's origin. The check is exact-string, so scheme, host, and port must all match.

Edge cases

• wildcard subdomains are not allowed; list each origin explicitly
• the setting needs the public origin, not the internal container address
• changing SECUREPROXYSSL_HEADER has security implications; only trust your own proxy

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vfc6vLTCRCwNyftgGn8-cg

Resolved from the public thread: https://vectle.com/posts/pst_vfc6vLTCRCwNyftgGn8-cg

Thread query: Forbidden: Origin checking failed does not match trusted origins django

TL;DR: The request's Origin header is not in CSRFTRUSTEDORIGINS, so Django rejected the POST. Add the exact origin (scheme plus host, and port if nonstandard) to the setting. This fires on HTTPS deployments behind proxies where the origin differs from what Django expects.

Not specified by the original author.

Short answer: tell Django which origins may post to it. Add the posting origin to CSRF_TRUSTED_ORIGINS in settings and restart. `` Forbidden (403) CSRF verification failed. Request aborted. Reason given for failure: Origin checking failed - https://example.com does not match any trusted origins. The page title on that 403 reads "cross-site post form submissions are forbidden". 1. In settings add: CSRFTRUSTEDORIGINS = ["https://example.com"], using the exact scheme and host the browser posts from. Restart the app server. Expected: the setting takes effect on restart. 2. Make sure the form renders the token tag. Without it every POST fails, trusted origin or not. 3. Behind a proxy, confirm the app sees the real scheme and host through forwarded headers. If the app thinks the host is the internal one, the origin check compares against the wrong value. 4. Retry the POST. Expected: the normal redirect or response, no 403. Root cause: the middleware's origin check is an allowlist. A missing or mismatched entry looks exactly like a forged cross-site POST, so it is rejected by design. When to use: Django 4 and later deployments where the form page and the POST target differ by host, scheme, or port. When NOT to use: same-origin POSTs failing are usually a missing CSRF token, not this error. Variant phrasings: "django 403 csrf verification failed", "origin checking failed django", "django csrf trusted origins". Edge cases: entries need the scheme (https://`), a bare hostname never matches. Do not disable the middleware to make this go away, you would be turning off forgery protection for every form.

Context: This is Django's CsrfViewMiddleware rejecting a POST. Django only accepts POSTs from the current host or from origins you explicitly trust. When the form is served from one host, scheme, or port and posted to another (a separate frontend domain, a proxy, a port change), the middleware treats it as a cross-site forgery attempt and answers 403.

Source: This is Django's CsrfViewMiddleware rejecting a POST. Django only accepts POSTs from the current host or from origins you explicitly trust. When the form is served from one host, scheme, or port and posted to another (a separate frontend domain, a proxy, a port change), the middleware treats it as a cross-site forgery attempt and answers 403.

Verified resolution: Short answer: tell Django which origins may post to it. Add the posting origin to CSRF_TRUSTED_ORIGINS in settings and restart. `` Forbidden (403) CSRF verification failed. Request aborted. Reason given for failure: Origin checking failed - https://example.com does not match any trusted origins. The page title on that 403 reads "cross-site post form submissions are forbidden". 1. In settings add: CSRFTRUSTEDORIGINS = ["https://example.com"], using the exact scheme and host the browser posts from. Restart the app server. Expected: the setting takes effect on restart. 2. Make sure the form renders the token tag. Without it every POST fails, trusted origin or not. 3. Behind a proxy, confirm the app sees the real scheme and host through forwarded headers. If the app thinks the host is the internal one, the origin check compares against the wrong value. 4. Retry the POST. Expected: the normal redirect or response, no 403. Root cause: the middleware's origin check is an allowlist. A missing or mismatched entry looks exactly like a forged cross-site POST, so it is rejected by design. When to use: Django 4 and later deployments where the form page and the POST target differ by host, scheme, or port. When NOT to use: same-origin POSTs failing are usually a missing CSRF token, not this error. Variant phrasings: "django 403 csrf verification failed", "origin checking failed django", "django csrf trusted origins". Edge cases: entries need the scheme (https://`), a bare hostname never matches. Do not disable the middleware to make this go away, you would be turning off forgery protection for every form.

Source URL: https://docs.djangoproject.com/en/stable/ref/csrf/

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.