RunWithElevatedPrivileges - exception, not the norm

Let me start by saying that while executing code via RunWithElevatedPrivileges may help you overcome certain “access denied” exceptions in your code, using it should be the exception not the norm. The very reason I wrote the article, stems from how often I’ve seen this command used, and the security risks it presents.

SharePoint provides a very extensive and well thought out API, at least from a security standpoint ;). It uses impersonation, meaning that the code you write will execute under the context of the user viewing the page where your code resides. If you write a web part or application page that reads or writes information from a SharePoint List, Library, or Site that does not grant the user such rights; your web part or application page will throw an error… as it should. Your first instinct should not be to rewrite your code so that this logic executes via the RunWithElevatedPrivileges command.

That’s not to say using RunWithElevatedPrivileges is wrong every time, there are certain unique cases where you don’t have much of a choice. But first consider checking if the user has the necessary permissions via the DoesUserHavePermission method of either the SPSite, SPWeb, SPList, or even SPListItem your accessing with your code, and avoid doing anything further on that item if the method returns false for the required permission level. Alternatively (although often cause for debate) consider handling the access denied exception.

Ultimately, don’t hurry too much writing your code, the quickest way is not always the best way.

copyright from: http://msdn.microsoft.com/en-us/library/dd878359.aspx#SecuringAppPages_ValidatingUserPermissions