content
content copied to clipboard
mdn
Initial content for Integrity-Policy
Description
This documents the Integrity-Policy headers.
Motivation
I recently added Integrity-Policy to the platform, and I'd like to document it so developers can use it.
Additional details
https://w3c.github.io/webappsec-subresource-integrity/#integrity-policy-section https://chromestatus.com/feature/5178394056327168 https://github.com/WebKit/standards-positions/issues/458 https://github.com/WebKit/WebKit/pull/45773
We need to file an equivalent BCD PR that would update the fact that this is shipped in Chromium 138. (It also landed in WebKit ToT, but not yet in an STP)
Related issues and pull requests
Fixes https://github.com/mdn/mdn/issues/676
Preview URLs
/en-US/docs/Web/API/IntegrityViolationReportBody/en-US/docs/Web/API/Reporting_API/en-US/docs/Web/HTTP/Reference/Headers/Integrity-Policy-Report-Only/en-US/docs/Web/HTTP/Reference/Headers/Integrity-Policy/en-US/docs/Web/Security/Subresource_Integrity
Flaws (3)
Note! 4 documents with no flaws that don't need to be listed. 🎉
URL: /en-US/docs/Web/HTTP/Reference/Headers/Integrity-Policy-Report-Only
Title: Integrity-Policy-Report-Only header
Flaw count: 3
- unknown:
No generic content config foundno blog rootno blog root
(comment last updated: 2025-06-24 22:34:20)
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has merge conflicts that must be resolved before it can be merged.
@yoavweiss It looks like you ran npm i or similar (this repo still uses yarn v1). Can you remove the package-lock.json, and revert the yarn.lock changes?
@yoavweiss It looks like you ran
npm ior similar (this repo still uses yarn v1). Can you remove thepackage-lock.json, and revert theyarn.lockchanges?
done
Does this use the Reporting_API?
If so, should link/use that doc too.
It is, and it should. I'll add something.
Whether or not it does what does the report look like?
I'll try to copy other examples for representing the report body (e.g. CSP?)
Is there a BCD entry on the way?
I need to add one, yes.
Does this use the Reporting_API? If so, should link/use that doc too.
It is, and it should. I'll add something.
Whether or not it does what does the report look like?
I'll try to copy other examples for representing the report body (e.g. CSP?)
All sounds very good. As we're in discussion on the COEP/COOP headers we can probably follow similar patterns.
I don't want to tread on Chris toes while you two work out what you want here, so can you ping me when you think this is done and I can do a more thorough review. It is worth me waiting because that COOP/COEP stuff will refresh me on how this kind of thing is supposed to work.
@yoavweiss FYI only at some point you added a yarn.lock and package, which is not a good idea. I've rebased to remove those so we can cleanly rebase update when needed.
@yoavweiss Thanks for this. Good changes. I made a number of updates which I will try explain inline in https://github.com/mdn/content/pull/39815/commits/fb00c7a7c23684e52c16e5b3d23e91052f544157
The main point is to better cross link to the reporting API - this isn't just for sending reports to the reporting-endpoint it can also be used for local reporting.
Are you still intending to add a dictionary in the Web API as well and cross link? That is where you would describe the format of the report that you have shown?
This all looks good except for the missing
IntegrityViolationReportBody, which should be a peer of https://developer.mozilla.org/en-US/docs/Web/API/CSPViolationReportBodyLet me know if you're planning to do this. If not, I could take a shot at it.
I'm actually not sure we want to document it as an interface, as there are (vague) plans to turn all these interfaces to dicts: https://github.com/w3c/reporting/pull/284
This all looks good except for the missing
IntegrityViolationReportBody, which should be a peer of https://developer.mozilla.org/en-US/docs/Web/API/CSPViolationReportBody Let me know if you're planning to do this. If not, I could take a shot at it.I'm actually not sure we want to document it as an interface, as there are (vague) plans to turn all these interfaces to dicts: w3c/reporting#284
The change to dictionaries happened and is currently causing some conflicts with the IDL.
I'm happy for you to document it as either as an interface, or as a dictionary. The only difference is that if you do it as a dictionary you would omit to_json and not derive from ReportBody.
The reason both are OK is that the interface is a nothing convenience.
I'm happy for you to document it as either as an interface, or as a dictionary.
If we're documenting it as a dictionary, won't it make the most sense to document it inline (either with the headers, or the broader feature), give that it won't have an explicit name?
If we're documenting it as a dictionary, won't it make the most sense to document it inline (either with the headers, or the broader feature), give that it won't have an explicit name?
The MDN ideal is indeed to do it inline, but not if that would make the docs unusable, which this would.
The dictionaries will still have an explicit name in the spec. All the other ReportBody derived things that are visible in the ReportingObserver are keeping their dictionary name too, and MDN will likely continue to use those.
If it is documented in the header, then in theory you should duplicate that in both the enforce and report-to header for this particular header. Then we have to do that for all the other report bodies as well.
Then we have to do the same thing for all the objects to reflect their use in the API. But where would we do that inline? The "right" place is the callback to the observer constructor, but if we do this inline, we'd have to do it for every single body we have now and in future.
Upshot, is that this is a case where it makes sense to use dictionaries, because doing it inline would be a lot of duplication, and it would be very hard for users to work what do expect for the different kinds of reports.
Does that make sense?
The possible exception is COEP and COOP since these don't have a name and aren't reported through the API (apparently). I'm still tempted to create a body for them but add a note they can ONLY be used through the reporting server endpoint.
Let me know if you're planning to do this. If not, I could take a shot at it.
@hamishwillee maybe it's best if you give it a go, as I'm being distracted by the next shiny object..
@hamishwillee maybe it's best if you give it a go, as I'm being distracted by the next shiny object..
I'll give it a go. Thank you for this. Looking good. Friday or Monday.
This pull request has merge conflicts that must be resolved before it can be merged.
FYI only, I reduced this to only a few commits. The merge history made it hard for me to update and track what was going on. Some loss of "who did what" at commit level sorry.
The reviewdog comments seem spurious/wrong. I am checking.