What Permission Delegation changes in Web Security

There is a plan to ship Permission Delegation in Chrome 71. So I will try to summarize what would change in Web Security.

Reasons of why this is happening are explained in this doc so I will skip that part.

If Chrome 71 ships Permission Delegation by default, following is what happens.

https://test.shhnjk.com/trusted.html

Before Permission Delegation

After Permission Delegation

Basically, all permission prompt from cross-origin iframes will also have top-level origin. Of course, most of strong permissions can be requested from cross-origin iframes only if allow attribute is present (<iframe src="https://other.tld" allow="geolocation">) or explicitly allowed by Feature Policy response header (Feature-Policy: geolocation https://other.tld;).

So what would Permission Delegation change in Web Security? Let's say you have HTML injection in some site, but you can't turn that into XSS for whatever reason (e.g. CSP, XSS Auditor, etc). You can now frame your site with allow attribute and inherit permissions from top-level website (or request permission to users with origin of top-level website).

To protect a website against this permission inheritance issue, you should:

• Set appropriate Feature Policy response header in all of responses

Or

• Set CSP response header with appropriate frame-src directive in all of responses

These solution will not solve an issue where https://trusted.tld intentionally frames https://other.tld with allow attribute and https://other.tld has XSS in other pages. Permissions given to https://trusted.tld  are automatically inherited to https://other.tld frame, thus XSS can access that frame through DOM and abuse inherited permissions.

Let me know if something needs clarification 🙂