Skip to content
TC39 proposal to identify template strings
HTML JavaScript
Branch: master
Clone or download
Latest commit 6c8e1e0 Jul 3, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
test Make IsTemplateObject realm agnostic Jun 12, 2019
test262/test/built-ins/Array
.gitattributes copy from tc39/template-for-proposals Mar 27, 2019
.gitignore
.npmrc copy from tc39/template-for-proposals Mar 27, 2019
CONTRIBUTING.md guidelines for contributors Mar 27, 2019
LICENSE Initial commit Mar 27, 2019
README.md Link to polyfill Jul 3, 2019
index.html
package.json Make IsTemplateObject realm agnostic Jun 12, 2019
spec.emu incorporate @ljharb's simplifications Jun 13, 2019

README.md

Array.isTemplateObject explainer (stage 2)

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

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.

result = sensitiveOperation`trusted0 ${ untrusted } trusted1`
// Authored by dev          ^^^^^^^^                ^^^^^^^^
// May come from outside                ^^^^^^^^^

This proposal would provide enough context to warn or error out when this is not the case.

function (trustedStrings, ...untrustedArguments) {
  if (Array.isTemplateObject(trustedStrings)
      // instanceof provides a same-Realm guarantee for early frozen objects.
      && trustedStrings instanceof Array) {
    // Proceed knowing that trustedStrings come from
    // the JavaScript module's authors.
  } else {
    // Do not trust trustedStrings
  }
}

This assumes that an attacker cannot get a string to eval or new Function as in

const attackerControlledString = '((x) => x)`evil string`';

// Naive code
let x = eval(attackerControlledString)

console.log(Array.isTemplateObject(x));

Many other security assumptions break if an attacker can execute arbitrary code, so this check is still useful.

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.

Polyfill

There is an es-shim API compatible polyfill available at npm.

Tests

The test262 draft tests which would be added under test/built-ins/Array

Related Work

If the literals proposal were to advance, this proposal would be unnecessary since they both cover the use cases from this document.

You can’t perform that action at this time.