Skip to content

Proposal for Foundational Structural Re-Alignment of EN 304-617 in the Context of the Web Security Model and CRA

Proposal for Foundational Structural Re-Alignment of EN 304-617 in the Context of the Web Security Model and CRA

Following a first and high-level review of the current draft of EN 304-617 "Browsers - Essential Cybersecurity Requirements", we would like to provide preliminary structural feedback.

Although the available review time is not proportionate to the length and complexity of the draft, as also reflected in feedback from other stakeholders in other issues and during the Deep Dive session, it was nevertheless possible to identify certain structural aspects that may merit reconsideration. With additional time and detailed line-by-line analysis, further issues may emerge.

Given that the web security model is defined and maintained by other Standards Development Organizations (SDOs), earlier structured coordination could have facilitated architectural alignment from the outset and reduced the need for subsequent structural reconsideration.

At this stage, we respectfully suggest that the document may benefit from foundational structural reorganization to ensure:

  • A clearer separation between the web security model, as defined by other SDOs, and the profiling role of this draft in the context of web browser deployments. The document structure could more explicitly relate the product boundary (e.g., a web browser in a specific deployment environment) to the externally defined web security model and the CRA risk-based compliance framework.
  • Reconsideration of the current capability–condition tier system, which, on the one hand, complicates the selection of applicable requirements and, on the other hand, does not take into account that web browsers already enforce fundamental security principles (e.g., isolation of untrusted third-party content). It may be preferable to distinguish between mandatory baseline security properties and optional hardening measures.
  • Adoption of a more top-down and outcome-oriented structure, similar in spirit to the BSI minimum standard for web browsers and the EN 304-626 draft. The current draft, in several areas, specifies implementation mechanisms with a level of detail that may limit its longevity.
  • More explicit alignment with the risk-based logic of the CRA, potentially structuring the document around an explicit **risk-based **Threat Model, supported by data flow diagrams and control structures.
  • Clearer alignment with the CRA Annex I. For example, update logic, vulnerability handling, security-by-design, security-by-default, and risk analysis would benefit from more explicit structural anchoring, providing clearer guidance on secure deployments. In contrast, the draft focuses on the implementation of specifications by web browsers.
  • Clarification of the role of Clause 6 and Annex A as compliance-supporting artefacts suitable for OJEU citation.

In its current structure, the draft may risk:

  • Being perceived as evolving toward a parallel web security specification, rather than toward secure web browser deployments, while the focus of CRA is on products.
  • Presenting long-term maintenance and usability challenges due to implementation-specific prescriptions.

Below is our feedback for each Clause.

Clause 1 - Scope

This section contains definitions, obligations for manufacturers, and the state of the art in security practices.

  • There are several inconsistencies and conceptual misalignments in the definitions and in the attribution of standards. For example: "web browser" and not "browser", as described in Web User Agents, which is also redefined elsewhere and in Clause 3; WebAuthn is a W3C REC, not an IETF RFC.
  • The scope boundaries could benefit from clearer delineation of what is outside the scope and why.

Feedback

  • Consider defining the scope more explicitly and concisely, e.g., with a specific "In scope" section and an "Out-of-Scope" product type section (e.g., Websites, PWAs, Mini-Apps).
  • Distinguish embedded browsers based on how they integrate with the host. For example, ElectronJS-based applications have specific characteristics regarding browser updates, the access that web pages have to the browser and, therefore, to the operating system, and additional risks, as Cross Site Scripting (XSS) can become Remote Code Execution (RCE), and their Threat Model is different from that of a standalone web browser or a WebView.
  • State that the web security model is defined elsewhere and that this draft deals with implementation and deployment profiles of products that use web browsers.
  • It may be appropriate to relocate the obligations and responsibilities of manufacturers to the appropriate section, map them to the corresponding evidence required for the presumption of conformity and legal intent, and ensure they remain necessary and proportionate, in particular, regarding the proposed scheme for browser engines and derivative products, considering the impact on the Open Source Community.

Clause 2 - References

