Security Warnings


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.

CA2100: Review SQL queries for security vulnerabilitiesA 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 handlersA 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 securityA 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 typesAn 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 onlyWhen 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 assertsA 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 usageUsing 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 typesA public or protected value type is secured by Data Access or Link Demands.
CA2109: Review visible event handlersA public or protected event-handling method was detected. Event-handling methods should not be exposed unless absolutely necessary.
CA2111: Pointers should not be visibleA 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 fieldsA 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 typeA method should not have both method-level and type-level declarative security for the same action.
CA2115: Call GC.KeepAlive when using native resourcesThis 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 methodsWhen 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 typesWhen 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 usageSuppressUnmanagedCodeSecurityAttribute 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 interfacesAn 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 constructorsThis 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 privateThe 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 demandsA 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 baseThis 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 tryA 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 demandsA 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 annotationsCritical 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 assertsThis 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 itemsMethods 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 transparentTransparency 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 equivalenceA 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 constructorsTypes 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 transparencyThis 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 methodsThis 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 LinkDemandsLinkDemands 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 annotationsTransparency 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 ILA 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 attributeA security transparent method calls a method that is marked with the SuppressUnmanagedCodeSecurityAttribute attribute.
CA2139: Transparent methods may not use the HandleProcessCorruptingExceptions attributeThis 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 itemsA 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 LinkDemandsA 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 LinkDemandsThis 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 demandsSecurity 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 arraysThe 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 SuppressUnmanagedCodeSecurityAttributeMethods 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 interfacesThis 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 assertsCode that is marked as SecurityTransparentAttribute is not granted sufficient permissions to assert.
CA2149: Transparent methods must not call into native codeThis 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 criticalTo 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 criticalMethods 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 ExceptionsCorrupted 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 ProcessingIf 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 ExecutionIf 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 ReaderWhen 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.