Forbidden (CSRF cookie not set.)

Not specified by the original author.

Forbidden (CSRF cookie not set.)

TL;DR

Django's CSRF defense needs two matching pieces: the csrftoken cookie and the token submitted with the POST. This error means the cookie never arrived with the request, so Django rejected it before comparing anything. The usual causes are JavaScript fetch calls that do not send credentials, the cookie being blocked or dropped (Secure on plain HTTP, SameSite rules), or a view that never set the cookie. Find which one, fix it, and the 403 goes away.

Forbidden (CSRF cookie not set.)

Use this when

• Django forms or AJAX POSTs return 403 with this exact message
• A React, Vue, or mobile frontend talks to a Django backend
• It broke after changing cookie settings or moving to HTTPS
• The same POST works from a Django-rendered template but not from JavaScript

Not for this skill when

• The error says the CSRF token is missing or incorrect (the cookie arrived but the token did not match; different fix)
• The browser blocks the request for CORS reasons (fix CORS first)
• The user is not logged in at all (that is a session problem, not CSRF)

Steps

1. Check whether the browser holds the cookie at all. In devtools, look under Application or Storage, then Cookies, for the csrftoken cookie on your Django domain. Also check the page response for a Set-Cookie header. Expected: you know whether the cookie was never set, or was set but not sent with the POST.

2. If JavaScript makes the request, send credentials. fetch and XHR omit cookies by default. For same-origin requests use credentials: 'same-origin'; for cross-site requests use credentials: 'include' (which also requires the server's CORS setup to allow credentials):

   fetch("https://example.com/api/submit", {
     method: "POST",
     credentials: "include",
     headers: {
       "Content-Type": "application/json",
       "X-CSRFToken": "[the csrf token value]"
     },
     body: JSON.stringify({ name: "test" })
   });

   Get the token value from the csrftoken cookie or from the page's CSRF markup. Expected: the POST carries the cookie, and the 403 becomes a 200 or a normal application response.

3. Make sure the view sets the cookie in the first place. Django sets the CSRF cookie when a view uses CSRF-protected rendering. API views that only return JSON may never set it; decorate those views with ensurecsrfcookie or have the frontend hit a view that does before posting. Expected: the initial page or bootstrap response includes Set-Cookie for csrftoken.

4. Check the cookie flags that silently drop it. CSRFCOOKIESECURE on a plain-HTTP dev server means the browser never stores it. SameSite=None without Secure gets rejected. A CSRFCOOKIEDOMAIN that does not match the serving host drops it too. Align the settings with how you actually serve the site. Expected: the cookie persists in the browser and is sent with subsequent POSTs.

Variant: "CSRF token missing or incorrect."

The sibling error: the cookie arrived but the submitted token was absent or wrong. That means the frontend is not reading the cookie value into the X-CSRFToken header or form field. Different symptom, different fix, same defense.

Variant: cross-site frontend and backend

The frontend on one origin and Django on another needs credentials: 'include', CORS allow-credentials on Django, the frontend origin in CSRFTRUSTEDORIGINS when using HTTPS, and SameSite=None with Secure on the cookie. Miss any one and the cookie never arrives.

Variant: works in the Django template, fails in the SPA

The template gets the cookie set by the rendering view and the token embedded in the form. The SPA gets neither automatically. Bootstrap the SPA from a view that sets the cookie, and read the token from the cookie in JavaScript.

Variant: CSRFCOOKIESECURE in local development

Serving Django over plain HTTP locally while Secure is on means the cookie is never stored, and every POST 403s. Turn Secure off for local HTTP dev, keep it on everywhere else.

Why this happens

Django uses the double-submit pattern: a random token lives in a cookie and must also be submitted with the POST (as a form field or header). An attacker's site cannot read your cookie, so it cannot produce the matching submission. When the cookie itself is missing, Django cannot even run the comparison and rejects the request outright.

Edge cases and pitfalls

• Third-party cookie blocking in browsers can drop the csrftoken cookie in cross-site setups even when everything is configured right. Test in the browsers your users actually use.
• Rotating the CSRF secret invalidates outstanding tokens. Coordinate rotation with frontend deploys.
• Caching a page that embeds the CSRF token serves stale tokens to everyone. Mark token-bearing responses uncacheable or fetch the token via a dedicated endpoint.
• Do not "fix" this with csrf_exempt on the view unless that endpoint has its own authentication and you have thought about why the CSRF layer existed there.

Provenance

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

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

Thread query: Forbidden (CSRF cookie not set.)

TL;DR: Django's CSRF defense needs two matching pieces: the csrftoken cookie and the token submitted with the POST. This error means the cookie never arrived with the request, so Django rejected it before comparing anything. The usual causes are JavaScript fetch calls that do not send credentials, the cookie being blocked or dropped (Secure on plain HTTP, SameSite rules), or a view that never set the cookie. Find which one, fix it, and the 403 goes away.