Sample code acceptance checklist for IT organizations

Article
01/10/2017

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

Topic Last Modified: 2016-11-14

Web sites that are based on Microsoft Office SharePoint Server 2007 often include custom solutions. The ability to customize sites by adding custom solutions gives Office SharePoint Server 2007 power and flexibility. However, a poorly designed or implemented executable module that runs in a SharePoint farm can do harm even beyond the scope of the Web application for which it was intended. Poorly implemented custom solutions can introduce security or performance risks, increase the cost of support, complicate deployment, and reduce productivity.

Because the impact of installing custom solutions in a SharePoint server farm can be either positive or negative, we recommend that you to carefully evaluate all custom solutions before deploying them in your production environment. Among the areas to evaluate are the following:

Was the solution developed, tested, and piloted consistently with the best practices described in Design and build sites for Office SharePoint Server 2007 and in white papers such as Implementing Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 Solutions?

Along with requiring that the solution be developed in accordance with general best practices, we recommend that you have developers submit a checklist to verify that their solutions have been coded and tested according to best practices.

To help you ensure that the solutions that you deploy provide the intended benefits without exposing the enterprise to unnecessary risk, you can use the following sample code acceptance checklist. Use this list as a starting point for your own checklist to verify the quality of solutions that are submitted for deployment. Along with providing a check after a solution has been developed, your code acceptance checklist can make a good training tool. By providing developers with the list before they implement their customizations, you communicate your expectations of the quality of the solutions that they will develop and submit.

Important

This sample checklist is for informational purposes only. It cannot be assumed that all code acceptance issues are covered in this checklist or that additional measures may not be required applicable for your organization. No warranty, either express or implied, is created by this checklist.

In this topic:

