ee-cdn-cli no longer writes Level 1 keys into your built pages

SecurityCLI0.2.0

Built pages carried each Level 1 workload's key in the HTML, readable by every cache in front of the site. From 0.2.0 the key is left out by default and delivered in the address fragment instead, and embedKey opts back in.

A Level 1 site is encrypted so that only someone holding its key can read it, and the key is meant to travel in the address fragment, the part after #, which browsers never send to a server. The CLI’s Astro integration wrote each Level 1 sub-workload’s key into the built HTML as a data-ee-key attribute instead. Anything that stored or passed on the page could keep the key with it: a proxy, a cache, or an archive.

From 0.2.0, the key is left out of built pages by default:

  • The key isn’t written into the HTML. If a page already carries one from an earlier build, it’s removed.
  • The key is still shown once when you build, and kept in your local .ee-cache.json, so you can share the link that carries it.
  • embedKey: true on a workload restores the old behaviour, if you accept that the key is then readable by everything in front of the site.

Only pages built with 0.2.0 or later are protected. Upgrade, rebuild and redeploy any Level 1 site built with an earlier version:

npm install -D @evolving-edge/ee-cdn-cli@^0.2.0

One limit. A page with more than one Level 1 sub-workload can carry only one key in its address, so the extra ones need embedKey: true.

This is the same principle as Level 1 decryption keys never reach our servers, applied to sites built with the CLI.

← All changes · More CLI changes · Subscribe to CLI