Repository files navigation

Developers wish to have control over the resources loaded into their pages'contexts and the endpoints to which their pages can make requests. This controlis necessary for several purposes, ranging from architectural insight into andconstraints upon a site's dependencies to the mitigation of exfiltration attackswhich might otherwise put users' data at risk.

Content Security Policy addresses some of this need, but does so in a way thatis more granular than is necessary for the most critical use cases, and with asyntax and grammar that's complicated by the other protections CSP is used todeploy.

If we focus on the single use case of controlling the explicit requests a pagemay initiate through Fetch and other web platform APIs (WebRTC, Web Transport,FedCM, Web Payments, DNS Prefetch, etc), we can likely provide a tool whosepurpose is clear and that's straightforward to use.

In short, a server will distribute a list of acceptable endpoints as an HTTPresponse header, along with some configuration metadata. Before establishinga connection on behalf of a page, the user agent will consult this list ofendpoints, and block the connection before it's made if there's a mismatch.

One syntax which seems sufficient would be a Structured Field parsed as aList with one element: an Inner List whose elements are either the Tokenresponse-origin, or Strings matching theURLPattern syntax forabsolute URLs. This Inner List could be annotated with a small number ofparameters as we discover required extension points. Reporting, for example.That is:

Connection-Allowlist: (response-origin "https://*.site.example" "https://cdn.example" "https://*.site.([a-z\\-]+)"); report-to=ReportingAPIEndpointNameGoesHere

This policy would allow requests and connections to the origin of the serverwhich delivered the response, the specific CDN listed, any subdomain ofsite.example, and any subdomain of any host whose penultimate DNS label issite. URLPattern allows quite a bit of flexibility that we can reusehere rather than inventing a new approach (or reusing a more limited grammarfrom something like CSP).

To effectuate blocking connections, we'd add a check against this list toFetch, and to the more esoteric specifications partially listed above. If theconnection endpoint doesn't match the list, we'll block it, and report metadataabout the violation to the Reporting API endpoint namedReportingAPIEndpointNameGoesHere.

That's it.

This proposal is intentionally small, targeting a specific but useful niche ofclient-side attacks and/or misconfigurations:

• Policies for documents and workers will be asserted by servers as HTTPresponse headers. This means that attackers who can manipulate responseheaders will remain out of scope.

• A document's (or worker's) asserted policy governs only requests initiatedbythat context. If a framed document asserts a distinct policy, so beit (with the caveat that we'll likely inherit this policy into contextscreated via local schemes (data:,about:, etc.), similar to othercomponents of a context'spolicy container)which are handled by HTML when creating new document/worker contexts.

• The connection and/or request are the threat the proposal aims to defendagainst. To be effective as an exfiltration defense, we must blockconnections before they're made.

• There are a plethora of side-channels available as unintended effects ofotherwise-excellent web platform APIs. This proposal does not attempt toaddress them, focusing instead soley on those requests or connectionsexplicitly initiated by the user agent on a page's behalf. This certainlyincludes the clear cases of Fetch and XMLHttpRequest, along with resourcerequests generally. It also includes network connections establishedthrough channels that are less explicitly "requests": manifests fetchedthrough the Web Install API, connections to TURN/STUN servers via WebRTC,Web Transport channels, navigations, and so on. These are all in scope,while more esoteric channels like memory or CPU consumption, socketexhaustion, and XSLeaks in general are not.

• This proposal addresses only communication channels. It does not aim toprevent (or even substantially mitigate) threats like content injectionor cross-site scripting. It only can constrain the impact of such anattackon those specific pages where the policy is in place, and shouldbe considered only as one layer in a page's defenses; it won't besufficient in itself.

• It's tempting to attempt to defend against a subset of server-side threats,like open redirects. It's possible that we could do so in a proposal likethis one, similar conceptually to what CSP does today. That said, CSP'sbehavior around redirects is both a leak in itself, and has garneredinconsistently favorable feedback from developers and researchers alike.For simplicity's sake, this proposal will generally treat redirectresponses as match failures. That is, we'll start with a draconian policywhich will block any redirect response. It's quite possible we'll shiftthis one way or another as use cases crystalize (see the section entitled"You're going to have to rethink a ban on redirects."below).

