Skip to main content

HTTP 417 error in the Umbraco CMS backoffice

Why Umbraco backoffice requests return HTTP 417 (Expectation Failed), how a third-party cookie-consent script blocks Umbraco's antiforgery cookies, and how to check which cookies are actually reaching the server.

Written by Joana Knobbe

Type: Troubleshooting
Category: Umbraco CMS > Backoffice & Errors
Tags: 417, Expectation Failed, backoffice not loading, GetSections, antiforgery, XSRF, UMB-XSRF-TOKEN, UMB-XSRF-V, cookie consent, third-party cookies, CookieScriptConsent, cookies used by Umbraco

Product: Umbraco CMS
Version: All versions


Summary

If the Umbraco backoffice fails to load sections or content nodes and the browser's network tab shows requests returning HTTP 417 (Expectation Failed), the usual cause is that Umbraco's antiforgery cookies are not reaching the server. A third-party cookie-consent or cookie-control script is the most common reason.

Symptoms

  • Backoffice sections, trees, or node details do not load.

  • Requests to /umbraco/backoffice/... endpoints (for example /umbraco/backoffice/UmbracoApi/Section/GetSections) return 417.

  • The problem appears on a hosted environment but not locally, or appeared after a cookie-consent tool was added to the site.

Cause

Umbraco protects backoffice requests with an antiforgery token that is validated against a pair of cookies. If those cookies are missing, duplicated, or rewritten by the time the request reaches the server, validation fails and the request is rejected with a 417.

Cookie-consent and cookie-control scripts are a frequent cause: they may block, defer, or rewrite cookies they do not recognise as necessary. CookieScriptConsent is one reported example, but any consent tool that manages cookies site-wide can produce the same result.

Solution

Step 1 — Confirm the failing request is a 417

Open the browser developer tools, go to the Network tab, and reload the backoffice. Find a failing /umbraco/backoffice/... request and confirm the status is 417.

Step 2 — Check which cookies are actually being sent

On that same request, inspect the Cookies tab (or Request Headers → Cookie). Look for Umbraco's antiforgery cookies:

  • UMB-XSRF-TOKEN

  • UMB-XSRF-V

Compare what you see against the full list of cookies Umbraco sets — see Cookies in Umbraco.

Three findings point to the consent tool:

  • One or both antiforgery cookies are missing from the request.

  • A consent cookie (for example CookieScriptConsent) is present, and the Umbraco cookies are not.

  • Duplicate or conflicting XSRF cookies appear on the same request (for example both XSRF-TOKEN and UMB-XSRF-TOKEN, or the same cookie name twice with different values).

Step 3 — Allowlist Umbraco's necessary cookies

In your cookie-consent tool's configuration, classify Umbraco's cookies as strictly necessary so they are never blocked, deferred, or rewritten. Use the documented cookie list above as your reference.

Step 4 — Verify

Clear the site's cookies for the affected domain, reload the backoffice, and confirm the request now returns 200 and the antiforgery cookies are present.

If the problem persists

If the antiforgery cookies are being sent correctly and requests still return 417, the cause may lie elsewhere in the request pipeline — a proxy, CDN, or WAF between the browser and the site can also strip headers or cookies. Background on this error signature is in Umbraco-CMS issue #4138. Contact Umbraco Support with the failing request's headers and cookie list if you cannot identify the cause.

Prevention

When adding or reconfiguring a cookie-consent tool on a site with an Umbraco backoffice, add Umbraco's necessary cookies to the strictly-necessary category before going live.

Recommended documentation


AI-generated. Last updated on August 26, 2026

Did this answer your question?