Using Elevated Privileges and AllowSafeUpdates Method - Potential Security Risks

Although not recommended, there may be times when you need your code to perform certain functions that the current user does not have the necessary permissions to perform. I have such situation in one of our project, suppose that you wanted to provide add, edit or delete capability to all users who use your application, regardless of their permissions on the list. So how this would be achieved?

By using the SPSecurity class, it provides a method RunWithElevatedPrivileges that allows you to run a subset of code in the context of an account with higher privileges than the current user. You need to wrap the RunWithElevatedPrivileges method around your code, as shown below: 

    protected void btnAddListItem_Click(object sender, EventArgs e)
    {
        using (SPSite oSite = SPContext.Current.Site)
        {
            // Run with an account with higher privileges than the current user
            SPSecurity.RunWithElevatedPrivileges(delegate()
            {
                using (SPWeb oWeb = oSite.OpenWeb())
                {
                    // Turn off security validation
                    oWeb.AllowUnsafeUpdates = true;
                    // Code to add list item to a list
                    SPList oList = oWeb.Lists["ListName"];
                    SPListItem oListItem = oList.Items.Add();
                    oListItem["PostCode"] = txtPostCode.Text;
                    oListItem.Update();
                    // Turn on security validation
                    oWeb.AllowUnsafeUpdates = false;
                }
            });
        }
    }

Also, in certain circumstances, such as when working with Web forms, you may also need to set the AllowSafeUpdates method to true to temporarily turn off security validation within your code. If you use this technique, it is imperative that you set the AllowSafeUpdates method back to false to avoid any potential security risks.

This is a common mistake when coding using AllowSafeUpdates method, so I think it is worth a mention because not many people knew this.

How to Turn Off SharePoint Custom Error Message and Display Stack and Page Output Trace

When error occurs in SharePoint, by default the following error message is displayed:

To see the "true" description of the ASP.NET errors along with the Stack and Page Output Trace messages, the following steps are required:

• In Windows Explorer, browse to the following folder: C:\inetpub\wwwroot\wss\VirtualDirectories\{SharePoint Port Number} 
• Double-click the SharePoint web.config file.
• In the SharePoint web.config file, look for <customErrors mode="On" /> tag and change it to <customErrors mode="Off" /> - this enables the detailed ASP.NET errors to be shown to the remote clients and to the local host (You can also set the mode value to "RemoteOnly" so that the remote clients can see the Custom Error Message and the local host is shown with detailed ASP.NET errors.).
• In the SharePoint web.config file, locate the <SafeMode MaxControls="200" CallStack="false" tag and change it to <SafeMode MaxControls="200" CallStack="true" - this enables you to received ASP.NET exception messages with stack trace information.
• Next, in the <system.web> element, add the following line <trace enabled="true" pageOutput="true"/> - this enables you to use the tracing feature in ASP.NET to monitor the page output and environment variables of the local host.
• Save and close the file.

You will no longer see the SharePoint Custom Error Message page instead you get the "true" & "lovely" standard ASP.NET error page with the stack and page output trace as shown below:

SharePoint development has got that little bit easier!!.. I would recommend only making the following changes in a development environment and not production environment...