Security Warnings
Note
This article applies to Visual Studio 2015. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
Security warnings support safer libraries and applications. These warnings help prevent security flaws in your program. If you disable any of these warnings, you should clearly mark the reason in code and also inform the designated security officer for your development project.
In This Section
| Rule | Description |
|---|---|
| CA2100: Review SQL queries for security vulnerabilities | A method sets the System.Data.IDbCommand.CommandText property by using a string that is built from a string argument to the method. This rule assumes that the string argument contains user input. A SQL command string built from user input is vulnerable to SQL injection attacks. |
| CA2102: Catch non-CLSCompliant exceptions in general handlers | A member in an assembly that is not marked with the RuntimeCompatibilityAttribute or is marked RuntimeCompatibility(WrapNonExceptionThrows = false) contains a catch block that handles System.Exception and does not contain an immediately following general catch block. |
| CA2103: Review imperative security | A method uses imperative security and might be constructing the permission by using state information or return values that can change while the demand is active. Use declarative security whenever possible. |
| CA2104: Do not declare read only mutable reference types | An externally visible type contains an externally visible read-only field that is a mutable reference type. A mutable type is a type whose instance data can be modified. |
| CA2105: Array fields should not be read only | When you apply the read-only (ReadOnly in Visual Basic) modifier to a field that contains an array, the field cannot be changed to reference a different array. However, the elements of the array stored in a read-only field can be changed. |
| CA2106: Secure asserts | A method asserts a permission and no security checks are performed on the caller. Asserting a security permission without performing any security checks can leave an exploitable security weakness in your code. |
| CA2107: Review deny and permit only usage | Using the PermitOnly method and CodeAccessPermission.Deny security actions should be used only by those with an advanced knowledge of .NET Framework security. Code that uses these security actions should undergo a security review. |
| CA2108: Review declarative security on value types | A public or protected value type is secured by Data Access or Link Demands. |
| CA2109: Review visible event handlers | A public or protected event-handling method was detected. Event-handling methods should not be exposed unless absolutely necessary. |
| CA2111: Pointers should not be visible | A pointer is not private, internal, or read-only. Malicious code can change the value of the pointer, potentially allowing access to arbitrary locations in memory or causing application or system failures. |
| CA2112: Secured types should not expose fields | A public or protected type contains public fields and is secured by Link Demands. If code has access to an instance of a type that is secured by a link demand, the code does not have to satisfy the link demand to access the type's fields. |
| CA2114: Method security should be a superset of type | A method should not have both method-level and type-level declarative security for the same action. |
| CA2115: Call GC.KeepAlive when using native resources | This rule detects errors that might occur because an unmanaged resource is being finalized while it is still being used in unmanaged code. |
| CA2116: APTCA methods should only call APTCA methods | When the APTCA (AllowPartiallyTrustedCallers) attribute is present on a fully trusted assembly, and the assembly executes code in another assembly that does not allow partially trusted callers, a security exploit is possible. |
| CA2117: APTCA types should only extend APTCA base types | When the APTCA (AllowPartiallyTrustedCallers) attribute is present on a fully trusted assembly, and a type in the assembly inherits from a type that does not allow partially trusted callers, a security exploit is possible. |
| CA2118: Review SuppressUnmanagedCodeSecurityAttribute usage | SuppressUnmanagedCodeSecurityAttribute changes the default security system behavior for members that execute unmanaged code that uses COM interop or platform invocation. This attribute is primarily used to increase performance; however, the performance gains come with significant security risks. |
| CA2119: Seal methods that satisfy private interfaces | An inheritable public type provides an overridable method implementation of an internal (Friend in Visual Basic) interface. To fix a violation of this rule, prevent the method from being overridden outside the assembly. |
| CA2120: Secure serialization constructors | This type has a constructor that takes a System.Runtime.Serialization.SerializationInfo object and a System.Runtime.Serialization.StreamingContext object (the signature of the serialization constructor). This constructor is not secured by a security check, but one or more of the regular constructors in the type are secured. |
| CA2121: Static constructors should be private | The system calls the static constructor before the first instance of the type is created or any static members are referenced. If a static constructor is not private, it can be called by code other than the system. Depending on the operations that are performed in the constructor, this can cause unexpected behavior. |
| CA2122: Do not indirectly expose methods with link demands | A public or protected member has Link Demands and is called by a member that does not perform any security checks. A link demand checks the permissions of the immediate caller only. |
| CA2123: Override link demands should be identical to base | This rule matches a method to its base method, which is either an interface or a virtual method in another type, and then compares the link demands on each. If this rule is violated, a malicious caller can bypass the link demand just by calling the unsecured method. |
| CA2124: Wrap vulnerable finally clauses in outer try | A public or protected method contains a try/finally block. The finally block appears to reset the security state and is not itself enclosed in a finally block. |
| CA2126: Type link demands require inheritance demands | A public unsealed type is protected with a link demand and has an overridable method. Neither the type nor the method is protected with an inheritance demand. |
| CA2136: Members should not have conflicting transparency annotations | Critical code cannot occur in a 100%-transparent assembly. This rule analyzes 100%-transparent assemblies for any SecurityCritical annotations at the type, field, and method levels. |
| CA2147: Transparent methods may not use security asserts | This rule analyzes all methods and types in an assembly that is either 100% transparent or mixed transparent/critical, and flags any declarative or imperative use of Assert. |
| CA2140: Transparent code must not reference security critical items | Methods that are marked with SecurityTransparentAttribute call non-public members that are marked as SecurityCritical. This rule analyzes all methods and types in an assembly that is mixed transparent/critical, and flags any calls from transparent code to non-public critical code that are not marked SecurityTreatAsSafe. |
| CA2130: Security critical constants should be transparent | Transparency enforcement is not enforced for constant values because compilers inline constant values so that no lookup is required at run time. Constant fields should be security transparent so that code reviewers do not assume that transparent code cannot access the constant. |
|---|---|
| CA2131: Security critical types may not participate in type equivalence | A type participates in type equivalence and a either the type itself, or a member or field of the type, is marked with the SecurityCriticalAttribute attribute. This rule fires on any critical types or types that contain critical methods or fields that are participating in type equivalence. When the CLR detects such a type, it fails to load it with a TypeLoadException at run time. Typically, this rule fires only when users implement type equivalence manually rather than by relying on tlbimp and the compilers to do the type equivalence. |
| CA2132: Default constructors must be at least as critical as base type default constructors | Types and members that have the SecurityCriticalAttribute cannot be used by Silverlight application code. Security-critical types and members can be used only by trusted code in the .NET Framework for Silverlight class library. Because a public or protected construction in a derived class must have the same or greater transparency than its base class, a class in an application cannot be derived from a class marked SecurityCritical. |
| CA2133: Delegates must bind to methods with consistent transparency | This warning fires on a method that binds a delegate that is marked with the SecurityCriticalAttribute to a method that is transparent or that is marked with the SecuritySafeCriticalAttribute. The warning also fires a method that binds a delegate that is transparent or safe-critical to a critical method. |
| CA2134: Methods must keep consistent transparency when overriding base methods | This rule fires when a method marked with the SecurityCriticalAttribute overrides a method that is transparent or marked with the SecuritySafeCriticalAttribute. The rule also fires when a method that is transparent or marked with the SecuritySafeCriticalAttribute overrides a method that is marked with a SecurityCriticalAttribute. The rule is applied when overriding a virtual method or implementing an interface. |
| CA2135: Level 2 assemblies should not contain LinkDemands | LinkDemands are deprecated in the level 2 security rule set. Instead of using LinkDemands to enforce security at just-in-time (JIT) compilation time, mark the methods, types, and fields with the SecurityCriticalAttribute attribute. |
| CA2136: Members should not have conflicting transparency annotations | Transparency attributes are applied from code elements of larger scope to elements of smaller scope. The transparency attributes of code elements with larger scope take precedence over transparency attributes of code elements that are contained in the first element. For example, a class that is marked with the SecurityCriticalAttribute attribute cannot contain a method that is marked with the SecuritySafeCriticalAttribute attribute. |
| CA2137: Transparent methods must contain only verifiable IL | A method contains unverifiable code or returns a type by reference. This rule fires on attempts by security transparent code to execute unverifiable MSIL (Microsoft Intermediate Language). However, the rule does not contain a full IL verifier, and instead uses heuristics to catch most violations of MSIL verification. |
| CA2138: Transparent methods must not call methods with the SuppressUnmanagedCodeSecurity attribute | A security transparent method calls a method that is marked with the SuppressUnmanagedCodeSecurityAttribute attribute. |
| CA2139: Transparent methods may not use the HandleProcessCorruptingExceptions attribute | This rule fires any method which is transparent and attempts to handle a process corrupting exception by using the HandleProcessCorruptedStateExceptionsAttribute attribute. A process corrupting exception is a CLR version 4.0 exception classification of exceptions such AccessViolationException. The HandleProcessCorruptedStateExceptionsAttribute attribute may only be used by security critical methods, and will be ignored if it is applied to a transparent method. |
| CA2140: Transparent code must not reference security critical items | A code element that is marked with the SecurityCriticalAttribute attribute is security critical. A transparent method cannot use a security critical element. If a transparent type attempts to use a security critical type a TypeAccessException, MethodAccessException , or FieldAccessException is raised. |
| CA2141:Transparent methods must not satisfy LinkDemands | A security transparent method calls a method in an assembly that is not marked with the AllowPartiallyTrustedCallersAttribute (APTCA) attribute, or a security transparent method satisfies a LinkDemand for a type or a method. |
| CA2142: Transparent code should not be protected with LinkDemands | This rule fires on transparent methods which require LinkDemands to access them. Security transparent code should not be responsible for verifying the security of an operation, and therefore should not demand permissions. |
| CA2143: Transparent methods should not use security demands | Security transparent code should not be responsible for verifying the security of an operation, and therefore should not demand permissions. Security transparent code should use full demands to make security decisions and safe-critical code should not rely on transparent code to have made the full demand. |
| CA2144: Transparent code should not load assemblies from byte arrays | The security review for transparent code is not as thorough as the security review for critical code, because transparent code cannot perform security sensitive actions. Assemblies loaded from a byte array might not be noticed in transparent code, and that byte array might contain critical, or more importantly safe-critical code, that does need to be audited. |
| CA2145: Transparent methods should not be decorated with the SuppressUnmanagedCodeSecurityAttribute | Methods decorated with the SuppressUnmanagedCodeSecurityAttribute attribute have an implicit LinkDemand placed upon any method that calls it. This LinkDemand requires that the calling code be security critical. Marking the method that uses SuppressUnmanagedCodeSecurity with the SecurityCriticalAttribute attribute makes this requirement more obvious for callers of the method. |
| CA2146: Types must be at least as critical as their base types and interfaces | This rule fires when a derived type has a security transparency attribute that is not as critical as its base type or implemented interface. Only critical types can derive from critical base types or implement critical interfaces, and only critical or safe-critical types can derive from safe-critical base types or implement safe-critical interfaces. |
| CA2147: Transparent methods may not use security asserts | Code that is marked as SecurityTransparentAttribute is not granted sufficient permissions to assert. |
| CA2149: Transparent methods must not call into native code | This rule fires on any transparent method which calls directly into native code, for example, through a P/Invoke. Violations of this rule lead to a MethodAccessException in the level 2 transparency model, and a full demand for UnmanagedCode in the level 1 transparency model. |
| CA2151: Fields with critical types should be security critical | To use security critical types, the code that references the type must be either security critical or security safe critical. This is true even if the reference is indirect. Therefore, having a security transparent or security safe critical field is misleading because transparent code will still be unable to access the field. |
| CA5122 P/Invoke declarations should not be safe critical | Methods are marked as SecuritySafeCritical when they perform a security sensitive operation, but are also safe to be used by transparent code. Transparent code may never directly call native code through a P/Invoke. Therefore, marking a P/Invoke as security safe critical will not enable transparent code to call it, and is misleading for security analysis. |
| CA2153: Avoid Handling Corrupted State Exceptions | Corrupted State Exceptions (CSE) indicate that memory corruption exists in your process. Catching these rather than allowing the process to crash can lead to security vulnerabilities if an attacker can place an exploit into the corrupted memory region. |
| CA3075: Insecure DTD Processing | If you use insecure DTDProcessing instances or reference external entity sources, the parser may accept untrusted input and disclose sensitive information to attackers. |
| CA3076: Insecure XSLT Script Execution | If you execute Extensible Stylesheets Language Transformations (XSLT) in .NET applications insecurely, the processor may resolve untrusted URI references that could disclose sensitive information to attackers, leading to Denial of Service and Cross-Site attacks. |
| CA3077: Insecure Processing in API Design, XML Document and XML Text Reader | When designing an API derived from XMLDocument and XMLTextReader, be mindful of DtdProcessing. Using insecure DTDProcessing instances when referencing or resolving external entity sources or setting insecure values in the XML may lead to information disclosure. |