Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions files/en-us/web/api/coepviolationreportbody/blockedurl/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
---
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@camillelamy I'm hoping to get back to this next month.

When I last looked at this it sounded like COEP and COOP violations would only be reported to server endpoints, and not be visible to reporting observers via the Web API. However looking in the spec for COEP it explicitly states that this will be visible:

The "coep" report type is a report type whose value is "coep". It is visible to ReportingObservers.

Can you confirm that it is visible and that this is also intended for COOP?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@camillelamy Could you please confirm this? Is the report also visible via the API/to reporting observers?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

COEP reports are visible to reporting observers.

COOP property access reports are also visible to reporting observers. The navigation ones are not.

title: "COEPViolationReportBody: blockedURL property"
short-title: blockedURL
slug: Web/API/COEPViolationReportBody/blockedURL
page-type: web-api-instance-property
browser-compat: api.COEPViolationReportBody.blockedURL
---

{{APIRef("Reporting API")}}

The **`blockedURL`** read-only property of the {{domxref("COEPViolationReportBody")}} interface returns the URL of the resource that was blocked from loading by an enforced COEP violation, or would be blocked if a report-only policy was enforced.

## Value

An string containing a URL value.

## Examples

### Get the URL of the resource that triggered the report

In this example we create a new {{domxref("ReportingObserver")}} to observe COEP violation reports, then log the value of `blockedURL` to the console.

```js
const options = {
types: ["coep"],
buffered: true,
};

const observer = new ReportingObserver((reports, observer) => {
const firstReport = reports[0];
console.log(firstReport.type); // coep
console.log(firstReport.body.blockedURL); // URL of the violating resource
}, options);
```

## Specifications

{{Specifications}}

## Browser compatibility

{{Compat}}
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
title: "COEPViolationReportBody: disposition property"
short-title: disposition
slug: Web/API/COEPViolationReportBody/disposition
page-type: web-api-instance-property
browser-compat: api.COEPViolationReportBody.disposition
---

{{APIRef("Reporting API")}}

The **`disposition`** read-only property of the {{domxref("COEPViolationReportBody")}} dictionary indicates whether the policy violation was enforced, blocking loading of the associated resource, or just reported.

## Value

A string that can have one of the following values:

- `"enforce"`
- : The violation caused loading of the embedded resource to be blocked.
This is set for violations of policies set with {{httpheader("Cross-Origin-Embedder-Policy")}}.
- `"reporting"`
- : The violation was reported without blocking the resource from loading.
This is set for violations of policies set with {{httpheader("Cross-Origin-Embedder-Policy-Report-Only")}}.

## Examples

### Get the disposition of a report

In this example we create a new {{domxref("ReportingObserver")}} to observe COEP violation reports, then log the value of `disposition` to the console.

```js
const options = {
types: ["coep"],
buffered: true,
};

const observer = new ReportingObserver((reports, observer) => {
const firstReport = reports[0];
console.log(firstReport.type); // coep
console.log(firstReport.body.disposition);
}, options);
```

## Specifications

{{Specifications}}

## Browser compatibility

{{Compat}}
93 changes: 93 additions & 0 deletions files/en-us/web/api/coepviolationreportbody/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
---
title: COEPViolationReportBody
slug: Web/API/COEPViolationReportBody
page-type: web-api-interface
browser-compat: api.COEPViolationReportBody
---

{{APIRef("Reporting API")}}

The `COEPViolationReportBody` dictionary represents the {{domxref("Report.body","body")}} of a {{domxref("Report")}} that has a {{domxref("Report.type","type")}} of `coep`.

