Merge branch 'main_publish' of...

<mark>Editor's Note: Proposal to put together a common term sheet for all verticals developed in CYBER-EUSR.</mark>

Origin: An origin in browser products is the compound of the scheme, host and port of a web resource. When a web resource defined as valid in the user documentation cannot be formed into a meaningful combination of host, scheme and port, the product constructs a synthetic origin uniquely identifying the resource.

Same-origin policy: A security model in browser products used to determine whether assets and state should be shared or not between web page execution contexts.

## 3.2 Symbols

`SIEM  Security Information and Event Management`  

`SIF   Social Interactive Function`  

`SOAR  Security Orchestration Automation and Response`  

`SOP   Same-origin policy`

`TLS   Transport Layer Security`  

`TUF   The Update Framework`  

`UC    Use Case`  

> NOTE: It is proposed that a cross-vertical task force could work on the technical requirements to be included in this clause.

<<<<<<< HEAD

**[REQ-KEV-1]**:The product shall incorporate only components, including third party and open source elements, for which no known exploitable vulnerabilities exist at the time of release. 

Note: The manufacturer may relay on documentation in the form of an Software Bill of Materials (SBOM) as well as reasoning of why known vulnerabilities are not exploitable under the applicable, expected operational environment. 

Note: To demonstrate compliance, the manufacturer may rely on manual security testing (e.g., penetration testing), automated vulnerability scanners, or a combination of both, depending on what is most comprehensive and technically feasible for the product's technology stack.

=======

**[REQ-MEM-KEV-1]**: Web browser interfaces that are, or could potentially be, exposed to untrusted data shall undergo automated dynamic analysis to identify vulnerabilities (for example, via techniques such as fuzzing in an environment that enables the detection of memory access errors).

**[REQ-MEM-KEV-2]** The web browser source code shall undergo automated static analysis to identify vulnerabilities (for example, via LLM code analysis). 

**[REQ-MEM-KEV-3]** The web browser source code shall make use of languages, language features, libraries, and/or automation-enforced coding conventions that prevent well-known classes of vulnerability from being introduced (for example, via the use of memory safe languages, bounds checked container classes, restricting use of raw pointers).

>>>>>>> 6a7b7bab3e517a6c90ccb8c3d916c45d5de3e74f

## 5.3 Secure by default configuration

**[REQ-EXT-AAC-6]**: The product shall ensure isolation between the execution and data contexts of different extensions.

**[REQ-SOP-AAC-1]**: The product shall deny access in one origin to all parts of another origin, except as defined in the user documentation.

Example: Web pages may load images from other origins, message using `window.postMessage` and may access limited properties such as `Location`. Web pages may not access the document object model or global Window scope from scripts of other origins. The user documentation references industry standards with implementation recommendations and additinal examples.

**[REQ-SOP-AAC-2]**: The product shall isolate origin-specific data such as cookies, Web Storage, IndexedDB and any other storage, ensuring it's not available to any other origin, except through protocol-determined methods.

<mark>Editor's note: is this limited to top-level pages?</mark>

<mark>Editor's note: are cookies awkward here? in what way?</mark>

<mark>Editor's note: need to add examples for cross domain storage access is allowed, etc.</mark>

## 5.6 Confidentiality

Proposed ESR code: CON

**[REQ-EXT-CON-1]**: The product shall prevent secrets stored by extensions from being read by other extensions or by web content.

**[REQ-SOP-CON-1]**: The product shall only allow scripts to access the body of a cross-origin HTTP response where the source origin has opted to allow access by the requesting origin.

Example: Implementation of Cross-Origin Resource Sharing (CORS)

**[REQ-SOP-CON-2]**: Where the product allows cross-origin embedding of a resource in documents, the product shall limit information about that resource as specified in the technical documentation.

Example: Cross-origin embedding of the height and width of an image are exposed to scripts, while the contents of the image are not exposed unless CORS is enabled by the source origin of the image.

<mark>Editor's note: In principle, CON-1 might imply CON-2, and maybe we could put this all in assessment steps. Or maybe better to be explicit?</mark>

