Indirect eval is a form of JavaScript code evaluation where eval is called in a way that runs the string as global code rather than in the current local scope. The distinction matters because it changes which variables are visible and can reduce scope leakage, but it still executes attacker-controlled code if the input is untrusted.
How indirect eval differs from direct eval
Indirect eval changes the execution context, not the fact that code is being evaluated. In JavaScript, that means the string is parsed and executed as global code instead of inheriting the current local scope, which can make behavior more predictable, but it also changes what data the evaluated code can reach.
That distinction matters because scope is part of the security boundary in application code. A function that appears to limit what eval can see may still expose globals, browser primitives, or server-side process-wide objects that the author did not intend to make available.
Why indirect eval is used
Developers sometimes use indirect eval when they want to avoid accidental access to local variables or to force code into the global environment. In practice, that makes it a mechanism for changing lexical scope, not for making dynamic code safe.
It is also easy to misunderstand in code review because the same API name suggests the same risk profile. The real difference is whether the call is made in a way that preserves the local execution context or breaks out of it.
Security implications of global-code execution
The main security implication is that global execution can widen blast radius. If untrusted input reaches eval, the attacker is still supplying executable code, and the code may gain access to broader ambient capabilities than the author expected, including globals, imported helpers, and state shared across the runtime.
That can turn a local injection issue into a broader compromise of application logic, secrets in memory, or privileged functions that were never meant to be callable from untrusted content.
Safer alternatives and control boundaries
Security-sensitive JavaScript should avoid eval altogether when possible, especially for user-controlled data. Where dynamic behavior is required, safer patterns usually involve explicit parsers, fixed dispatch tables, schema validation, or narrowly scoped expression evaluators that do not execute arbitrary code.
When code execution is unavoidable, the control boundary should be designed around least privilege and strict input handling, not around assumptions that indirect eval meaningfully sanitizes the payload. The safer question is whether the runtime needs arbitrary execution at all.
Risk and Threat Considerations
Indirect eval does not remove code injection risk, it changes the execution scope. That can still be dangerous because an attacker who controls the string can execute arbitrary JavaScript and may be able to abuse broader global objects, shared state, or server-side process privileges.
Failure mechanism: A developer assumes indirect eval reduces exposure enough to treat it like a constrained evaluator, but untrusted input still becomes executable code with access to the runtime environment that remains in scope globally.
Impact: The result can be script injection, data theft, logic manipulation, or further compromise of the application and any sensitive values reachable from the global environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V5 — File Handling | Eval-based code execution is a code-safety concern for input handling and dynamic processing. |
| V15 — Secure Coding and Architecture | Avoiding eval and preserving explicit control flow is a secure-coding decision. | |
| Recommendation — Remove arbitrary evaluation paths and replace them with validated parsing or fixed dispatch logic. Redesign dynamic behavior so it does not depend on arbitrary code evaluation. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted strings reaching eval are an input-validation failure that can enable code execution. |
| Recommendation — Validate and constrain all externally sourced input before it can reach executable logic. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application code review and secure design guidance apply directly to eval misuse. |
| Recommendation — Eliminate dangerous dynamic execution patterns during secure code review. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest Is Protected | If eval can reach sensitive data in memory or application state, protection of data becomes material. |
| Recommendation — Limit exposure of sensitive data to code paths that can be influenced by user input. | ||
Practitioner Guidance
Why practitioners should care: The practical issue is not whether the code runs locally or globally, but whether any untrusted string can become executable at all. If that path exists, the security review should treat it as an injection sink and not as a harmless scope tweak.
What to watch for: Review code that constructs expressions from request data, template fragments, configuration values, or browser state, especially when developers use indirect eval to “make it safer.” That pattern often signals a misunderstanding of the actual risk boundary.
Related resources from NHI Mgmt Group
- How should security teams reduce indirect prompt injection risk in AI systems?
- When does indirect prompt injection become a business risk rather than a technical curiosity?
- Why do indirect prompt injections matter for IAM and NHI governance?
- Why is indirect prompt injection harder to defend than XSS?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org