isTemplateObject ?
- Stage: Unstaged
- Status: Withdrawn
- ECMAScript edition: —
- Synchronized: Aug 28, 2026
- 中文译文 · Source repository
The proposal introduces Reflect.isTemplateObject, a method that template tag functions can use to determine whether they were called with a genuine template string bundle rather than a forged array. This enables distinguishing trusted, developer-authored strings from potentially attacker-controlled values, helping to safely handle sensitive operations.
The README below comes from the upstream repository and may contain outdated stage or status metadata. Use the proposal details above as the current source of truth.
Reflect.isTemplateObject (withdrawn)
Authors: @mikesamuel, @koto Champions: @littledan, @ljharb Reviewers: @erights, @jridgewell
Provides a way for template tag functions to tell whether they were called with a template string bundle.
Table of Contents
- Use cases & Prior Discussions
- An example
- What this is not
- Possible Spec Language
- Polyfill
- Tests
- Related Work
Use cases & Prior Discussions
Distinguishing strings from a trusted developer from strings that may be attacker controlled
Issue WICG/trusted-types#96 describes a scenario where a template tag assumes that the literal strings were authored by a trusted developer but that the interpolated values may not be.
This proposal would provide enough context to warn or error out when this is not the case.
This assumes that an attacker cannot get a string to eval or new Function as in
Many other security assumptions break if an attacker can execute arbitrary code, so this check is still useful.
An Example
Here's an example of how isTemplateObject lets a tag function wisely use a sensitive operation, namely Create a Trusted Type.
The sensitive operation is not directly accessible to the tag function's callers since it's in a local scope.
This assumes that TT's first-come-first-serve name restrictions solve provisioning, letting only authorized callers access the sensitive operation.
Without isArrayTemplate, this can be bypassed:
The threat model here involves three actors:
- A team of first-party developers (in conjunction with security specialists) decides to trust the tag function.
- A malicious attacker controls a string in the variable
payload. - Non-malicious but confusable third-party library tries to provide a higher level of service by forging a template object.
It assumes its clients are comfortable with trusting
dodgyMarkdownToHTMLConverterto produce HTML for the current origin.
We've addressed this threat model when the first-party developers can be less tolerant of risk than the most risk tolerant third party dependency w.r.t. HTML injection.
This simple implementation doesn't deal with interpolations. A more thorough implementation could do contextual autoescaping.
What this is not
This is not an attempt to determine whether the current function was called as a template literal.
See the linked issue as to why that is untenable. Especially the discussion around threat models, eval, and tail-call optimizations that weighed against alternate approaches.
Possible Spec Language
You can browse the ecmarkup output or browse the source.
Tests
The test262 draft tests which would be added under test/built-ins/Reflect
Related Work
If the literals proposal were to advance, this proposal would be unnecessary since they both cover the use cases from this document.