## 5.7 Integrity

Proposed ESR code: INT

**[REQ-EXT-AP-1]**: The product shall make the best effort to prevent the ability of an extension to make the product unavailable.

**[REQ-ISO-AP-1]**: The product shall take steps to reduce the risk that errors or crashes in one website running in one tab cause other, unrelated tabs to crash.

**[REQ-ISO-AP-2]**: The product shall take steps, on a best-effort basis, to save the state of running websites such that they can be restored later following an incident.

<mark>Editor's note: Need conclusion wrt this being about page state such as scroll position, form data or storage or unspecific or more specific.</mark>

## 5.10 Impact Minimisation

Proposed ESR code: IM

**[REQ-EXT-IM-3]**: The product shall permit extensions to communicate with system webservers when the localhost origin is declared in the extension manifest.

**[REQ-ISO-IM-1]**: The product's technical documentation shall describe all public network protocols implemented by the product, or include references to such protocols. These protocols shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.

<mark>Editor's note: Discussion around this was not concluded. HAS did not like asking for technical docs. Sam raised asking for user docs instead. Andrew suggested that in some circumstances it's not needed at all, eg explicit cooperation between client and server. Daniel E had concerns about lowering the bar even in cooperation contexts.</mark>

## 5.11 Minimisation of Attack Surfaces

Proposed ESR code: MAS

Example: Extensions may bundle assets in their packages, and browsers may allow them provide web pages with access to static assets, such as images, scripts and styles. Extensions declare these assets in their manifest, and browsers restrict access to only the declared assets.

**[REQ-ISO-MAS-1]**: The product's technical documentation shall describe all web-exposed interfaces, or include references to such descriptions. These interfaces shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.

**[REQ-SOP-MAS-1]**: The product shall enforce restrictions from a source origin on how its resources may be used across origins, as defined in the user documentation.

Example: Usage of cross-origin options such as `X-Frame-Options` or `Cross-Origin-Resource-Policy` allow source origins to specify usage constraints for products to receive and enforce.

**[REQ-MEM-MAS-1]** The web browser shall not include unneeded functionality that is, or could potentially be, exposed to untrusted data (for example, shall not expose code implementing an unused file format).

**[REQ-MEM-MAS-2]** The web browser shall validate or otherwise render harmless untrusted data before exposing it to complex parsing functionality implemented in a non-memory safe language, or in a privileged process.

## 5.12 Exploitation Mitigation Mechanisms

Proposed ESR code: EMM

**[REQ-EXT-EMM-2]**: The product shall validate an extension's manifest before installation and update, reject malformed manifests, and ignore unexpected manifest content.

**[REQ-ISO-EMM-1]**: The product shall separate certain product components from each other to reduce the scope of exploits, using process isolation or similar industry standard mitigations.

**[REQ-ISO-EMM-2]**: The product shall isolate different sites from each other, including from side-channel attacks.

**[REQ-ISO-EMM-3]**: The product shall reduce the privileges of its various components with respect to the operating system to the level required to perform their tasks.

**[REQ-MEM-EMM-1]** The web browser shall include assertions to the correctness of program state, which fail safely (for example, an unexploitable crash) when violated (for example, via the use of ASSERT() or CHECK() statements).

**[REQ-MEM-EMM-1]** Portions of the web browser that are not implemented in a memory safe language shall employ mitigations to reduce exploitability of memory safety vulnerabilities (for example, via compiler flags, hardened allocators).

**[REQ-MEM-EMM-1]** The web browser should make use of mitigation technologies provided by the operating system and/or hardware when appropriate  (for example, hardware-assisted memory tagging, ASLR).

**[REQ-MEM-EMM-1]** Web browser processes should only have access to a restricted set of operating system capabilities and privileges as required by their function (e.g. via sandboxing, system call filtering)

<mark>Editor's note: Should sandboxing generally be considered by memory safety, or isolation?</mark>

## 5.13 Logging and Monitoring

Proposed ESR code: LOG