Checklist: Security Review for Managed Code


Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

patterns & practices Developer Center

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

Microsoft Corporation

Published: June 2003

Applies to:

  • .NET Framework version 1.1

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.


How to Use This Checklist General Code Review Guidelines Managed Code Review Guidelines Resource Access Considerations Code Access Security Considerations

How to Use This Checklist

This checklist is a companion to Chapter 7, "Building Secure Assemblies", and Chapter 8, "Code Access Security in Practice." Use it to help you implement a security review for managed code in your Web application, or as a quick evaluation snapshot of the corresponding chapters.

This checklist should evolve so that you can repeat a successful security review of managed code.

General Code Review Guidelines

Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Potential threats are clearly documented. (Threats are dependent upon the specific scenario and assembly type.)
Ff648189.z02bthcm01(en-us,PandP.10).gif Code is developed based on .NET framework coding guidelines and secure coding guidelines at
Ff648189.z02bthcm01(en-us,PandP.10).gif The FXCop analysis tool is run on assemblies and security warnings are addressed.

Managed Code Review Guidelines

Assembly-Level Checks

Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)
Ff648189.z02bthcm01(en-us,PandP.10).gif 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.
Ff648189.z02bthcm01(en-us,PandP.10).gif Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specify minimum permission requirements.
Ff648189.z02bthcm01(en-us,PandP.10).gif 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
Ff648189.z02bthcm01(en-us,PandP.10).gif Class and member visibility is restricted. The most restrictive access modifier is used (private where possible).
Ff648189.z02bthcm01(en-us,PandP.10).gif Non-base classes are sealed if they contain security secrets (like passwords) accessible through protected APIs or if they contain many virtual members that cannot be sealed and the type is not really designed for third-party extensibility.
Ff648189.z02bthcm01(en-us,PandP.10).gif Input from outside the current trust boundary is validated. Input data is constrained and validated for type, length, format, and range.
Ff648189.z02bthcm01(en-us,PandP.10).gif Code implements declarative checks where virtual internal methods are used.
Ff648189.z02bthcm01(en-us,PandP.10).gif Access to public classes and methods are restricted with principal permission demands (where appropriate).
Ff648189.z02bthcm01(en-us,PandP.10).gif Fields are private. When necessary, field values are exposed by using read/write or read-only public properties.
Ff648189.z02bthcm01(en-us,PandP.10).gif Read-only properties are used where possible.
Ff648189.z02bthcm01(en-us,PandP.10).gif Types returned from methods that are not designed to be created independently contain private default constructors.
Ff648189.z02bthcm01(en-us,PandP.10).gif Unsealed public types do not have internal virtual members.
Ff648189.z02bthcm01(en-us,PandP.10).gif Use of event handlers is thoroughly reviewed.
Ff648189.z02bthcm01(en-us,PandP.10).gif Static constructors are private.


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


Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Secrets are not hard coded.
Ff648189.z02bthcm01(en-us,PandP.10).gif Plain text secrets are not stored in configuration files.
Ff648189.z02bthcm01(en-us,PandP.10).gif Plain text secrets are not stored in memory for extended periods of time.

Exception Management

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


Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Delegates are not accepted from untrusted sources.
Ff648189.z02bthcm01(en-us,PandP.10).gif If code does accept a delegate from untrusted code, it constrains the delegate before calling it by using security permissions with SecurityAction.PermitOnly.
Ff648189.z02bthcm01(en-us,PandP.10).gif Permissions are not asserted before calling a delegate.


Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Serialization is restricted to privileged code.
Ff648189.z02bthcm01(en-us,PandP.10).gif Sensitive data is not serialized.
Ff648189.z02bthcm01(en-us,PandP.10).gif Field data from serialized data streams is validated.
Ff648189.z02bthcm01(en-us,PandP.10).gif ISerializable.GetObjectData implementation is protected with an identity permission demand in scenarios where you want to restrict which code can serialize the object.


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


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

Unmanaged Code Access

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

Resource Access Considerations

File I/O

Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif No security decisions are made based on filenames.
Ff648189.z02bthcm01(en-us,PandP.10).gif Input file paths and file names are well formed.
Ff648189.z02bthcm01(en-us,PandP.10).gif Environment variables are not used to construct file paths.
Ff648189.z02bthcm01(en-us,PandP.10).gif File access is constrained to the context of the application (by using a restricted FileIOPermission).
Ff648189.z02bthcm01(en-us,PandP.10).gif Assembly file I/O requirements are specified using declarative security attributes (with SecurityAction.RequestMinimum).

Event Log

Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Event log access code is constrained using EventLogPermission.

This particularly applies if your event logging code could be called by untrusted callers.

