Microsoft introduced SharePoint in 2001. Originally designed as an intranet for team collaboration and content management, SharePoint has evolved with every new version and enterprises have found additional innovative ways to customize it and manage their line of business applications, to some SharePoint is considered a Web Application.
Today we can find several solutions for help desk, wiki sites, blogging, proposal management, resource and project management, emergency response application, to name just a few, which are all based on SharePoint.
The popularity and functionality of Microsoft’s SharePoint continues to increase. In 2009, it generated $1.3 billion in revenues from an installed base of 100+ million users and it has been growing at a rate of 20,000 SharePoint users per day, every day for the last five years and that’s over 7 million new SharePoint users every year. 
SharePoint is built primarily on Visual C#, Visual Basic, Microsoft .NET Framework, ASP.NET, HTML/CSS, Document Object Model, Silverlight, it interfaces with Microsoft Active Directory, but it can be configured with LDAP, and is designed for use with Microsoft SQL Server and Internet Explorer. Consequently is not without its share of security vulnerabilities.
One defense mechanism that Microsoft has integrated in SharePoint to protect users against cross-site scripting attacks is the inclusion a form digest for each ASPX web page requested.
The form digest is a security validation specific to a user, site, and time period. It is generated for each HTTP Request and placed on the ASPX page before serving it; it will then get validated on the server side when the user submits the form.
Form Digest embedded in the HTML Form
This mechanism is a feature available to developers who create new Web Pages with just a simple point and click.
Developers have also the option to create their own custom web pages but careful consideration needs to be taken care of to avoid security validation errors, which result in Exceptions errors being thrown out.
Security Validation Exception Error
The way to correct this is by including the appropriate controls in the ASPX page , which will instruct the server to create, include, and manage the form digest
ASPX FormDigest Tag
An SPWeb.ValidateFormDigest or SPUtility.ValidateFormDigest  method can then be invoked to explicitly check the security validation used in the ASPX page, and works on a second page on which the first ASPX page posts or on the first one, if there is no second page involved.
This mechanism help developers build their own HTTP POST requests to submit and update SharePoint data, but how can we submit data to the server using HTTP GET requests?
The solution is not without some level of risk. The object model provides developers with a method to instruct the server to bypass the form digest validation by setting the AllowUnsafeUpdates  property of the SPSite object to true.
However, setting this property to true opens security risks, potentially introducing cross-site scripting vulnerabilities as noted in the remarks for the class reference, so it must be reset programmatically as soon as the update has taken place.
· SPRoleDefinitionCollection.BreakInheritance ()
· BreakRoleInheritance ()
· ResetRoleInheritance ()
· An Exception being thrown out
The cross-site scripting protection just described may result in errors if you are writing server-side code not necessarily designed to respond to a POST Request.
If your web pages are designed to respond to a GET Request  or if you are creating your own SPSite or SPweb objects using the SharePoint object model and you are required to update the database you must then use the AllowUnsafeUpdate property prior to executing the update.
There are also instances in which you may not be updating the database but instead calling functions, which in turn perform a database update. One such case is the call to EnsureUser () which looks for the specified user login in the Site Users collection and if the login is not found then SharePoint looks to see if it is a valid user in the Active Directory, if it is it then adds the login to the Site Users collection resulting in an update to the database.
In case like this you must also make use of the AllowUnsafeUpdates function and set it to true, but remember to always set it back to false --or at least to its previous state-- after the operation is complete, so that other code in your program will not run in unsafe mode.
Many examples I have found on posts on the web, reset it right after line of code executing the database update and sometimes fail to consider exception errors, therefore is always a good idea to reset its value in the finally block of a try and catch. 
Use of finally block to ensure reset to unsafe updates
SharePoint Internals – Hristo Pavlov’s Blog. What You Need To Know About AllowUnsafeUpdates (Part 1)
 SharePoint Internals – Hristo Pavlov’s Blog. What You Need To Know About AllowUnsafeUpdates (Part 2)
SharePoint or Project Server
related articles please visit my website at: