Managed Code Review Guidelines

Assembly-Level Checks

Check	Description
	Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name .)
	You have considered 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 the 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 sandboxed in a separate assembly.

Class-Level Checks

Check	Description
	Class and member visibility is restricted. The most restrictive access modifier is used (private where possible).
	Non-base classes are sealed.
	Input from outside the current trust boundary is validated. Input data is constrained and validated for type, length, format, and range.
	Code implements declarative checks where virtual internal methods are used.
	Access to public classes and methods are restricted with principal permission demands (where appropriate).
	Fields are private. When necessary, field values are exposed by using read/write or read-only public properties.
	Read-only properties are used where possible.
	Types returned from methods that are not designed to be created independently contain private default constructors.
	Unsealed public types do not have internal virtual members .
	Use of event handlers is thoroughly reviewed.
	Static constructors are private.

Cryptography

Check	Description
	Code uses platform-provided cryptography and does not use custom implementations .
	Random keys are generated by using RNGCryptoServiceProvider (and not the Random class).
	PasswordDeriveBytes is used for password-based encryption.
	DPAPI is used to encrypt configuration secrets to avoid the key management issue.
	The appropriate key sizes are used for the chosen algorithm, or if they are not, the reasons are identified and understood .
	Keys are not held in code.
	Access to persisted keys is restricted.
	Keys are cycled periodically.
	Exported private keys are protected.

Secrets

Check	Description
	Secrets are not hard coded.
	Plain text secrets are not stored in configuration files.
	Plain text secrets are not stored in memory for extended periods of time.

Exception Management

Check	Description
	Code uses exception handling. You catch only the exceptions that you know about.
	Exception details are logged on the server to assist in diagnosing problems.
	The information that is returned to the end user is limited and safe.
	Code that uses exception filters is not sensitive to filter execution sequence (filter runs before finally block).
	Code fails early to avoid unnecessary processing that consumes resources.
	Exception conditions do not allow a user to bypass security checks to run privileged code.

Delegates

Check	Description
	Delegates are not accepted from untrusted sources.
	If code does accept a delegate from untrusted code, it constrains the delegate before calling it by using security permissions with SecurityAction.PermitOnly.
	Permissions are not asserted before calling a delegate.

Serialization

Check	Description
	Serialization is restricted to privileged code.
	Sensitive data is not serialized.
	Field data from serialized data streams is validated.
	ISerializable.GetObjectData implementation is protected with an identity permission demand in scenarios where you want to restrict which code can serialize the object.

Threading

Check	Description
	Results of security checks are not cached.
	Impersonation tokens are considered when new threads are created (any existing thread token is not passed to the new thread).
	Threads are synchronized in static class constructors for multithreaded application code.
	Object implementation code is designed and built to be thread safe.
	Threads are synchronized in static class constructors.

Reflection

Check	Description
	Caller cannot influence dynamically generated code (for example, by passing assembly and type names as input arguments).
	Code demands permission for user authorization where assemblies are loaded dynamically.

Unmanaged Code Access

Check	Description
	Input and output strings that are passed between managed and unmanaged code are constrained and validated.
	Array bounds are checked.
	File path lengths are checked and do not exceed MAX_PATH.
	Unmanaged code is compiled with the /GS switch.
	Use of "dangerous" APIs by unmanaged code is closely inspected. These include LogonUser , RevertToSelf , CreateThread , Network APIs, and Sockets APIs.
	Naming conventions (safe, native, unsafe) are applied to unmanaged APIs.
	Assemblies that call unmanaged code specify unmanaged permission requirements using declarative security ( SecurityAction.RequestMinimum ).
	Unmanaged API calls are sandboxed and isolated in a wrapper assembly.
	Use of SuppressUnmanagedCodeSecurityAttribute is thoroughly reviewed and additional security checks are implemented.
	Types are not annotated with SuppressUnmanagedCodeSecurityAttribute . (This attribute is used on specific P/Invoke method declarations instead.)
	Calling code is appropriately authorized using a full stack walk Demand (using either a .NET Framework permission or custom permission).
	Unmanaged types or handles are never exposed to partially trusted code.
	Pointers are private fields.
	Methods that use IntPtr fields in a type that has a finalizer call GC.KeepAlive(object) .