SharePoint is growing in popularity, partially due to its great model for describing and deploying packaged applications. This is especially true in the latest v3 or 2007 release, with the introduction of the “solution” deployment. However, if you’re deploying those applications, you should be aware of the risks involved, particularly if you are hosting a large number of applications in your farm.
Don’t get me wrong, there isn’t anything specifically bad about the model used by SharePoint. However, deploying code in a shared environment always comes with a certain risk. You can mitigate that by limiting the types of elements that are allowed in your farm and/or by having a comprehensive application quality assurance process.
Some types of SharePoint applications are actually perfectly safe in a farm (mostly the ones that are purely metadata-based). Other components are given high privileges in the environment and would need more testing, like web parts deployed to the Global Assembly Cache (GAC) or custom workflow activities. Your farm health is directly related to understanding the difference in order to limit (or even prohibit) certain types of code.
You should promote the use of no-code SharePoint applications. Those are the templates and solution definitions that are based purely in metadata definition, like columns, lists, views, pages and workflows that carry no custom code. If your package (templates and site definitions) has only XML/ASPX files and no assemblies, that a good indication that your risks are low.
Keep in mind that custom web parts include code and you have a choice not to deploy those to the GAC. If you do, they get full trust and could do dangerous things like write to items in the content database. You can limit the permissions granted to those web parts by using code acess security, but developers might be tempted to give it full trus (or put it in the GAC, with automatically gives them full trust). That’s not good. It’s the equivalent of giving a user administrator rights to run a specific application. You should take the time to investigate what permissions are actually needed and grant nothing else.
Custom workflow activities need to be deployed to the GAC, so you need to test those properly. Better yet, you should look into using only workflows that don’t require custom activities, leveraging only those activities provided out-of-the-box. Those end up as XAML, an XML-based description of the workflow. You can do quite a lot with workflows without writing any custom code, but developers might rush into writing code before investigating all that’s built-in. As a rule, if you can build your workflow only with SharePoint Designer, you’re on the safe side. You can build no-custom-code with Visual Studio, too, but you need to watch what options you use there.
ASPX pages in SharePoint are usually safe. By default, these pages will have no “code behind”. In fact, you are only allowed to have code behind if your page in under the “_layouts” folder, which is restricted.
If you must deploy custom code, follow all the steps related to security. Think about security from the early stages of your code design. Use the Visual Studio tools to analyze your application for security issues. Test in a development environment and also in a stage (pre-production) environment before moving the code to production. Take a look at the “Writing Secure Code” book and learn about the Secure Software Development Lifecycle.
One last thing to consider is having separate SharePoint environment for custom code. For a large enterprise deployment, you could have your “no-custom-code” farm where you only deploy out-of-the-box code and no-code customizations. You then create another farm (or multiple farms) for those custom applications. A less technical approach is to charge a premium for that service, which will encourage your customer (external or from one of your corporation’s business units) to consider a no-code approach.
Keep security in mind, leverage no-code applications and have a safe SharePoint deployment.