Because the impact of installing custom solutions in a SharePoint server farm can be either positive or negative, it is recommended that you to carefully evaluate all custom solutions before deploying them in your production environment.
Along with requiring that the solution be developed in accordance with general best practices, it is recommended that 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 this 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.
Original source: http://technet.microsoft.com/en-us/library/cc707802(office.12).aspx
 |
Click here to mark the task as complete |
|---|---|
| 1 | Use Data Input Inclusion Lists
|
The application uses an inclusion list (known, valid, and safe input) rather than an exclusion list (rejecting known malicious or dangerous input). |
|
| 2 | Encode all output
|
All user input is encoded with IOSec when displayed to clients. |
|
| 3 | Server sets encoding
|
Character encoding is set by the server (ISO-8859-1 is recommended). |
|
| 4 | Encrypt stored credentials
|
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. |
|
| 5 | Secure Cookies
|
If cookies contain sensitive data, they are marked secure. |
|
| 6 | Protect from XSS / SQL Injection
|
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. |
|
| 7 | Canonicalization checks
|
The design addresses potential canonicalization issues. |
|
| 8 | Avoid using 'AllowUnsafeUpdates'
|
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. |
|
| 9 | Robust session management
|
Session state is strong, unpredictable, and protected from unauthorized access or replay attacks. |
|
| 10 | Set session inactivity limit
|
Session lifetime is limited to 30 minutes maximum of inactivity. |
|
| 11 | Protect session identifiers
|
Session identifiers are not passed in the URL, and the ASP.NET feature, cookieless session, is not used. |
|
| 12 | Disable State Server
|
The session state service is disabled if not used. |
|
| 13 | Validation occurs at entry points
|
Input validation is applied at all identified entry points (including form fields, querystrings, cookies, HTTP headers, and Web service parameters). |
|
| 14 | Do we need 'validateRequest' option?
|
The ASP.NET validateRequest option is enabled, if possible. |
|
| 15 | Data type checks
|
Data is validated for type, length, format, and range. |
|
| 16 | Server-side validation
|
Security does not rely on client-side validation. Instead, validation is performed on the server side. |
|
| 17 | Use of consistent input validation approach
|
The application consistently uses standardized input validation such as RegEx throughout. |
|
| 18 | Encrypt sensitive data in logs files
|
The application does not log sensitive data in clear text. |
|
| 19 | No sensitive data in cookies
|
Sensitive data is not stored in cookies. |
|
| 20 | Manage sensitive data on server
|
Sensitive data is not stored in unencrypted, hidden form fields or query strings. It is maintained by using server-side state management. |
|
| 21 | Use of SLL when required
|
SSL, IPSEC with encryption, or application layer encryption prior to transmittal is used to protect sensitive data during transmission. |
|
| 22 | Sensitive data not cached
|
Sensitive data is not cached. Output caching is off by default. |
|
| 23 | Email of sensitive data uses S/MIME
|
Sensitive data that is transferred via e-mail uses S/MIME encryption or Information Rights Management (IRM), depending upon the intended recipient. |
|
| 24 | Use of structured error handling
|
The application uses a standardized approach to structured error and exception handling throughout. |
|
| 25 | Inherit from SPException class
|
Error-handling code inherits from the SPException class to maintain a consistent SharePoint look and feel for errors. |
|
| 26 | Fail securely in error event
|
The application fails securely in the event of error and exceptions. |
|
| 27 | No bypassing of privileged code post exceptions
|
Exception conditions do not allow a user to bypass security checks to run privileged code. |
|
| 28 | Return generic error messages
|
The application returns generic custom error messages to the client. |
|
| 29 | Only capture known exceptions
|
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. |
|
| 30 | Use of exception filters
|
If code uses exception filters, it is not sensitive to filter execution sequence (filter runs before 'finally' block). |
|
| 31 | No sensitive data in exceptions
|
Application errors do not contain sensitive information or information that could be used to exploit the fault. |
|
| 32 | Pack parts in SP Features
|
Custom Web parts (including resource files) are contained within a SharePoint Feature and are packaged as a SharePoint solution in order to be deployed. |
|
| 33 | Allow admins to determine deployment scope
|
The configuration of Web parts that are being deployed gives the administrator the flexibility of deploying to the Web application level or lower. |
|
| 34 | Webparts support connection interfaces
|
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. |
|
| 35 | Have source code of 3rd party webparts
|
Source code for third party Web parts solutions, whenever possible, is provided with adequate documentation to ensure good technical support. |
|
| 36 | Webparts utilize sharrepoint architecture
|
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. |
|
| 37 | Provide installation instructions
|
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. |
|
| 38 | Provide test documentation
|
Customizations are accompanied by test documents and results. |
|
| 39 | Provide list of dependencies
|
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. |
|
| 40 | Provide list of errors/events raised
|
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. |
|
| 41 | Consider providing source code
|
Optionally, source code is provided to expedite validation and testing by the IT organization. |
|
| 42 | Provide change logs for upgrades
|
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. |
