Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Proposal: Deprecation of "cross-origin-policy" in favor of a declarative network isolation of insecure HTML tags #6553

Closed
ghost opened this issue Apr 2, 2021 · 1 comment
Closed

Proposal: Deprecation of "cross-origin-policy" in favor of a declarative network isolation of insecure HTML tags #6553

ghost opened this issue Apr 2, 2021 · 1 comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@ghost
Copy link

ghost commented Apr 2, 2021 •
edited by ghost
Loading

Context

Web developers need declarative, simple and elegant ways to reason about security and network policies, which are not offered by origin-based policies such as cross-origin-policy.

Why cross-origin-policy should be deprecated ?

  1. cross-origin-policy diverges from the HTML specification

The technology is mainly based on HTTP headers which are not part of HTML, but of a different specification, as a transport protocol.

  1. Control of cross-origin-policy is often not available for web developers

More and more websites are hosted on third-party hosting services and web developers often do not have the possibility or the knowledge necessary in order to modify or control the HTTP headers for their documents on the server-side.

  1. cross-origin-policy is difficult to reason about for web-developers

The technology may lead to very complicated scenarios to reason about (#6552). Moreover, by mixing server-related issues with client-side related issues, it creates confusion and incertitude in the mind of web-developers, who often do not want or need to deal with server-side related settings.

  1. cross-origin-policy is not secure

The technology is not able to isolate critical parts of the application in the eventuality that the hosting server itself or the transport protocol or both get compromised.

Proposal

As first proposed in Per-Module Network Isolation for script tags (#6547), we could achieve security and have fine-grained control over network policies via the declarative network isolation of insecure HTML tags. This proposal is thus an extension of declarative network isolation for all insecure HTML tags beyond the script tag.

For example, we could declare for a siteA.com embedding a siteB.com, that siteB.com can gain network access for all domains excepted the embedder domain siteA.com, via the allow-net attribute in the insecure iframe tag, with a value set to an exclusion ! reference for siteA.com and an all * reference for every other domain:

<iframe src ="https://siteB.com" allow-net="!https://siteA.com; *"></iframe>

Meaning simply here that siteB.com could not access siteA.com resources.

By default, an empty document such as about:blank or the main document of the website siteA.com would not have any network access (w3c/webappsec #578), but we could define and restrict network access within the head of the HTML document:

<head allow-net="siteA.com; sub.siteA.com">
</head>

Security

For Web Applications, which require more security than mere websites and can be distributed as a Web Bundle, the allow-net attribute of the head would not be set, so that by default, the document is offline and does not have any network access.
Then, isolated parts of the application could gain network access via Per-Module Network Isolation, allowing critical parts of the application to stay offline:

<html>
	<head>
		<!-- The main document of `siteA.com`does not have network access-->
	</head>
	<body>
		<!-- The module `login.js` gets access to the hosting server at `siteA.com`-->
		<script type="module" src="login.js" allow-net="https://siteA.com"></script>

               <!-- The module `app.js` does not have network access`-->
		<script type="module" src="app.js"></script>
	</body>
</html>

Defining network policies in the form of HTML attributes would be a more secure, concise and declarative way to achieve network isolation for insecure tags than "cross-origin-policy", and would be more in line with the HTML specification.
@ghost ghost mentioned this issue Apr 2, 2021
Closed
@domenic domenic added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Apr 3, 2021
This was referenced Apr 3, 2021
Closed
Open
Open
Closed
Closed
Open
@domenic
Copy link
Member

domenic commented Apr 6, 2021

Closing per whatwg/fetch#1209 (comment).

@domenic domenic closed this as completed Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Milestone
No milestone
Development

No branches or pull requests
1 participant
@domenic