Last Thursday, I had the opportunity to chat with folks in the CMS community about some client-side web security topics that I find pretty relevant today. Preparing the talk was a bit of a strange experience; I think I could have directly copied most of the slides from similar presentations I’ve given years ago, and it’s a little frustrating that they’re still so relevant. That said, this was a good opportunity to discuss some new bits and pieces that are only now coming into focus after a lot of design work and discussion.

I aimed to get a few messages across:

1. My team is focused on two sets of web platform attacks: script injection continues to be both high risk and pervasive, and we’re rapidly discovering the side-channeled consequences of insufficient isolation. These are topics I’d love web developers to be paying attention to as well.

2. Injection attacks can be reasonably mitigated today with a reasonably strict Content Security Policy, and I’m hopeful about our ability to more robustly address the underlying vulnerability via new tools like Trusted Types. I would love to see web developers deploy the former, and start playing around with the latter.

3. Browsers and developers can cooperate to attenuate side-channel attacks by shifting away from the web’s embed-everything defaults, moving instead towards an opt-in model that more tightly constrains attackers’ ability to unexpectedly poke at resources. Chrome will be shipping Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy shortly, and we intend to ensure that they’re in place before enabling some APIs that risk aggravating side-channel attacks. To make this work at scale, it’s critical that we collectively help developers place priority on applying Cross-Origin-Resource-Policy assertions to intentionally-embeddable resources.

   Note that Artur Janc, et al. have put together a great explainer for Cross-Origin Resource/Embedder/Opener Policy that I’m kicking myself for not linking in the talk. So. I’m linking it here, now.

4. I pointed folks to Securer Contexts as an area where I think browsers can revisit the minimum bar for modern applications that we set back in ~2015. Transport security seems quite insufficient to mitigate today’s threats, and nudging developers more firmly towards the tools noted above seems imminently reasonable to me.

I’d appreciate feedback on these priorities, and also on the particular mitigations proposed above. I’m hopeful that they’re generally-applicable and widely-deployable, and would love to hear how y’all see things.

For completeness, I’ll embed the slides below (but I think you’ll only get as much out of them as you’ve already gotten out of the bullets above). For those of you that were in the room, thanks for listening!

Slides

Hosted on Speaker Deck, or as a PDF.

Links from the presentation

• Artur Janc and Lukas Weichselbaum’s “Securing Web Apps with Modern Platform Features from Google I/O in 2019.
• Chromium’s “Post-Spectre Threat Model Re-Think.
• Google’s “Strict CSP” recommendations.
• Christoph Kern’s “Securing the Tangled Web”.
• Krzysztof Kotowicz’ “Trusted Types Help Prevent Cross-Site Scripting”.
• The Trusted Types specification.
• The Scripting Policy thought experiment.
• The Cross-Origin-Resource-Policy specification.
• The Cross-Origin-Embedder-Policy specification.
• The Fetch Metadata specification.
• Example Fetch Metadata policies.
• The Cross-Origin-Opener-Policy specification.
• The “Securer Contexts” proposal.