Three reasons:

1. CSP's model is too granular: Developers who wish to mitigate the risk that data flows outof a sensitive context require a protection that exhaustively covers the possibleways in which requests can be made or connections established. CSP's categorizationof requests into types which can be controlled in isolation is the wrong way toapproach this problem, as data leaking through a request for a web font is just asbad as data leaking through a request for an image or a script. Distinguishing theserequest types complicates the process of designing a reasonable defense with questionsthat are simply irrelevant.

2. CSP's syntax is not granular enough: Thehost-source grammar CSP supports leads to trulyverbose headers being delivered with responses. A distinct policy provides the opportunityto shift to the URLPattern syntax which will resolve some complaints folks have raised aboutCSP's approach by providing a more modern, malleable, and standardized matching syntax.

3. CSP's coverage is incomplete: While CSP does a good job covering HTTP requests which runthrough Fetch, it does not exhaustively cover the myriad ways in which web platform APIsallow connections to be established. DNS prefetch and WebRTC are good examples to startwith, but there are many others which have struggled with exactly how they fit into CSP'sthreat model. By creating a new policy with a narrow focus and explicit promise to developers,these discussions will have a defensible answer and a clear mandate to specification authors.

In short, we should follow CSP's model for resolving multiple policies: each should take effect,and connections will only be established if they pass all of the applicable policies. That is, aresponse containing the following headers:

Content-Security-Policy: default-src https://good.example/ https://sketchy.example/Connection-Allowlist: ("https://good.example/")

requests tohttps://good.example/ would pass both policies, while requests tohttps://sketchy.example/ would be blocked, as they wouldn't match theConnection-Allowlist.

Of course. That's been a critical part of real-world policy deployments, and we'll need it here too:

Connection-Allowlist-Report-Only: (response-origin "https://*.site.example" "https://cdn.example" "https://*.site.([a-z\\-]+)"); report-to=ReportingAPIEndpointNameGoesHere

Navigation (of the current context or any other to which a handle can be obtained) is clearly in-scopefor exfiltration mitigation. In certain contexts, it will be straightforward to list all the possibleplaces to which navigation is expected, and the current proposal will handle those situations well.In other situations, endpoints might be harder to determine. OAuth flows, payment flows, etc. might hoparound in ways which are difficult to predict.

It's potentially necessary for us to split navigation requests out from the rest, possibly by allowingdevelopers to set broad expectations for them via a property on the list(e.g.(...);allow-navigation={same-origin,same-site,cross-origin})? Feedback on use cases here wouldbe quite helpful.

Probably, yes. I want to simplify the initial proposal so we can start talking about it, but I doanticipate redirects being required one way or the other for real-world deployments. I think we havea few realistic options:

1. Apply the allowlist to every hop of a redirect chain. This has the advantage of matching CSP'sbehavior that developers are already familiar with. Itis a cross-origin data leak insofar as itprovides insight about another origin's decisions, which is unfortunate but perhaps unavoidable.

2. Allowa specific rule's redirect chain to arbitrarily redirect. This narrows the concernsabove by forcing developers to annotate the allowlist with their expectations. It might be perfectlyacceptable forhttps://trusted.example/ to redirect users to arbitrary locations, while otherendpoints are expected to remain put. Annotating list items should make this kind of distinctionpossible if necessary (e.g.("https://trusted.example/";redirection-allowed "https://less-so.example/")).

3. Narrow the above by allowinga specific rule to redirect so long as the targets match the allowlist.This creates less opportunity for unexpected connection than 1 or 2 by requiring developers to annotatethe specific rules which can redirect, but would do so in a way that's less broad (e.g.`("https://semi-trusted.example/";redirection-allowed=within-allowlist ...)).

We could add more options as well. CSP's earliernavigate-to proposal distinguished between intermediateredirects and the final, non-redirect response. You could imagine adding those kinds of options either tothe entire allowlist or individual rules. Feedback here as well would be much appreciated.

Of course! It could be a dictionary (allowlist=("a" "b" "c"), report-to=ReportingAPIEndpointGoesHere)!It could be multiple headers! It could be a new CSP directive! The spelling above seems reasonable to me,but feedback on different approaches is welcome!