This section contains a minimal list of references, both regulatory and informative.

  • The draft references several documents that are not yet reflected in this section, suggesting that this section may still be consolidating.
  • Nevertheless, it is appropriate to include here the feedback on several references we found regarding W3C-related material.

Feedback

  • Clearly distinguish normative references to stable documents (e.g., W3C REC, IETF RFC) and references to unstable documents (e.g., W3C Community Group reports, W3C GitHub-hosted pages), in addition to including them among normative or informational references.
  • We understand there may be procedural constraints regarding referencing W3C RECs. We have a process in place to enable their reference; we remain available to support this process. One example is the EN 301 549.

Clause 3 - Definitions

This section contains definitions, symbols, and abbreviations.

  • Web terminology, as defined elsewhere or in Clause 1, appears to be restated here.

Feedback

  • Clearly define the authority over terminology defined elsewhere and the security profiles defined in the draft, to avoid redefining terminology that is already authoritatively defined elsewhere.
  • Consider consolidating the definitions currently in Clause 1 within this Clause.

Clause 4 - Product Context

This section contains a list of uses and environments that are out of scope; in-scope components for different web browser classifications (e.g., standalone, embedded); and use cases. It also explains how to apply this for conformity assessment and use cases. Finally, the product definition includes architectural review, trust boundaries, deployment contexts, relevant security features, essential functions, operating environments, users, behavior patterns, and accessibility considerations.

  • Section "4.2 Out of scope use/environments" contains a list of uses derived from the CRA, and it would benefit from clarification on why this section is here, in particular within the context of web browsers.
  • Section "4.3. In-Scope components" lists components, but the relationships among them are not explained. Furthermore, the term "Out-of-Scope Components" is defined in a subsection that may benefit from clarification.
  • Section "4.4 Use Cases," particularly Scope and Applicability, would benefit from clarification because PWAs reappear, and the use cases are a mix of deployment and usage scenarios. For example, UC-B4 is a standard navigation case; UC-B5 includes session re-authentication and timeout in the security considerations, but it is not clear whether it refers to the operating system on which the web browser runs or to the web application used. In general, however, the web browser threat model is that they do not trust the content of third-party websites; UC-B10, on the other hand, is essentially different and refers to modified web browsers, as does UC-B12, which considers SuperApps, which are architecturally distinct.
  • Section "4.5. Product overview and architecture" may be ambiguous: it repeats concepts defined previously (i.e., 4.3 In-Scope Components), outlines a threat model (4.5.3 Trust Boundaries and Threat Model), and describes the functions of a web browser.
  • Section "4.6 Essential functions" not only defines the product's context but may also be interpreted as introducing implicit requirements, even though no regulatory terminology is specified.
  • Section "4.7 Operational Environment" defines the environment, but it would benefit from clarification whether it relates to section 4.2, and it seems to include requirements for User Training and Awareness.
  • Section "4.8 Users" lists users and their needs.

Feedback

  • This section may lead to ambiguity at the macro-structural level, first of all. For example, a logical thread: the product (4.5) should be defined first, then what is in scope (4.3) or what is not (4.2), the environment, use cases, users, and security functions needed.
  • It would be important to organize the section logically and to move in-scope and out-of-scope components to the appropriate sections of the document. Still, a reconsideration of the structural approach may be appropriate.
  • Given that the CRA approach is risk-based as stated in Art 13(2), it may be appropriate to consider using this section to set up a structured web browser product threat model (drawing on what already exists in this regard in W3C), with data flows that connect the components, so that trust boundaries can be properly defined, along with the related threats, with related diagrams for the various scenarios. This approach may facilitate clearer requirements mapping. Given that web browsers are complex systems, one could also consider using System Theoretic Process Analysis (STPA).

Clause 5 - Requirements

