[Security] Declarative network permissions in parent scope for safe request default mode

[ghost]

Context:

The default mode of a request is "no-cors", meaning that, by default, the fetch API is unsafe to use, as pointed out in the specification. The Fetch API is also available by default in script tags, so that a tampered script loaded from a remote third-party CDN can gain full network access within the context of the document or application.

Background:

In (whatwg/html#6553), was introduced a declarative way for web developers to easily reason about network permissions without having to deal with HTTP headers, via the allow-net attribute in insecure HTML tags. This declarative approach for defining network policies would be more in line with the HTML specification than current network policies approaches, while offering:

• no network access by default (offline-first documents and applications)
• enhanced, fine-grained network permissions,
• the possibility to gain network isolation for critical parts of the document/application (Script tag extension: Per-Module Network Isolation html#6547)
• the possibility to define and even extend declarative cross-origin communication scenarios, by leveraging the Shared Worker technology (Proposal: Declarative cross-origin communication in iframe and popup tags via Shared Worker html#6555).

Proposal:

The Fetch API can be made safe by default by using declarative network permissions in the parent scope, via the allow-net attribute in insecure HTML tags.

Example:

<script allow-net="https://example.com">
/* Script has only access to https://example.com */

/* Following fetch will fail */
fetch('https://anothersite.com/data.json')
  .then(response => response.json())
  .then(data => console.log(data));

/* Following fetch will likely succeed */
fetch('https://example.com/data.json')
  .then(response => response.json())
  .then(data => console.log(data));

</script>

<script >
/* Script does not have network access */

/* Following fetch will fail */
fetch('https://example.com/data.json')
  .then(response => response.json())
  .then(data => console.log(data));

</script>

Those declarative permissions could be set at the level of the whole document in the head tag, and/or in a fine-grained way within insecure HTML tags such as iframe, portal, script, etc., that is, everywhere the Fetch API can be used.

[yutakahirano]

cc: @mikewest
Isn't this a proposal to CSP or HTML?

[domenic]

Hi @abflow,

Thanks for your interest in improving the web, and all your many (many) issues proposing novel security mechanisms and models.

However, I think the WHATWG is probably not the best place to pursue those issues, given the lack of interest so far. I'd suggest incubating them in another community, such as https://discourse.wicg.io/. Once you have at least one implementer interested and prototyping your ideas in browser code, we can open issues on WHATWG repositories with specific technical changes.

Until that time, we'd kindly ask that you refrain from opening new issues of this sort. And especially that you stop commenting on existing issues that refer to similar keywords, pointing people to your proposals.

I'll close this and similar issues you've been opening across the WHATWG ecosystem, but I encourage you to take such new proposals to an incubation community such as the aforementioned https://discourse.wicg.io/.

Thanks for understanding,
-Domenic