Ff648189.z02bthcm01(en-us,PandP.10).gif Event sources are created at installation time. If unable to create event sources at installation time, the administrator manually creates a new event source entry in the registry.

The account used to run the code that writes to the event log is not allowed to create new event sources by configuring ACL in the registry.

Ff648189.z02bthcm01(en-us,PandP.10).gif Security-sensitive data, such as passwords, is not written to the event log.


Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Sensitive data, such as database connection strings or credentials, is encrypted prior to storage in the registry.
Ff648189.z02bthcm01(en-us,PandP.10).gif Keys are restricted. If a key beneath HKEY_CURRENT_MACHINE is used, the key is configured with a restricted ACL. Alternatively, HKEY_CURRENT_USER is used.
Ff648189.z02bthcm01(en-us,PandP.10).gif Registry access is constrained by using RegistryPermission. This applies especially if your registry access code could be called by untrusted callers.

Environment Variables

Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Code that accesses environment variables is restricted with EnvironmentPermission. This applies especially if your code can be called by untrusted code.
Ff648189.z02bthcm01(en-us,PandP.10).gif Environment permission requirements are declared by using declarative security attributes with SecurityAction.RequestMinimum.

Code Access Security Considerations

If an entry is preceded by a star (*), it indicates that the checks are performed by the FXCop analysis tool. For more information about FXCop security checks, see

Check Description
Ff648189.z02bthcm01(en-us,PandP.10).gif Assemblies marked with AllowPartiallyTrustedCallersAttribute (APTCA) do not expose objects from non-APTCA assemblies.
Ff648189.z02bthcm01(en-us,PandP.10).gif Code that only supports full-trust callers is strong named or explicitly demands the full-trust permission set.
Ff648189.z02bthcm01(en-us,PandP.10).gif All uses of Assert are thoroughly reviewed.
Ff648189.z02bthcm01(en-us,PandP.10).gif All calls to Assert are matched with a corresponding call to RevertAssert.
Ff648189.z02bthcm01(en-us,PandP.10).gif *The Assert window is as small as possible.
Ff648189.z02bthcm01(en-us,PandP.10).gif *Asserts are proceeded with a full permission demand.
Ff648189.z02bthcm01(en-us,PandP.10).gif *Use of Deny or PermitOnly is thoroughly reviewed.
Ff648189.z02bthcm01(en-us,PandP.10).gif All uses of LinkDemand are thoroughly reviewed. (Why is a LinkDemand and not a full Demand used?)
Ff648189.z02bthcm01(en-us,PandP.10).gif LinkDemands within Interface declarations are matched by LinkDemands on the method implementation.
Ff648189.z02bthcm01(en-us,PandP.10).gif *Unsecured members do not call members protected by a LinkDemand.
Ff648189.z02bthcm01(en-us,PandP.10).gif Permissions are not demanded for resources accessed through the .NET Framework classes.
Ff648189.z02bthcm01(en-us,PandP.10).gif Access to custom resources (through unmanaged code) is protected with custom code access permissions.
Ff648189.z02bthcm01(en-us,PandP.10).gif Access to cached data is protected with appropriate permission demands.
Ff648189.z02bthcm01(en-us,PandP.10).gif If LinkDemands are used on structures, the structures contain explicitly defined constructors.
Ff648189.z02bthcm01(en-us,PandP.10).gif *Methods that override other methods that are protected with LinkDemands also issue the same LinkDemand.
Ff648189.z02bthcm01(en-us,PandP.10).gif *LinkDemands on types are not used to protect access to fields inside those types.
Ff648189.z02bthcm01(en-us,PandP.10).gif *Partially trusted methods call only other partially trusted methods.
Ff648189.z02bthcm01(en-us,PandP.10).gif *Partially trusted types extend only other partially trusted types.
Ff648189.z02bthcm01(en-us,PandP.10).gif *Members that call late bound members have declarative security checks.
Ff648189.z02bthcm01(en-us,PandP.10).gif *Method-level declarative security does not mistakenly override class-level security checks.
Ff648189.z02bthcm01(en-us,PandP.10).gif Use of the following "potentially dangerous" permissions is thoroughly reviewed:

Unmanaged Code

Ff648189.z02bthcm01(en-us,PandP.10).gif Code identity permission demands are used to authorize calling code in scenarios where you know in advance the range of possible callers (for example, you want to limit calling code to a specific application).
Ff648189.z02bthcm01(en-us,PandP.10).gif Permission demands of the .NET Framework are not duplicated.
Ff648189.z02bthcm01(en-us,PandP.10).gif Inheritance is restricted with SecurityAction.InheritanceDemand in scenarios where you want to limit which code can derive from your code.

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.