This section contains the security requirements; it uses a capability-condition framework, and starts with "5.1. Isolation Mechanisms", then "5.3 Encryption Implementation", "5.6 Protocol Handler Security", "5.7 Core Component Security", "5.8 Embedded Browser Security", "5.10 Derivative Browsers" (Some section numbering appears to require review):

  • Some sections such as the "5.1.1 Domain and Origin Isolation" describe implementation approaches for what is defined in standards elsewhere (which typically contain normative language in this regard and related implementation tests), including implementation-level detail (e.g., "Browser shall implement process-per-site isolation" versus "The web browser should ensure that the compromise of one component does not allow unauthorized access to other components").
  • Other sections, such as "5.2.1 Third-Party Code Execution", or "5.4 Diagnostic and Monitoring Systems", reflect varying levels of abstraction, including procedures for installing extensions or logging capabilities, and what to log.
  • Other sections, such as "5.3.1 Data Protection Layers", on the one hand, indicate the use of specific versions of "TLS 1.3 or higher" (ENC-0-REQ-1), the draft may require future updates as cryptographic standards evolve On the other hand, it has another level of detail for cipher suites: "cipher suites to strong, modern algorithms only", and, in addition, some requirements appear to overlap partially.

Feedback

  • In general, it may be advisable to use a clear, simple security profile based on the risk-based threat model suggested in the feedback of Clause 4, following the approach defined in CRA Art 13(2).
  • Specify the structure of requirements (e.g., requirements structure, necessity, type, assumption, and note for the risk transfer).
  • Further organize and focus the requirements on the relevant web browser as a product, as defined in the CRA. For example: Annex I, Part I - e.g., (a) No known exploitable vulnerabilities, (b) secure by default, (c) security updates, (d) protection from unauthorized access (if applicable for the web browser), (e) confidentiality of stored information and transport security, (f) integrity of data, (g) data minimization, (h) security by design, (i), logging, data deletion.
  • For each requirement, structure it descriptively, stating the security outcomes/objectives rather than the mechanism, and specify the proper categorization and mapping between web browser components, specific use case scenarios, and other relevant information to determine whether the requirement applies to the specific threat model.
  • If a requirement is already defined in other specifications (e.g., Same Origin Policy, Sub Resource Integrity), avoid restating it, but refer to the specification. This also applies in particular to the Assessments contained in Clause 6, which over-detail the assessment method. For example, the approach used in the BSI minimum standard for web browsers is more streamlined and practical.
  • There is also a long list of Web APIs, but it is unclear how they were selected. Moreover, the maturity level of the referenced APIs is inconsistent, with some Recommendations, others drafts, and still others in the incubation stage (Community Report). This may pose a practical maintenance challenge and risk of becoming obsolete shortly after publication. Therefore, it may be advisable to consider API selection during threat modeling.
  • Additional mapping tables may enhance usability.

Clause 6 - Assessment

This section describes how to assess the requirements defined in the previous Clause.

  • This section reflects structural issues in the previous clauses. In the proposed reorganization, it could include a descriptive procedure for obtaining the required evidence, based on the defined threat model. Therefore, the considerations outlined in Clause 5 remain applicable.

Feedback

  • For each requirement in Clause 5, clearly state the preparation and activities needed to verify it, the verdict, and the evidence needed as per CRA Art 13(22), and provide proper mapping with other Clauses.

Annex A - CRA mapping

This annex describes a mapping between CRA requirements and Technical Requirements.

Feedback

  • Annex A could evolve from an informative-only annex to a compliance-supporting mapping. This would provide significant added value but would require a different approach. For example, a guided threat model (as suggested in Clause 4) would enable a more accurate mapping of requirements - particularly with respect to CRA Article 13(1) and 13(2) and Annex I, Part I (1, 2) - based on applicable threats, asset and capability inventories, attack surfaces, and trust relationships.

Other appendices

The other appendices depend directly on the approach used and contain the mapping between use cases, capabilities, and requirements (B), relationships with other documents (C), risk identification and assessment (D), and risk evaluation (E).

Feedback

  • Using a risk-based approach through threat modeling, we recommend Appendices D and E to explain how to create the base model to define the product profile.

Thank you,

Simone Onofri (W3C, W3C Security Interest Group - Staff Contact)
Giovanni Corti (FBK, W3C Security Interest Group - Invited Expert)
Luca Lumini (Independent, W3C Security Interest Group - Invited Expert)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information