Security Considerations for Reflection

  • Article

Providing access to nonpublic information involves security risks. Code that is allowed to discover nonpublic information on a type can potentially access code, data, and other information you want to keep private. Therefore, .NET Framework security enforces rules that determine to what degree reflection can be used to discover type information and access types. Depending on the operation being performed, a ReflectionPermission or the SecurityPermission for serialization might be required.

All code can use reflection to perform the following tasks without permissions:

  • Obtain information about public types and their public members.
  • Discover which module and assembly the code is in.
  • Enumerate public types.
  • Enumerate nonpublic types located in the same assembly as the code using reflection.
  • Enumerate assemblies and modules.
  • Invoke public members.
  • Invoke family access members of the calling code's base classes.
  • Invoke assembly access members of the calling code's assembly.

To discover information about nonpublic members, callers must have the ReflectionPermission that represents the ability to obtain type information. Without this permission, code cannot use reflection to obtain information about nonpublic members (even of its own class) through the Get methods on Type, Assembly, and Module.

To use reflection to invoke methods or access fields that are inaccessible according to the common type system accessibility rules, the code must be granted the ReflectionPermission for member access.

**Note   **It is recommended that security policy deny ReflectionPermission to code that originates from the Internet.

The SecurityPermission for serialization provides the ability to get and set any nontransient data fields (that is, members that do not exist only in memory) of serializable types, regardless of accessibility. This permission allows code to discover and alter the private state of an instance. (In addition to being granted the appropriate permissions, the type must be marked as serializable in metadata.)

If a method or a delegate has a LinkDemand for some permission P, the runtime will perform a link demand check against the caller of the method or delegate to verify that the caller has been granted permission P. This link demand check occurs for both discovery of type information and invocation.

Avoid writing public APIs that take MethodInfo parameters, especially for highly trusted code. The permission rights might be more vulnerable to malicious code. For example, consider a public API in highly trusted code that takes a MethodInfo parameter. Assume that the public API indirectly calls MethodInfo.Invoke on the supplied parameter. If the public API does not perform the necessary permission checks, the call to the Invoke method will always succeed, since the security system determines that the caller is highly trusted. Even if malicious code does not have the permission to directly invoke the method, it can still do so indirectly by calling the public API.

See Also

Viewing Type Information | ReflectionPermissionFlag.TypeInformation | ReflectionPermissionFlag.MemberAccess | SecurityPermission | Applying Attributes | Accessing Custom Attributes