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.
Therefore, 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 must be addressed by their corresponding vendor or
maintainers, as W3C does not have a formal means to reach these parties.
- 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 appreciates the comments made by researchers on their work. The response from W3C will depend on the type of
technical report in which the problem was found, the severity of the problem, and the complexity of the solution.
W3C will try to resolve and correct security issues as soon as possible. It follows the process that 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 assessment and action by the group designated to coordinate
Vulnerability Disclosure and Handling, composed of the W3C Team and relevant groups.
It is advisable to send encrypted messages using the PGP key to standards-vulnerability@w3.org.This. This email does not have a
public archive.
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 good-faith security research. W3C
will provide non-prosecution information security researchers and an exemption from civil
liability for their activities, acknowledging the challenges faced by vulnerability researchers. 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 criticality,
importance, 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 advisory will be handled according to the type of document to which it refers.
W3C will then collaborate with the reporter and the groups impacted by the security issue, which 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 the Security Issue
functionality on GitHub.
- 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 GitHub.
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, including a description of the vulnerabilities, information allowing users to identify
the affected standard, the impacts, their severity, and clear, accessible information to help implementers and
users remediate. 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.