Connection Allowlists

I noticed a relatively innocuous "Connection Allowlists" reference in the recent Chrome 148 Release Notes, and I was intrigued.

Connection Allowlists is a feature designed to provide explicit control over external endpoints by restricting connections initiated using the Fetch API or other web platform APIs from a document or worker.

It sounded a bit like Content Security Policy (CSP). CSP is a set of specifications that make the web a tremendously safer place by allowing web sites to specify what can and can't be done, in general terms, by content that is referenced by the web page. For example, a web site that accepts payments can serve a carefully-crafted CSP header that would prevent malicious browser extensions, compromised ads, or the site's own poorly sanitized user-generated content from allowing threat actors to access your payment data. It's not the only mechanism a site should use, but it's one layer of defense-in-depth. Defense-in-depth (that is, multiple layers) is absolutely crucial in a system with a lot of moving parts like, oh, say...the web.

"Carefully-crafted CSP header" is doing a lot of work in that last paragraph -- as I might put it in my East Texas vernacular: CSP can be a real pain in the ass.

I say that despite my very strongly-held opinion that CSP plays an absolutely crucial role in making the web a much safer place, and should be implemented anywhere that privacy and security are important...which is pretty much everywhere. So CSP is critical, but it's hard for teams -- especially small teams -- to get right. It seems pretty far down on the list of things most front-end devs I know care about, which is unfortunate, because front-end devs are the ones who generally know what the CSP should actually contain. And it's even further down on the list of things most of the back-end devs I know care about. The Infrastructure/DevSecOps/Platform Engineering/SRE folks I know care a LOT...but in any given situation, they're unlikely to have the context to craft the CSP, so spend a lot of time in confusing conversations with the front-end folks.

Full-stack generalists like me are probably in the ideal spot to understand and implement CSP, but speaking as a full-stack generalist, when you wear a lot of hats, you get spread thin, and it's hard to focus, and CSP deserves a bit of focus.

So anyway, I got a little excited and took a look at the Connection Allowlists Draft Community Group Report document published by the Web Platform Incubator Community Group (WICG). The WICG is a group that incubates ideas from the web developer community, until they can be migrated to a more formal World Wide Web Consortium (W3C) Working Group. Basically these are the folks that design the web.

It didn't take me long to figure out it's a LOT like CSP -- but less redundant, less error-prone, and with a more workable syntax. The WICG didn't bury the lede -- they spelled it out right there in the first few paragraphs of the Draft Community Report doc.

OK! So I went from intrigued (while reading the Chrome release notes) to excited (while reading the Draft Community Report) to motivated. Time to play.

First, I signed up for the corresponding Chrome origin trial by clicking through the link in the Chrome 148 Release Notes, which allowed me to get a token value to serve in the Origin-Trial header, alongside the new Connection-Allowlist. As I write this, I'm not 100% certain this is necessary after Chrome 148, but it seemed logical at the time. If I get a chance I may go back and see if Chrome 148 honors Connection-Allowlist without it. But it was quick and easy in any case.

After that, I went to the specification and cooked up my Connection-Allowlist header (or, more precisely, Connection-Allowlist-Report-Only - the non-enforcing version that only reports violations rather than blocks them). I also noticed that the reporting endpoint for Connection-Allowlist is specified by a Reporting-Endpoints header, which differs from the mechanism I was originally using for CSP on the site I was experimenting with. (Side note: that makes at least three flavors of reporting-endpoint specification I'm juggling -- between CSP, COOP, NEL, etc., and now Connection-Allowlist, which means I should probably go look up the latest on which are deprecated by the latest Reporting-Endpoints, clean all that up in my headers if I can, and write about that as well. Another day.)

After a bit of experimentation and some trial-and-error, I ultimately had my headers:

Origin-Trial: <ORIGIN_TRIAL_TOKEN_GOES_HERE>
Connection-Allowlist-Report-Only: (response-origin "https://api.dev.epicroadtripplanner.com"); report-to=default
Reporting-Endpoints: default="https://<redacted>.com/report-to"

By serving these headers, my site tells Chrome that it's in the origin trial for the Connection-Allowlist (and Connection-Allowlist-Report-Only) headers, and that it should report any JavaScript fetch (or other supported request type) that goes anywhere besides the site itself and api.dev.epicroadtripplanner.com.

(I've redacted my actual reporting endpoint in the snippet above.*)

To test it, I added a bit of JavaScript to one of the pages on my personal dev site, to try to fetch campground data for Fort Casey:

try {
  console.log("Fetching from dev (allow-listed)...")
  const response = await fetch("https://api.dev.epicroadtripplanner.com/v1/campgrounds/3a198528-95cf-4235-a40e-c9597d0a877a", {
    headers: {
      'accept': 'application/json'
    }
  });
  console.log("Response:", response);
} catch(e) {
  console.error(e)
}

try {
  console.log("Fetching from prod (not allow-listed, reported)...")
  const response = await fetch("https://api.epicroadtripplanner.com/v1/campgrounds/84af4262-6dff-4121-b22d-70b6173b15f6", {
    headers: {
      'accept': 'application/json'
    }
  });
  console.log("Response:", response);
} catch(e) {
  console.error(e)
}

Since I'm using the report-only variant (Connection-Allowlist-Report-Only) rather than the enforcement variant (Connection-Allowlist), both calls succeed -- but only the prod call is reported.

I got this single connection-allowlist report on my reporting server, for the call to the prod server:

I also tried the enforce version and played around with a few other items. Now that I know this all works at a high level, I'm looking forward to going deeper -- reviewing the actual CSP headers on a few of my sites and seeing just how much simpler and more specific the corresponding Connection-Allowlist headers can be. I'll also be watching how the WICG draft evolves. Good stuff!

-Tim

*I'm redacting my default reporting endpoint, not because it's a secret -- it can't be, since it's served publicly in the header -- but because I don't want anyone or an LLM copying the headers above verbatim and inadvertently sending a bunch of their own error reports to my reporting site, filling it with noise and probably blowing out my quotas. A former co-worker had that happen with his public NTP server, and I really hope he can laugh about it now 20+ years later, but I'm sure it wasn't funny at the time. But I digress. Shoot me an email and let me know if I should write up how to deploy a very lightweight reporting endpoint just for experimentation; it's pretty easy.