SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Can someone explain to me exactly when and why I need to call SPUtility.ValidateFormDigest?

Contrary to the spec, which says you need to call it before elevating privileges, I've had the following work:

  1. Elevate permissions
  2. Call SPUtility.ValidateFormDigest()
  3. Create sub web
  4. Add user to group on web

Then I had the the following fail (complaining that the form digest is invalid)

  1. Elevate permissions
  2. Read elevated web''s Url property
  3. Call SPUtility.ValidateFormDigest()
  4. Create sub web
  5. Add user to group on web

but only at the point where I try to add the user to the group, not the point where I create the sub web!

I'd expect, if I've somehow invalidated the digest by reading a property from a web (honestly, SharePoint?), that either the explicit validate call would fail or the first change I try to make would fail, not the second. It leads me to believe that, if someone was genuinely attacking my site, they might be able to create subwebs even if they can't add people to groups.

I can fix the issue by moving the Validate call to before reading the Url property - again, contrary to the spec.

share|improve this question
Both examples are executed on a POST request right? I can only assume that for some reason you are already starting with AllowUnsafeUpdate == true so you first test pass. Then in the second example reading the web url prop somehow calls a SPWeb.Invalidate, so the prop is reset. This is only a wild guess though. – SPArchaeologist Mar 19 '13 at 9:34
I'm not setting AllowUnsafe anywhere in my code, and IIRC it's not something that's persisted past the lifetime of the SPWeb instance, so I don't think that can be it. both examples are executed identically, on a POST. – Rawling Mar 19 '13 at 9:46
Maybe this post will help you why… – Remko Nov 17 '13 at 19:04

If all you are doing is updating content in SharePoint, then it is better to impersonate the system account instead of elevating privilege.

Also, even though your first scenario happens to work, you should validate the token before creating the new SPSite context.

share|improve this answer
I am elevating to an account, but it's not the system account. (I edited my question down to make it more succinct, apparently I edited that bit out...) I am now validating before opening the site, I just wish what's gonig on was a bit more transparent :( – Rawling Mar 20 '13 at 8:07

you need to use

Web.AllowUnsafeUpdates to true .

instead of messing with the digest.

from my experience

Also there might be a difference if your code running inside a webpart , page or an event handler.

give it a shot.

don't forget to revert to back to false when done

Best of luck.

share|improve this answer
AllowUnsafeUpdates is orthogonal to elevation - it allows you to make changes on a GET instead of a POST, which is not what I'm trying to do. – Rawling Aug 19 '13 at 7:58
Web.AllowUnsafeUpdates = true is something you'd need to do in rare cases only if you are 100% that it is necessary. – Milen Nov 6 '13 at 9:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.