La lista completa se puede encontrar en ingles en el sitio de Microsoft (http://technet.microsoft.com/en-us/library/cc707802.aspx) y una copia en formato Word se puede encontrar en http://technet.microsoft.com/en-us/library/cc707802.aspx#Section3
Además de las reglas de calidad aceptadas para crear código fuente de cualquier tipo, es recomendable seguir las siguientes reglas que son específicas para código de SharePoint. La lista es solamente informativa y no pretende cubrir todos los aspectos aplicables para una organización en particular.
Seguridad
[ ] La aplicación usa una lista de inclusión (entrada de datos conocidos, validos y seguros) en lugar de exclusión (datos no aceptados por ser malicioso o peligroso)
[ ] Todos los datos de entrada deben ser codificados con IOSec cuando son mostrados en la interface
[ ] El set de codificación de caracteres es hecho por el servidor (ISO-8859-1 recomendado)
[ ] Texto plano de claves no debe estar presente en el web.config, machine.config o cualquier otro archivo que contenga configuraciones
[ ] Si hay cookies con información sensitiva, deber ser marcados como seguros
[ ] Controles de entrada de datos deben contener chequeos de límites y de integridad y deben contener rutinas para protegerse de cross-site scripting e inyección de código de SQL
[ ] El diseño debe prevenir la canonalización de situaciones
[ ] No se debe utilizar AllowUnsafeUpdates. Debe usar ValidateFormDigest() y, si es necesario, usar privilegios elevados para interactuar con objectos de SharePoint. Si es indispensable usar AllowUnsafeUpdate, debe ser puesto en false luego de haber sido utilizado
Manejo de sesión
[ ] Estado de sesión debe ser impredecible y protegido de acceso no autorizado
[ ] Sesión debe ser configurada a un límite de 30 minutos como máximo
[ ] Identificadores de la sesión no deben ser enviados en el URL
[ ] El estado de sesión debe estar desconectado si no se utiliza
Validación
[ ] Validación de entrada de datos debe ser aplicada en todos los puntos de entrada (formas, querystrings, cookies, encabezados de HTTP y parámetros de WebServices)
[ ] Si es posible, la opción validateRequest de ASP.NET debe estar activada
[ ] Datos de entrada son validados por tipo, longitud, formato y rango
[ ] Seguridad no solo debe ser al lado del cliente, sino al lado del servidor
[ ] Validación estandarizada debe ser utilizada consistentemente (RegEx pro ejemplo)
Datos sensitivos
[ ] Datos sensitivos no deben ser guardados en texto legible
[ ] Datos sensitivos no deben ser guardados en cookies
[ ] Datos sensitivos no deben ser guardados sin encriptación, en campos ocultos o en querystrings
[ ] Antes de enviar datos, una capa de encriptación SSL o IPSEC debe ser utilizada
[ ] Datos sensitivos no deben ser guardados en el cache
[ ] Datos sensitivos transferidos por e-mail debe usar encriptación S/MIME o Information Rights Manamente (IRM)
Manejo de excepciones
[ ] La aplicación debe usar un sistema estandarizado para estructurar el manejo de excepciones
[ ] El código de manejo de errores debe heredar de la clase SPException para mantener consistencia con SharePoint
[ ] En caso de errores o excepciones la aplicación debe fallar de una forma segura
[ ] Condiciones de excepción no deben permitir a un usuario eliminar los chequeos de seguridad para ejecutar código privilegiado
[ ] La aplicación muestra al cliente mensajes de errores genéricos
[ ] El código debe atrapar solamente excepciones conocidas. Por ejemplo, no use try{} catch(Exception ex){} a menos que el error se transmita directamente
[ ] Errores de aplicación no contienen información sensitiva o información que se pueda usar para explotar el error
WebParts
[ ] WebParts deben estar contenidas in en una Característica de SharePoint y ser empacadas en una Solución de SharePoint
[ ] La configuración de la WebPar deben permitirle al administrador la flexibilidad para instalarla en un nivel de Aplicación Web o más bajo
[ ] La WebPart usa la infraestructura estándar para crear conexiones e intercambiar información
[ ] Para WebParts provenientes de otros fabricantes se debe tener una copia del código de fuente si es posible
[ ] Todas las WebParts deben asegurar conducta y arquitectura consecuente con la funcionalidad por defecto de SharePoint (Single Sign-On, Características, etc)
Documentación
[ ] Instrucciones de instalación y desinstalación deben ser incluidas lo mismo que Diagramas de arquitectura
[ ] Personalizaciones deben ser acompañadas por documentación de las pruebas y sus resultados
[ ] Personalizaciones deben ser acompañadas por una lista de todas sus dependencias, inclusive claves, WebServices, Bases de Datos, otras Soluciones o Características, etc
[ ] Una lista de todos los eventos generados debe ser proporcionada
[ ] Opcionalmente, el código fuente debe ser entregado para acelerar el proceso de aceptación
[ ] Nuevas versiones deben estar acompañadas con información sobre los cambios, consideraciones y forma de regresar a la versión original
