h5bp/server-configs-apache

Add `Cross-Origin-Embedder-Policy` and `Cross-Origin-Opener-Policy`

summercms opened this issue · 7 comments

summercms commented

Please can you add Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy to the /h5bp/security/ section.

More info: https://web.dev/coop-coep/

More info: https://developers.google.com/web/updates/2020/10/devtools#frame-details

As we want to add it to the apache header list.

LeoColomb commented

Thanks for opening this issue @ayumi-cloud!
These two headers are interesting!
Is there any living standard and some official documentation?

Malvoz commented

There are 2 other headers that relate and ought to be considered: Cross-Origin-Resource-Policy and Origin-Isolation.

Cross-Origin-Resource-Policy(spec, MDN):

The header can, for example, be used to restrict cross-origin access to resources that would otherwise be accessible by default and not restricted per the same-origin policy. Sort of a standard for preventing hotlinking.

For example, when COEP (Cross-Origin-Embedder-Policy) is set to require-corp, an embedded cross-origin resource should respond with Cross-Origin-Resource-Policy: cross-origin, or it'd be blocked.

This header can apply to any resource.

Origin-Isolation (spec):

Origin-Isolation is a related header, it's not supported in browsers yet (outside of origin trials I think), see Chrome status. The WICG Origin-Isolation explainer says:

Deploying COOP + COEP can be a significant burden for sites, e.g. in terms of how it requires all of their embedded content to be updated with CORP, COEP, and COOP headers.

this separate header would be much easier to deploy than COOP + COEP, since it does not require any embeddee cooperation.

This header should probably only apply to the document (html and possibly XML?) per https://github.com/WICG/origin-isolation#using-a-per-document-header and https://github.com/WICG/origin-isolation#more-detail-on-workers.

COEP and COOP should probably apply to the same resources as CSP (i.e. expr=%{CONTENT_TYPE} =~ m#text\/(html|javascript)|application\/pdf|xml#i). Although it doesn't seem to make sense to respond with COEP in PDF files as they cannot embed other files.

More info: https://web.dev/coop-coep/

Also see https://web.dev/why-coop-coep/ and:

  • 👍1
summercms commented

I had 4 headers written down as this:

  • COEP: Cross Origin Embedder Policy

  • COOP: Cross Origin Opener Policy

  • CORP: Cross Origin Resource Policy

  • CORB: Cross Origin Read Blocking

I think I didn't include all 4 as I thought only 2 were ready to use and not under a flag? But it would be nice to add them all.

This header, as well as COEP and COOP should probably apply to the same resources as CSP (i.e. expr=%{CONTENT_TYPE} =~ m#text/(html|javascript)|application/pdf|xml#i). Although it doesn't seem to make sense to respond with COEP in PDF files as they cannot embed other files.

Yah I was thinking would be nice to write it like that. Don't forget they also use the reporting api, see here: https://developers.google.com/web/updates/2020/10/devtools#frame-details

I did send some messages to some security experts to see if they could add these headers to their tools and see how they would try and write the header including their reporting api tools?

Not sure how to best code a pr for this?

If someone wants to give it a go - please go ahead.

Malvoz commented

@ayumi-cloud #250 (comment)

CORB: Cross Origin Read Blocking

CORB is a concept (see CORB for developers and X-Content-Type-Options).

Don't forget they also use the reporting api

I think generally H5BP doesn't or at least have not supported reporting headers/directives in the past, but feel free to open an issue on that.

LeoColomb commented

I think generally H5BP doesn't or at least have not supported reporting headers/directives in the past, but feel free to open an issue on that.

Indeed, as reporting usually refers to private endpoints, it is hard to used them directly here.

At the end, what do you both recommend? Documentation? Configuration addition?