Status of This Document
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the
W3C standards and drafts index.
Note
This document is a work in progress and may be changed at any time and without notice.
This document was published by the Security Interest Group as
an Editor's Draft.
Publication as
an Editor's Draft does not imply endorsement
by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than a work in progress.
This document was produced by a group
operating under the
W3C Patent
Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
This document is governed by the
18 August 2025 W3C Process Document.
W3C is a standards development organization that publishes Technical Reports, including W3C Recommendations,
Notes, and Registries, which describe Web technologies and specifications. While these documents may include
occasional references or example source code, W3C does not build or maintain implementations of their standards.
This policy applies to design vulnerabilities or security issues described in W3C
specifications.
This policy does NOT cover:
- Implementation or configuration vulnerabilities in products, open-source projects, or
services that may implement W3C standards. These issues should be reported to the corresponding vendor or
maintainer.
- Vulnerabilities in W3C infrastructure and services that support w3.org domains. These are the
responsibility of W3C Systems, which has its vulnerability disclosure policy.
W3C's response depends on the type of technical report in which the issue was found, the severity of the issue,
and the complexity of the response. W3C will work to resolve confirmed security issues without unnecessary delay.
This policy is based on the recommended steps of ISO/IEC 29147 (Vulnerability Disclosure - VD) and ISO/IEC 30111
(Vulnerability Handling - VH).
W3C handles and routes reports according to the type and maturity of the document in which the security issue is
reported.
If you think you have found a vulnerability in a W3C document, please contact standards-vulnerability@w3.org for coordinated
disclosure.
This email serves as the point of reference for the initial triage by the W3C Team. After triage, the W3C Team
will involve the appropriate group depending on the report and the affected specification. This normally includes
the Team contact, chair, and editors, and may include other people when their input is needed.
It is advisable to send encrypted messages using the PGP key to standards-vulnerability@w3.org. This email does not have a
public archive.
Issue 1
The PGP key for standards-vulnerability@w3.org will be made available before publication.
To facilitate the process, your advisory should include details such as those recommended by ISO/IEC
29147 and NIST SP 800-216:
- The specific document in which the vulnerability is present (e.g., its title, stable URL, and
publication date).
- A concise description of the type of vulnerability (e.g., Use of unsafe cryptographic
algorithms).
- Steps to reproduce the vulnerability, ideally a benign, non-destructive proof of concept.
- The impact of exploiting this vulnerability and how it could be used in an attack scenario.
- Proposed corrective or mitigating measures, if any.
- Your contact details (optional, to enable anonymous reporting, but helpful for follow-up clarifications).
Please note that:
- No "Bug Bounties": W3C does not pay "bug bounties" for reported
vulnerabilities.
- Confidentiality: The Reporter and the Coordinator involved in this policy will
respect the confidentiality of information and data obtained in carrying out their tasks, especially regarding
intellectual property rights, confidential business information, and public and national security interests.
Sensitive vulnerability information should be communicated confidentially to minimise risk.
- Researcher Protections: W3C recognizes the importance of probing security research,
and the potential legal challenges faced by vulnerability researchers in the course of their work.
W3C will not prosecute researchers invetigating information security in good faith for that research activity.
This policy is designed to be compatible with common vulnerability responsible disclosure good practice and does not
permit acting in a manner inconsistent with applicable law.
Once received, security issues will be acknowledged within 3 business days, establishing the
communication channel with the reporter.
After the acknowledgement, the security issue will be evaluated to determine its validity, technical severity,
relevance, and potential impact.
W3C will aim to verify the issue’s validity and inform the reporter within 15 working days. If
more information is needed to verify the security issue, W3C will request additional details from the source.
The W3C Team is responsible for tracking these response targets and for escalating the report when more time,
coordination, or authority is needed.
The advisory will be handled according to the type of document to which it refers.
W3C will then coordinate with the reporter and the groups responsible for the affected document. In most
cases, resolution will primarily involve updating the relevant document.
These are completed, community-reviewed standards.
-
If the Working Group that produced the Recommendation is still active, the Working Group is
accountable for determining the most suitable approach to address it. If confirmed, the vulnerability
might be addressed via:
- An erratum (for minor issues or corrections that do not change the normative content). W3C Working Groups
must keep a public record of errors reported for Recommendations, compiled no less
frequently than quarterly.
- An updated Recommendation specification document (revising the Recommendation).
- An entirely new document to handle the issue.
-
If the Working Group is closed, the W3C Team is accountable for determining the
most suitable approach to address the issue. The severity of the issue will determine the next steps:
- Minor issues can be covered with errata (potentially maintained by the W3C Team if no group is chartered).
- For more significant updates, the W3C Team may promote a different approach.
Class 3 or 4 changes, as per W3C Process, can trigger more extensive review and patent policy implications.
The issue will be handled in the
Security Issue functionality on GitHub.
These are documents adopted by a W3C Working Group, but that they are not yet finalized.
- W3C Working Groups should formally address any substantive review comments about a technical report promptly.
The issue will be handled on the associated Working Group mailing list or the
Security Issue functionality on GitHub.
These are not officially adopted documents in W3C. Editor's Drafts, that haven't been published as a W3C
specification, have no official standing.
- The issue should be handled and discussed with the editors of the document.
- Although not formally adopted, the issue can also be discussed on the associated Working Group mailing list or the
Security Issue functionality on GitHub.
The issue will be handled on the associated Working Group mailing list or through GitHub private
vulnerability reporting for the relevant repository, where enabled.
- W3C Technical Reports that have been marked as discontinued, obsolete, or rescinded are unlikely to
have action taken on them in response to a security issue report. Still, the Team should evaluate
listing them in the Status of the document (SOTD).
The issue will be handled in the
Security Issue functionality on GitHuba>.
These are not officially adopted documents in W3C. Member Submissions are proposed by Members for consideration.
- Any issues found should be handled and discussed with the editors of the document.
The issue will be handled according to the member's policy.
Once the update has been made available and sufficient time has been allowed to implement updates and releases of
related technologies, W3C encourages the sharing and public disclosure of information about fixed
vulnerabilities. This may include a description of the vulnerability, information that allows users to
identify the affected standard, the impact and severity, and clear information to help implementers and users
remediate the issue. In some cases, where security risks of publication outweigh security benefits, disclosure may be
delayed until after implementers and users have had the opportunity to apply the relevant countermeasures.
W3C welcomes requests to disclose your report once the vulnerability has been resolved and aims to coordinate
public release. If the reporter wishes to be publicly recognized, W3C will acknowledge them for reporting
the vulnerability, provided the reporter wishes to be publicly credited.