Skip to content
TC39 proposal to identify template strings
HTML JavaScript
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.

Files

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
CONTRIBUTING.md
LICENSE
README.md add a note about `core-js` polyfilling Oct 20, 2019
index.html
package.json
spec.emu

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

An es-shim API compatible polyfill available at npm.

A polyfill is available in the core-js library. You can find it in the ECMAScript proposals section.

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.