Unsafe Reflection

How Unsafe Reflection Works

Unsafe reflection happens when an application lets attacker-influenced input choose what class, method, or field gets inspected or invoked. That turns a programming convenience into a security boundary problem, because the reflected target may expose internal behaviour the developer never intended to make reachable.

Reflection itself is not inherently unsafe. It becomes dangerous when the program accepts names, paths, or selectors from untrusted sources and uses them to resolve code elements dynamically without a tight allowlist or equivalent validation.

Why Unsafe Reflection Is Dangerous

The main danger is that the attacker can steer execution toward privileged, debug, administrative, or otherwise sensitive code paths. In practice, that can bypass intended access controls, reveal internal APIs, or trigger functions that were never designed to be callable from the exposed interface.

This risk often appears in frameworks that support dynamic dispatch, plug-in loading, object instantiation, or metadata-driven behaviour. If the application treats a user-controlled string as a trusted instruction about what to call, the security model can collapse even when the surrounding code looks syntactically correct.

Common Exposure Patterns

Unsafe reflection is most concerning when the reflected target is derived from request parameters, headers, message fields, configuration values, or other externally supplied data. The problem is especially acute when reflection is used to route control flow, because the decision is made before normal business logic or authorization checks can intervene.

Developers also run into trouble when they assume that a type name or method name is harmless because it is "just a string". In reflective code, that string can be equivalent to an executable selector, so weak input handling can become code execution by indirection.

Safer Design and Review Practices

The safest approach is to avoid reflecting on untrusted names whenever a direct call, interface, or explicit dispatch table will do. When reflection is genuinely needed, constrain the accepted targets to a small allowlist, reject unknown values, and keep sensitive classes and methods out of the reachable set.

Security review should focus on where the reflected name comes from, what privilege the invoked target carries, and whether the call path changes based on user input. A code review that only checks for injection syntax can miss this class of flaw, because the issue is control of the target rather than malformed code text.

Risk and Threat Considerations

Unsafe reflection can expose hidden functionality, weaken authorization boundaries, and create an unusually direct path from input manipulation to privileged behaviour. Even when it does not lead to full compromise, it often expands the attack surface by making internal methods reachable through inputs the application was meant to treat as data.

Failure mechanism: An attacker supplies a crafted name or selector that causes the program to instantiate, inspect, or invoke a more powerful target than intended, bypassing the normal control path.

Impact: The result can be information disclosure, broken access control, unintended execution of dangerous code paths, or a stepping stone toward broader compromise.

Practitioner Guidance

What to watch for: Review any code that maps external input to reflective lookups, especially where the target controls object creation, method dispatch, or access to admin functions. Treat dynamic resolution as a security-sensitive decision, not a convenience feature.

Practitioner takeaway: If the input can choose the target, the target must be treated like an authorization boundary, not a harmless string.

Related resources from NHI Mgmt Group

• What happens when ViewState or similar deserialization paths rely on unsafe reflection?
• When does an ephemeral credential become unsafe in agentic environments?
• How can organisations reduce unsafe AI outputs without over-restricting users?
• Who is accountable when an AI agent takes an unsafe action?