The SPWeb.AllowUnsafeUpdates property recently came up in my project this week. I got the following exception:
System.Exception: Microsoft.SharePoint.SPException: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again. —> System.Runtime.InteropServices.COMException (0×8102006D): The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.
One of my team members told me to just set AllowUnsafeUpdates to true. I did and the exception went away. A quick google search shows dozens of blog posts and forum answers that the solution to the above exception is to set AllowUnsafeUpdates to true. After meeting a deadline I decided to go back and look at this property because it seems like a property that you would not want to set to true. The idea behind AllowUnsafeUpdates is to protect you from cross-site scripting attacks. All SharePoint does is check to see if HttpContext.Current is not null, and if it's not (this is in the context of a web request) it checks to see if the current web request is an HTTP GET (you clicked on a link) vs an HTTP post (you clicked on a button), and if it's not an HTTP POST (e.g., not a postback) it then checks the value of AllowUnsafeUpdates (which is false by default), if it is false then the security exception mentioned above is throw. I should mention I am leaving out a few steps to simplify the explanation. For more details of how the property is implemented see the MSDN documentation.
There are two reasons you get the above exception and may be tempted to set AllowUnsafeUpdates to true to avoid it. The first is if you are trying to perform an update of a web or list when the page loads instead of during a postback. For example creating a delete.aspx page and passing the list item ID in as a query string parameter then performing the delete on that item. This will throw a security exception by default. But MSFT gave you the option to override this exception by setting AllowUnsafeUpdates to true. Do not do this. There is a reason you are getting an exception here. You are opening a risk that anyone can call that page and pass in any id in the querystring and delete a list item. Plus your search crawler or an outside search engine might accidentally hit that page and delete the list item. But for me I was not doing this. I had a button click event that was calling my SharePoint update code. The reason I was getting the exception was because we did not have the forms digest security control in the master page. This control validates the Web application when it attempts to access the Windows SharePoint Services APIs. So adding the following control to our master page removed 95% of our need for setting AllowUnsafeUpdates to true:
<!-- Form Digest Security Control -->
<asp:ContentPlaceHolder id="PlaceHolderFormDigest" runat="server">
<SharePoint:FormDigest runat=server/>
</asp:ContentPlaceHolder>
The majority of the time you should have AllowUnsafeUpdates set to false. But there are always exceptions to the rule. The first that comes to mind is feature receivers. I haven't dug into this too much but it seems you have to set AllowUnsafeUpdates to true. If anyone can confirm or deny this please post in the comments. The other situation that comes to mind is one-off updates. For example, creating a console app that updates a particular column in a list is not a big enough security risk to worry about.
Some Additional References:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.allowunsafeupdates.aspx
http://hristopavlov.wordpress.com/2008/05/16/what-you-need-to-know-about-allowunsafeupdates/
http://hristopavlov.wordpress.com/2008/05/21/what-you-need-to-know-about-allowunsafeupdates-part-2/