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.

  • 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.
    – SPArcheon
    Mar 19, 2013 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, 2013 at 9:46
  • Maybe this post will help you why hristopavlov.wordpress.com/2008/05/21/…
    – Remko
    Nov 17, 2013 at 19:04

2 Answers 2


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.

  • 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, 2013 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.

  • 1
    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, 2013 at 7:58
  • 1
    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, 2013 at 9:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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