Add verifier hardening guidance for script injection

[marcoscaceres]

Addresses #133.

This adds an informative subsection, "Verifier hardening against script injection," to the Security Considerations section. It is relying-party-facing guidance. Because the API is exposed in any secure context, a script injected into a verifier's page (through cross-site scripting, a compromised dependency, or a tampered script) can read credential responses the verifier has decrypted and reflected back to client-side JavaScript, and can invoke the API from the verifier's origin to make its own requests. The guidance encourages verifiers to harden their pages with a strong Content Security Policy, complemented by Trusted Types and Subresource Integrity, as defense-in-depth.

It also makes explicit that mandated response encryption does not address this case, because the response is in cleartext once it reaches the page, and that the credential chooser limits silent misuse but does not stop an injected script from reading data the verifier has already exposed. These points reflect the discussion in the issue thread (encryption not protecting reflected data and the risk of a fresh same-origin request, and Subresource Integrity for the supply-chain angle).

The text is non-normative and uses no RFC 2119 keywords, since it is guidance for relying parties rather than a user-agent conformance requirement. It is filed as Addresses, not Closes, because the issue's open question, whether to recommend or to require injection mitigation, is left for the working group; this PR adds the recommendation, not a requirement.

The following tasks have been completed:

• Modified Web platform tests (link) (not applicable: non-normative guidance, no new user-agent behavior to test)

Implementation commitment:

• WebKit (link to issue) (not applicable: non-normative)
• Chromium (link to issue) (not applicable: non-normative)
• Gecko (link to issue) (not applicable: non-normative)

Documentation and checks

• Affects privacy
• Affects security
• Pinged MDN (not applicable: no API surface change)
• Updated Explainer (not applicable)
• Updated digitalcredentials.dev (not applicable)

---

Preview | Diff

[Copilot]

Pull request overview

Adds an informative Security Considerations subsection that warns verifiers that script injection in a relying party context can still exfiltrate decrypted credential data and initiate same-origin requests, and provides defense-in-depth hardening guidance.

Changes:

• Add “Verifier hardening against script injection” guidance covering CSP, Trusted Types, and SRI.
• Clarify why mandated response encryption and chooser mediation do not fully mitigate injected-script risks.
• Update cspell word list to include “subresource”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
index.html	Adds the new informative security guidance subsection and related cross-references.
.cspell/misc.txt	Adds terminology used by the new text to the spellchecker allowlist.

[simoneonofri]

LGTM with a few minor notes.

• Two small edits.
• Then, to make it visible as a threat model entry, it will be linked to the verifier hardening guidance once this PR lands.

Suggested text:

Verifier-origin script compromise: An attacker who can execute script in the verifier’s origin (e.g., through cross-site scripting, compromised dependencies, or tampered scripts), can read the credential responses if the verifier has decrypted them and exposed them to client-side JavaScript.
The same attacker can also try to initiate additional credential requests from that origin, subject to transient activation and user mediation.
The specification can document it and point verifier implementers to hardening guidance, but it does not enforce the integrity of verifier pages. The response strategy is therefore Light Reduce and Transfer: reduce the threat through guidance and platform/security recommendations, but transfer the responsibility to verifier and their dependencies.

[hlflanagan]

Discussed on 8 July 2026. Further discussion required (is a CSP useful/appropriate/possible to require?)

[timcappalli]

We should also talk about the risks due to browser extensions having full page access, which does not have a current mitigation until changes to CredMan are made.

[hlflanagan]

Discussed 13 July 2026. OK to merge after @timcappalli and @mohamedamir review.

[c2bo]

I understand the reason for the text, but maybe we should in general ask for caution on that kind of flow? People shouldn't expose decrypted credential data to client-side JavaScript unless absolutely necessary.

[marcoscaceres]

Makes sense.