Reports with this type are used by the [Reporting API](/en-US/docs/Web/API/Reporting_API) to notify of violations of COEP policies set with the HTTP headers {{httpheader("Cross-Origin-Embedder-Policy")}} and {{httpheader("Cross-Origin-Embedder-Policy-Report-Only")}}.
A serialized version of the same report structure may also be sent to [reporting server endpoints](/en-US/docs/Web/API/Reporting_API#reporting_server_endpoints).

> [!NOTE]
> This object does not derive from {{domxref("ReportBody")}} (unlike some other {{domxref("Report.body")}} values).

## Instance properties

- {{domxref("COEPViolationReportBody.type")}} {{ReadOnlyInline}}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I run https://wpt.live/html/cross-origin-embedder-policy/reporting-navigation.https.html I get another value for this than the values in the spec: corp.

@yoavweiss Do you know the story here? Is this value deprecated, going/coming?
Are there other values we know about?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, @camillelamy may know

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. Again, it's non-standard. In this case we might just not mention it at all unless we can get some information.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so it seems in Chrome we have three values corp, navigation and worker initialization. The comment above about worker initialization applies. However, I think it makes sense to distinguish between corp and navigation, and I am surprised it is not in the spec. corp is used when a subresource is blocked. navigation when a navigation is blocked. And worker initialization when a web worker script is blocked from loading (but I think this one should go away and the script should never be blocked but inherit COEP from its creator).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@camillelamy Thank you very much - on quick scan I think that is sufficient for me to continue.

I've been sidetracked but I will be coming back to this.
Assuming I have further questions, would it be possible for you to you invite the person who wrote the chrome implementation to be involved so I'm not hassling you? If for nothing else, I'd like to ping them to see if the corp could be added to the spec. Otherwise we're more likely to end up with divergent implementations.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, the person left the company. So I am pretty much the best person to answer your questions for Chrome, but my understanding is sometimes limited.

- : A string representing what kind of cross-origin embedding caused the violation.
- {{domxref("COEPViolationReportBody.blockedURL")}} {{ReadOnlyInline}}
- : A string containing the URL of the blocked resource.
- {{domxref("COEPViolationReportBody.disposition")}} {{ReadOnlyInline}}
- : A string indicating whether the violation was enforced or only reported.

## Description

A document's policies for loading and embedding cross-origin resources are configured and enforced using the {{httpheader("Cross-Origin-Embedder-Policy")}} HTTP header, and may also be reported but not enforced using the {{httpheader("Cross-Origin-Embedder-Policy-Report-Only")}} header.

COEP policy violations may be reported using the [Reporting API](/en-US/docs/Web/API/Reporting_API) whenever a policy set by those headers blocks (or would block) the loading of a resource.

A COEP policy violation report is represented by a {{domxref("Report")}} instance that has the {{domxref("Report.type","type")}} of `coep` and a {{domxref("Report.body","body")}} property that is an object of this type.
Reports can be returned via the {{domxref("ReportingObserver")}} interface or serialized and sent in a `POST` to a [reporting server endpoint](/en-US/docs/Web/API/Reporting_API#reporting_server_endpoints).

To send to a reporting server endpoint the {{httpheader("Cross-Origin-Embedder-Policy")}} and/or {{httpheader("Cross-Origin-Embedder-Policy-Report-Only")}} headers used to set the policy must include the `report-to` parameter with a valid reporting endpoint name.
Valid endpoint names are defined using the {{httpheader("Reporting-Endpoints")}} header.

There are two main causes of violations, which are indicated by the value of the {{domxref("Report.type","type")}} property.
The first is a `navigation` violation, which is caused when an {{htmlelement("iframe")}} or other child browsing context attempts to load a new document or other resource that is not compatible with the embedder policy of its parent for cross origin isolation.
The second is a `"worker initialization"` violation, which is when a page attempts to load a dedicated worker with an embedder policy that is not compatible with the page policy for cross origin isolation.

In both cases "incompatible" means that the parent embedder policy requires cross origin isolation but the embedder policy of the child resource does not provide those guarantees of isolation.
If the resource isn't loaded into a child context (such as a frame), or if the parent does not require isolation, then the embedder policy of the loaded resource doesn't matter.

## Examples

### COEP report

In this example we create a new {{domxref("ReportingObserver")}} to observe coep reports, then log the first report to the console.

```js
const options = {
types: ["coep"],
buffered: true,
};

const observer = new ReportingObserver((reports, observer) => {
const firstReport = reports[0];
console.log(firstReport.type); // coep
console.log(firstReport);
}, options);
```

The logged report object for a COEP violation from loading an iframe might look like this:

```json
[
{
"type": "coep",
"url": "https://url-where-report-sent",
"body": {
"type": "navigation",
"blockedURL": "https://url-of-frame-that-was-blocked",
"disposition": "enforce"
}
}
]
```

## Specifications

{{Specifications}}

## Browser compatibility

{{Compat}}

## See also

- {{httpheader("Reporting-Endpoints")}}
- [Reporting API](/en-US/docs/Web/API/Reporting_API)
- [The Reporting API](https://developer.chrome.com/docs/capabilities/web-apis/reporting-api)
47 changes: 47 additions & 0 deletions files/en-us/web/api/coepviolationreportbody/type/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
title: "COEPViolationReportBody: type property"
short-title: type
slug: Web/API/COEPViolationReportBody/type
page-type: web-api-instance-property
browser-compat: api.COEPViolationReportBody.type
---

{{APIRef("Reporting API")}}{{AvailableInWorkers}}

The **`type`** read-only property of the {{domxref("COEPViolationReportBody")}} dictionary returns a value that indicates the cause of the violation, such as embedding a child resource or loading a dedicated worker.

## Value

A string that can have one of the following values:

- `"navigation"`
- : The violation was caused by an {{htmlelement("iframe")}} or other child browsing context attempting to load a new document.
- `"worker initialization"`
- : The violation was caused by a page attempting to load a dedicated worker.

## Examples

### Get the type of a COEP violation report

In this example we create a new {{domxref("ReportingObserver")}} to observe COEP violation reports, then log the value of `type` to the console.

```js
const options = {
types: ["coep"],
buffered: true,
};

const observer = new ReportingObserver((reports, observer) => {
const firstReport = reports[0];
console.log(firstReport.type); // coep
console.log(firstReport.body.type); // navigation or worker initialization
}, options);
```

## Specifications

{{Specifications}}

## Browser compatibility

{{Compat}}
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
---
title: "COOPViolationReportBody: columnNumber property"
short-title: columnNumber
slug: Web/API/COOPViolationReportBody/columnNumber
page-type: web-api-instance-property
browser-compat: api.COOPViolationReportBody.columnNumber
---

{{APIRef("Reporting API")}}

The **`columnNumber`** read-only property of the {{domxref("COOPViolationReportBody")}} interface indicates the column number in the source file that triggered the [Cross-Origin-Opener-Policy (COEP)](/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-OPener-Policy) violation.

This property is used with {{domxref("COOPViolationReportBody.sourceFile")}} and {{domxref("COOPViolationReportBody.lineNumber")}} to indicate the location that triggered the violation.

## Value

An integer containing the column number that triggered the violation.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For line, column, source file - Need to

  • Add example
  • Add info about what type (s) reports it can be returned in. I think they appear in "access-to-opener" reports (all of them)


## Examples

## Specifications

{{Specifications}}

## Browser compatibility

{{Compat}}
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yoavweiss

Do you happen to know the how HTTP enforcement and report-only headers interwork?

I think that

  • you can have Cross-Origin-Opener-Policy and/or Cross-Origin-Opener-Policy-Report-Only headers on any document.
  • The report(s) sent are from the perspective of the document with the policy and reporting endpoint.
  • Violations are determined by comparing that documents policy (which may be enforced or report only or both) and the enforced policy of the other document (you're always comparing the reporting/enforce policy in the current document to the actual policy of the other document).

So say I have an opener with a Cross-Origin-Opener-Policy: same-site that includes a reporting endpoint, and there is a navigation to another document that in this case has no policy (so a policy of unsafe-none and no reporting endpoint)

Now consider the case where the opener still sets Cross-Origin-Opener-Policy: same-site but the opened sets Cross-Origin-Opener-Policy-Report-Only: same-site-no-opener and Cross-Origin-Opener-Policy-Report-Only: unsafe-none

  • There is a policy violation because the opened is opened in a new BCG.
  • I think a report will be sent to the reporting endpoint of the opener of type navigation-from-response.
  • I think a two reports will be sent to the reporting endpoint of the "opened" document of type navigation-from-response.
  • The first will be of disposition: enforced, and effectivePolicy unsafe-none
  • The second will be of disposition: reporting, and effectivePolicy same-site-no-opener

I think that is what the spec says, and it makes sense to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll again have to call on @camillelamy for help here, as I'm not sure what the answer here should be.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I wrote the spec for reporting in COOP and am much more familiar with the implementation, so this one I can answer.

For COOP, we try to see if a browsing context group would happen were we to enforce all the policies we're asked about.

In practice, we separate enforce/report-only mode (which can have different reporting endpoints).

For enforcement, we only compare with the other document enforced policy: we are reporting that a BCG switch did happen after all.

For report-only, this is a bit more complex. First, we check if the other document report-only policy would ensure that there would be no BCG swap. If that's the case, we won't send a report. Our rational is that developers might want to deploy COOP on several documents in their origin in report-only mode first, and we should not warn them about issues that would not happen if they switch all of their report-only policies to enforcement.

If the report-only don't match, then we check what would happen if we enforced the report-only policy of the document we're navigating to compared with the enforced policy of the current document. We also compare the report-only policy of the current document with the enforced policy of the document we're navigating to. If any of those would trigger a BCG swap, then we note that the documents would ned up in two different browsing contexts. We keep track of this information even if the documents navigate again, this is important for the access reporting. When the BCG switch would be triggered, we also send a report to the relevant endpoints of both the current document and the document we're navigating to. If there are no endpoints, then we don't send a response.

In your second example, you listed two report only policies so I am going to assume you meant unsafe-none as the enforced policy and same-origin-no-opener as the report-only one. In that case, you would get:

  • You get a navigation-from-response report on the endpoint of the opener, with disposition enforced and policy same-origin.
  • You get a navigation-to-response report on the enforced endpoint of the openee with disposition enforced and policy unsafe-none.
  • You get a navigation-to-response report on the report-only endpoint of the openee with disposition report-only and policy same-origin-no-opener.

Now if the openee report-only policy was same-origin, and it was same-origin with the opener, you would not get the third report-only report. But you would still get the first two. And if both documents were same-origin and had report-only same-origin COOP, you would not get any report at all. If only one of them had the report-only COOP, then you would get reports.

This gets a bit more complex for access reporting, as we're keeping track of whether any report-only COOP would have triggered a BCG swap. Then when an access happen, we check if the two documents would be in different BCGs if COOP had been enforced. But the BCG swap might have been triggered during a previous navigation. To give you an example:

  • You document has COOP report-only same-origin. It opens a popup with a cross-origin document. We record that all documents in the popup would be in a different BCG from the documents in the opener page if COOP was enforced. Accesses to the popup/from the popup are reported (provided they involve a same-origin document).
  • The popup navigates to another origin. There is no new BCG switch due to COOP, but we would still report accesses because the pages would still be in different BCGs.
  • The opener navigates to a non-COOP page. This would also trigger a BCG switch if COOP was enforced. We record this. However, we no longer have a reporting endpoint for COOP, so we don't send reports anymore.

title: "COOPViolationReportBody: disposition property"
short-title: disposition
slug: Web/API/COOPViolationReportBody/disposition
page-type: web-api-instance-property
browser-compat: api.COOPViolationReportBody.disposition
---

{{APIRef("Reporting API")}}

The **`disposition`** read-only property of the {{domxref("COOPViolationReportBody")}} dictionary indicates whether the report is for an enforced or report-only policy violation.

Policy violations are enforced if the policy was set with {{httpheader("Cross-Origin-Opener-Policy")}}, and report-only if set with {{httpheader("Cross-Origin-Embedder-Policy-Report-Only")}}.

## Value

A string that can have one of the following values:

- `"enforce"`
- : The report is for policy violation that was enforced.
- `"reporting"`
- : The report is for policy violation that was report-only.

## Examples

### Get the disposition of a report

In this example we create a new {{domxref("ReportingObserver")}} to observe COOP violation reports, then log the value of `disposition` to the console.

```js
const options = {
types: ["coop"],
buffered: true,
};

const observer = new ReportingObserver((reports, observer) => {
const firstReport = reports[0];
console.log(firstReport.type); // coop
console.log(firstReport.body.disposition);
}, options);
```

## Specifications

{{Specifications}}

## Browser compatibility

{{Compat}}
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
title: "COOPViolationReportBody: effectivePolicy property"
short-title: effectivePolicy
slug: Web/API/COOPViolationReportBody/effectivePolicy
page-type: web-api-instance-property
browser-compat: api.COOPViolationReportBody.effectivePolicy
---

{{APIRef("Reporting API")}}

The **`effectivePolicy`** read-only property of the {{domxref("COOPViolationReportBody")}} dictionary indicates the COOP policy of the opened or opener document that triggered the report.
It is present on all reports of type `coop`.

Note that the term "effective" is used for the property because to indicate that it is a policy that is either enforced or reported.

## Value

A string that indicates the policy set in {{httpheader("Cross-Origin-Opener-Policy")}} or {{httpheader("Cross-Origin-Opener-Policy-Report-Only")}} for the document associated with the report.

This will be one of the allowed directive values for [`Cross-Origin-Opener-Policy`](/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Opener-Policy#directives).

## Examples

### Get the effectivePolicy of a COOP violation report

In this example we create a new {{domxref("ReportingObserver")}} to observe COEP violation reports, then log the value of `effectivePolicy` to the console.

```js
const options = {
types: ["coep"],
buffered: true,
};

const observer = new ReportingObserver((reports, observer) => {
const firstReport = reports[0];
console.log(firstReport.type); // coep
console.log(firstReport.body.effectivePolicy); // A COOP directive such as unsafe-none or same-site
}, options);
```

## Specifications

{{Specifications}}

## Browser compatibility

{{Compat}}
Loading