Resources for SharePoint development best practices
Code acceptance checklists
Printable version of the code acceptance checklist (https://go.microsoft.com/fwlink/?LinkID=125134)

Resources for SharePoint development best practices

This section contains a list of resources that you can provide to developers to help them design and implement solutions that meet your IT requirements for usability, supportability, performance, and security.

Code acceptance checklist

This section organizes the code acceptance checklists by the following categories: security, session management, validation, sensitive data, exception handling, Web parts, documentation, general software development best practices. For a printable and modifiable version of the entire checklist, see Printable version of the code acceptance checklist (https://go.microsoft.com/fwlink/?LinkID=125134).

Note

Checklists that are supplied in this document are provided as a sample that you can use to develop your own code acceptance checklist based on the needs of your enterprise. Use it as a starting point to develop your own checklist.

Security

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in a SharePoint environment have been developed by using best security practices.

[ ]	The application uses an inclusion list (known, valid, and safe input) rather than an exclusion list (rejecting known malicious or dangerous input).
[ ]	All user input is encoded with IOSec when displayed to clients.
[ ]	Character encoding is set by the server (ISO-8859-1 is recommended).
[ ]	Plain text passwords are not present in Web.config, Machine.config, or any files that contain configuration settings. Utilities such as Aspnet_setreg.exe and Trustee or the identity setting in AppPool on IIS 6.0 or IIS 7.0 are used to encrypt credentials.
[ ]	If cookies contain sensitive data, they are marked secure.
[ ]	Input surfaces in Web parts and other customizations include boundary checks, input data integrity checks, and appropriate exception handling to protect from cross-site scripting and SQL injection.
[ ]	The design addresses potential canonicalization issues.
[ ]	You avoid using AllowUnsafeUpdates. You use ValidateFormDigest() and, if necessary, use elevated privileges to interact with SharePoint objects. In cases where AllowUnsafeUpdates must be used, you ensure that AllowUnsafeUpdates is set to False in your `try-catch-finally` block, or you use a Dispose() method (as required by the IDisposable interface) to avoid security issues.

Session management

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed by using best practices for managing sessions.

[ ]	Session state is strong, unpredictable, and protected from unauthorized access or replay attacks.
[ ]	Session lifetime is limited to 30 minutes maximum of inactivity.
[ ]	Session identifiers are not passed in the URL, and the ASP.NET feature, cookieless session, is not used.
[ ]	The session state service is disabled if not used.

Validation

[ ]	Input validation is applied at all identified entry points (including form fields, querystrings, cookies, HTTP headers, and Web service parameters).
[ ]	The ASP.NET validateRequest option is enabled, if possible.
[ ]	Data is validated for type, length, format, and range.
[ ]	Security does not rely on client-side validation. Instead, validation is performed on the server side.
[ ]	The application consistently uses standardized input validation such as RegEx throughout.

Sensitive data

[ ]	The application does not log sensitive data in clear text.
[ ]	Sensitive data is not stored in cookies.
[ ]	Sensitive data is not stored in unencrypted, hidden form fields or query strings. It is maintained by using server-side state management.
[ ]	SSL, IPSEC with encryption, or application layer encryption prior to transmittal is used to protect sensitive data during transmission.
[ ]	Sensitive data is not cached. Output caching is off by default.
[ ]	Sensitive data that is transferred via e-mail uses S/MIME encryption or Information Rights Management (IRM), depending upon the intended recipient.

Exception handling

[ ]	The application uses a standardized approach to structured error and exception handling throughout.
[ ]	Error-handling code inherits from the SPException class to maintain a consistent SharePoint look and feel for errors.
[ ]	The application fails securely in the event of error and exceptions.
[ ]	Exception conditions do not allow a user to bypass security checks to run privileged code.
[ ]	The application returns generic custom error messages to the client.
[ ]	The code uses exception handling. The code catches only the exceptions that you know about. For example, do not use `try{} catch(Exception ex){}` unless you throw the error again.
[ ]	If code uses exception filters, it is not sensitive to filter execution sequence (filter runs before `finally` block).
[ ]	Application errors do not contain sensitive information or information that could be used to exploit the fault. .

Web parts

[ ]	Custom Web parts (including resource files) are contained within a SharePoint Feature and are packaged as a SharePoint solution in order to be deployed.
[ ]	The configuration of Web parts that are being deployed gives the administrator the flexibility of deploying to the Web application level or lower.
[ ]	You use the SharePoint Web part infrastructure's standardized set of connection interfaces for Web parts to exchange information with each other at run time.
[ ]	Source code for third party Web parts solutions, whenever possible, is provided with adequate documentation to ensure good technical support.
[ ]	All custom Web parts utilize the SharePoint architecture to ensure consistent behavior across the application for functionality such as single sign-on, feature deployment, and so on.

Documentation

You should require adequate documentation to ensure that customizations that you are being asked to deploy are installable, supportable, and well tested. Furthermore, documentation indicates that all errors that are generated by the customizations are properly described and diagnosed. This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed using best practices for documentation.

[ ]	Customizations are accompanied by installation instructions that detail how to install and uninstall the package. Architecture diagrams that are related to the installation of the solution are included. If it is not possible to roll back a solution, this must be explained in the installation instructions so that you can discuss the risks and prepare a plan for a system recovery.
[ ]	Customizations are accompanied by test documents and results.
[ ]	Customizations are accompanied by a list of all dependencies. This could include account/passwords, Web services, databases, other solutions or Features, patches, tool sets or libraries, and other dependencies.
[ ]	A list of all event entries that are generated by the customizations and the actions to take are supplied. This can take the form of a table of error codes, where the severity and root cause of each code is supplied.
[ ]	Optionally, source code is provided to expedite validation and testing by the IT organization.
[ ]	Customizations that are an upgrade of previously deployed customizations are accompanied by documentation that describes the changes, considerations in upgrading the customizations, and rollback instructions.

General software development best practices

[ ]	Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)
[ ]	You use delay signing as a way to protect and restrict the private key that is used in the strong name and signing process.
[ ]	Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specify minimum permission requirements.
[ ]	Highly privileged assemblies are separated from lower privileged assemblies.
[ ]	If an assembly is to be used in a partial-trust environment (for example, it is called from a partial-trust Web application), then privileged code is in a separate assembly.
[ ]	You rely on a native configuration file to support the application instead of changing the configuration to the Web.config.
[ ]	You use .NET Framework 2.0, 3.0, or 3.5.
[ ]	You use a single .NET Framework version. You do not mix multiple versions.
[ ]	Your code is 64 bit compatible.
[ ]	Your application does not try to directly access any SharePoint databases. Data stores in SharePoint databases are only updated by using the SharePoint object model.
[ ]	You avoid hard coding strings and labels. You use resources or language files instead.
[ ]	When referencing the SPWeb or SPSite objects, you employ a `using` statement or, alternatively, you use an explicit call of the .Dispose method to ensure proper use and disposing of the memory objects.
[ ]	You use caching as appropriate to reduce unnecessary round trips. For Web parts, you expose the cache expiration (duration) as a Web part property.
[ ]	When packaging your solution, you include a Code Access Security policy for the solution and, if necessary, include your assembly in the Safe Controls list though the solution.
[ ]	When logging code, you use the Portal Log class to log the SharePoint Unified Logging Service (ULS) logs.
[ ]	If you need to update multiple list items by using remote code, you use the Web service to update list items. You only use SPListItem.Update() if you have to update more than one item at a time by using local OM-based code.
[ ]	When using the Count property of a SPListItemCollection, you only call it once and then store it in a variable that you can refer to when looping. You do not call it inside a loop.
[ ]	The solution uses the AppSettings object to implement XML mapping. (This can be provided by using the settings persistence framework in .NET 2.0, 3.0, or 3.5.) The solution avoids creating custom XML files and a strongly typed object for XML mapping.
[ ]	Installation and deployment logging are provided in the event logs to enable appropriate operational troubleshooting during installation and uninstallation.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

Plan Sites and Features, Part 1

See the full list of available books at Downloadable content for Office SharePoint Server 2007.

Share via