W3C Workshop Secure the Web Forward

Driving developer awareness and adoption of Web security standards & practices

September 26-28, 2023 - Virtual

Presented by W3C, OpenSSF, OWASP, OpenJS

Parsoa Khorsand


Table of contents

See also:

Executive summary

In coordination with OpenSSF, OWASP and OpenJS, W3C organized the Secure the Web Forward workshop on 26-28 September 2023, through a series of three online sessions, to review the state of technologies (existing, in development, or proposed), guidelines, tools, and documentation available to developers to secure applications deployed on the web, and coordinate relevant activities.

About 30 people attended the live sessions to discuss the 9 selected position papers along 3 different themes: supply chain security (including SBOMs), JavaScript security, and developer awareness. Participants acknowledged the growing complexity of web applications and of security related web technologies (e.g., CORS, CSP), which together makes it challenging for developers to secure applications. The main outcomes are that:

  • The use of SBOMs, which some regulations may require, could help developers keep track of security vulnerabilities.
  • A verification mechanism, such as the Source Code Transparency proposal, would allow browsers to validate that the application resources received match the resources advertised by the application developer in a web bundle or an SBOM and possibly analyzed by security researchers.
  • In parallel, JavaScript execution could be split in Compartments to isolate third party code and keep their power under control. Making this foolproof with the design of the DOM API remains a challenge.
  • Additionally, same origin realms can be manipulated by an attacker against the web application itself when they are not properly handled. Web applications should have the ability to control, at load time, how the potentially untrusted code they contain can create or access same origin realms.
  • Cookies are another source of security vulnerabilities. The deprecation of third party cookies creates a unique opportunity to revise the defaults of the cookies model for the web for increased security.
  • Regardless of technical solutions, a documentation effort is warranted: tutorials, how-tos, references, guides and best practices, targeted at developers as well as policy makers.

On top of progressing technical topics mentioned above, one of the suggested next steps is to initiate an activity, possibly hosted within a W3C Community Group, set to take a holistic approach to security and coordinate collaborations with other organizations (OpenSSF, OWASP, OpenJS, Open Web Docs, MDN, IETF, etc.). This activity could start by documenting threat models on the web and formulating end-user stories related to security to inform standardization groups, developers, and policy makers.


W3C holds workshops to discuss an aspect of the web platform from a wide variety of informed points of view, identify needs that could warrant standardization efforts, at W3C or elsewhere, and assess support and priorities among relevant communities.

The main goals of the Secure the Web Workshop were to review the state of technologies (existing, in development, or proposed), guidelines, tools, and documentation available to developers to secure applications deployed on the web, and coordinate activities and possible improvements in that space.

The workshop kicked off with a call for position papers in June 2023, which led to the publication of 9 position papers in August 2023, categorized in three main themes: supply chain security (including SBOMs), JavaScript security, and developer awareness.

Two informal meet-ups were held in preparation of the workshop in September 2023 in Spain: at W3C's TPAC event in Seville, and at the Open Source Summit Europe event in Bilbao. Three live sessions were then held on 26-28 September 2023 to discuss the themes and position papers. 30 people joined the live sessions. Recordings of paper presentations and meeting notes are available.

This report summarizes topics discussed during the live sessions and proposes next steps.

Setting the context

As input to the workshop, in collaboration with the WebDX Community Group and thanks to the support of the Mozilla MDN team, the program committee ran a short survey on MDN (visited monthly by 18M developers) in May 2023 to gather data on how developers handle security challenges for their web applications. 297 developers responded to the survey. An interpretation of the results is available.

On average, 60% of developers rated the security aspects as somewhat challenging or very challenging, while only 17% of developers rated them as easy or very easy. Also, all security aspects, save HTTP Configuration (only 45%), were rated by respondents with a majority of challenging or very challenging responses:

  • Detecting security vulnerabilities (71%)
  • Understanding security threat (69%)
  • Understanding the Browser Security Model (67%)
  • Safely Integrating Third Party Services (55%)
  • Keeping Frameworks and Libraries Up-to-Date (54%)

Overall, these responses suggest a clear need for better education, tools, and best practices to assist developers in detecting and preventing security vulnerabilities in their development workflows.

The workshop was organized to explore these aspects and answer the following questions:

  • How to bring the secure software supply chain approach to the web development community?
  • What guidance might be needed for web developers who work at different levels of the stack?
  • How to make web security technologies easier to use and adopt?
  • How can open source software focused efforts better support web developers?
  • How can open source software review processes serve as inspiration for review of new web specifications?

Topics discussed during the live sessions

Supply Chain Security

The first live session was focused on mechanisms used to describe, track, and verify the software supply chain of web applications.

The concept of a Software Bill of Materials (SBOM) is directly derived from bills of materials used in the manufacturing industry. A SBOM lists all the libraries, tools, and processes used to build and deploy a piece of software. Formats such as SPDX and CycloneDX may be used to formalize components of an application into an SBOM. The more trustworthy an SBOM is, the more useful it is to identify supply chain risks.

The idea is to get the list of ingredients of your software that you are actually shipping and run an analysis on it like issue or security to find known security issues with those components that you ship, that you actually depended on somehow. Or just to identify that you need to get rid of some supply chain risks.
– Jan Kowalleck

One challenge is that software, especially open source software, can grow in size and complexity quickly, and include various components that are not under the control of the company developing the software. In the native world, package managers are often used to track code dependencies. Package managers remain relatively uncommon on the web though: web applications rather link directly to third party libraries, or integrate them in a build through ad hoc processes. This makes it easy to lose track of atomic components.

For SBOMs to be useful as security manifests on the web, they need to be progressively adopted throughout the ecosystem: by developers of open source software, by compilers and build tools, by package managers, and by browsers. Existing and upcoming regulations that require SBOMs may help push this adoption.

Some improvements could help. For instance, SBOM discovery is not widely available, leading to data being duplicated over and over again. There also needs to be convergence on SBOM vocabularies.

Today, we have a number of producers of software, whether they're projects and open source commercial software providers. [...] Each of these are somewhat independent documents and they have a huge amount of overlapping data, because they describe their entire dependency tree. And in that description of the dependency tree, they're basically copying the same data over and over and over again.
– Gary O'Neall

SBOMs are declarative in essence and there are lots of ways to end up with tampered data on the web that would reduce the usefulness of SBOMs. Daniel Huygens introduced a different, and complementary, approach, named Source Code Transparency, that would allow anyone to check the source code of a web application that is actually delivered to end users. The idea would be for application developers to publish a hash of the source code in a transparency log, which browsers can then check to ensure that everyone gets the same code and that auditors can check with the help of reproducible builds.

How would we [provide source code transparency]? One concrete way to do this would be to create a signed web bundle of all the resources in the web app. This is also an existing proposal in the W3C. And when you create that you could send a hash of this web bundle to the source code transparency log [...] Such that a browser can check: Okay, the hash that I receive or the hash of the web bundle that I receive is included in this source code transparency log, therefore, security research researchers will also see it and it's the correct source code for this web bundle.
– Daniel Huigens

JavaScript Security

The second live session discussed mechanisms to harden web applications over potentially untrusted code that they may integrate: mechanisms to isolate such code from the rest of the application, as well as mechanisms to give applications control over code access to powerful capabilities. The session also explored the central role of third-party cookies in client-side isolation bypasses on the web and the opportunity created by the deprecation of third-party cookies to re-think the security model for cookies on the web.

Hardening JavaScript

The same-origin policy that underpins security on the web has proved very useful at isolating applications from other applications. That said, web applications are now often composed into JavaScript bundles from multiple third-party sources that run in the same context and with the same access rights as the code that the application developer actually wrote.

There's someone in my code base, and I don't trust them. And we invented "hoping for the best". That's not entirely true, but pretty factual if you worked on projects that were building front-end out of components from npm.
– Zbyszek Tenerowicz

The JavaScript Compartments proposal takes an approach similar to module loading in WebAssembly, allowing to isolate a JavaScript module from some potentially untrusted party within the same realm, and controlling which globals (and functions) that module has access to. A couple of problems remain though:

  1. Due to the structure of the DOM, giving access to any part of the DOM essentially leaks the global window object. The same is true for a number of web APIs which provide hooks into the global window object one way or the other.
  2. Various mechanisms can create another same-origin JavaScript realm within a realm. These creation mechanisms are not always explicitly described as such in specifications, and are sometimes linked to browser internals. This makes it hard to protect a realm, and relatively easy for malicious code to bypass protection measures, which may also result in leakage of unprotected global objects and powerful capabilities.

There are so many ways to create same origin realms, and we don't have the information from the browser to tell when these same origin realms are being created. So virtualizing it is really complicated, and the community managed to show us a lot of security gaps throughout the years in this [JavaScript shim] scenario.
– Gal Weizman

In parallel to the work on the Compartments proposal within TC39, work could perhaps take place in W3C to define additional CSP directives for allowing Compartments or the integration of new realm detection, review and propose APIs or API configurations to prevent them from leaking globals and thus:

  1. Prevent code from escaping their compartment (e.g., building on the experience of past attempts at creating a membrane for the DOM such as the Caja project; or creating an API for islands in the DOM that would not allow reaching up via parent, ownerDocument etc.)
  2. Prevent code from obtaining access to powerful capabilities the application attempts to deny (e.g. building on the experience of current attempts to virtualize security for same origin realms such as the Snow project).

There are also opportunities to work on tools for package managers and bundlers to ease the burden on developers.

The overall goals are to give application developers:

  1. The ability to plot the border between the code they trust and want to empower, and the code they need for some reason but would prefer not to trust with the whole application state and powers.
  2. The ability to mitigate powerful features accessible at runtime to third party code that's integrated into the app for when such a border cannot be drawn.
Establishing a robust long-term security model for cookies on the web

Third-party cookies are progressively going away on the web. This move is primarily driven by privacy-related considerations. Security-wise, third-party cookies are also at the root of a number of client-side isolation bypasses on the web. This move may partially break some existing content. As such, it provides a good opportunity to re-think the security model for cookies on the web and to get back to more secure defaults.

A good security goal could be to adopt the same functionality as that provided by the Set-Cookie "SameSite=Lax" HTTP directive by having web browsers switch to the "Lax-Allowing-Unsafe" enforcement model by default, and to complete that model with a set of rules to handle remaining under-defined behaviors.

If we do this right, and if we also make this a security boundary, then we will really make life easier for developers in the future, by removing these classes of bugs that have plagued web applications for a couple of decades
– Artur Janc

Developer Awareness

The focus of the third live session was on documentation efforts to improve the awareness of web application developers about security issues, mechanisms, risks and mitigations.

The web platform comes with a strong security model to prevent things from going away. That said, security defaults date back from the inception of the web, and application developers need to manipulate and understand complex security features (e.g., CORS, CSP, SRI, cross-origin isolation) to meet stronger security requirements in 2023.

In parallel, while various efforts have been made at documenting threat models in software in general, the particularities of the web platform are not explicitly documented. This leaves developers wondering what areas to prioritize. Documentation platforms do not have a clear understanding of where they should focus their efforts either.

The huge difference between software run in the browser and software run elsewhere is the browser sandbox. There's a whole security model that is there to protect and prevent things from going really bad in a browser, and in Javascript land in the browser. And so it begs the question as to what exactly does it mean to secure something like jQuery? What hole can jQuery open in the sandbox that doesn't exist without jQuery?
– Tobie Langel

The short survey ran in preparation for the workshop provided initial insights, but there may be a need to go deeper into details, e.g., by running interviews with developers on web security topics they struggle with.

But what we really need from security people like all of you, is review and advice and help on creating content outlines. And we also need insights into what developers don't understand.
– Florian Scholz

Web application developers have to understand and handle security. If they don't, no one else will! Documentation plays a crucial role in understanding threats and defense mechanisms. In the workshop, it was suggested that it might be helpful to have a consistent way for reference documentation to indicate the security requirements for calling particular Web APIs: for example, whether the API requires a secure context, user activation, or a specific permission. Positive feedback during the workshop prompted renewed discussions on the topic on MDN along with a new proposal for how these requirements might be defined. Some of these requirements might be derivable from the specifications themselves (and e.g., included in Webref data), which would ease maintenance and improve the accuracy of reference pages.

Past experiences with security regulations that touched on web features (such as cookies or GDPR) show that it is important to inform policy makers as early and as clearly as possible. Web security experts have the ability to tell the story from an end user perspective, which is something that policy makers are keen on hearing. Also, once referenced from regulations, best practices tend to provide legal protection, which in turn reinforces their adoption by tools and developers.

This suggests a concerted effort between relevant organizations to address the dimensions mentioned above (best practices, list of threat models, documentation of defense mechanisms, documentation of end user impacts, information for policy makers). Some efforts are already underway, e.g., in the OpenJS Foundation to adapt security best practices to web application contexts. Organizations represented at the workshop have complementary expertise. Collaboration would help achieve a more holistic approach and amplify the impact of individual outcomes.

[The security framework project] is a collection of best practices that we're developing for our projects. [...] First up is customizing OpenSSF and OWASP best practices. If you've gone through any of the OpenSSF badging stuff, some of that stuff is not 100% applicable to a web project, or a JavaScript project. [...] We're also looking to create a free Javascript training and courses as part of our effort [...] How can we amplify the work that we're doing in the community to have more impact?
– Ben Sternthal

Next steps

Workshop participants started to discuss possible next steps. This section builds on this discussion and attempts to propose actions for the immediate future. These suggested steps come with no guarantee: progress on most of them depends on further discussions among interested parties and actual time investment from people to do the work! If you are interested, please send an email to the program committee to group-secure-the-web-forward-ws@w3.org, raise an issue on the GitHub repository for the workshop, and/or join the #security channel of the W3C Community Slack instance (if not already done, you will need to sign up for the Slack instance first).


JavaScript Compartments, sanitization of web APIs and same origin realms enforcement APIs

The Compartments proposal, currently at stage 1 in the TC39 group, was raised in the workshop as a solid foundation to isolate portions of code in a web application within a JavaScript realm. The proposal follows the same approach as the one used in WebAssembly, where modules need to be given explicit access to any external functionality.

The proposal may need to be completed with sanitization work in W3C to provide stronger isolation guarantees in a web context, as it is easy to leak full access to globals (e.g., any access to the DOM leaks window), or mechanisms that allow code to create additional realms and bypass encapsulation/protection. This work could also lead to new CSP directives being proposed to the Web Application Security Working Group or to new API proposals submitted to the Web Platform Incubator Community Group to give web applications greater control over potentially untrusted code.

While technical in essence, this effort should start with a formulation of the end-user scenarios that need to be addressed, and an evaluation of directions that may be worth pursuing.

Supply chain technologies

SBOMs will play a growing role in evaluating and tracking security issues within a web application, possibly driven by regulations. The generation of SBOMs needs to be automated and integrated throughout the ecosystem: package managers, compilers, open source projects, browsers. This will be a broad and long-lasting effort. A cross-organization group, as proposed below, could monitor and coordinate actions to promote the use of SBOMs on the web.

Some updates to existing standards may be warranted. The SBOM Discovery proposal raised during the workshop was published as RFC 9472 by IETF shortly after the workshop (October 2023), and should help reduce the duplication of SBOM data. Alignment on SBOM vocabularies may also be beneficial.

In itself, an SBOM does not provide any guarantee that the application that a user is browsing matches the description set forth in an associated SBOM. The Source Code Transparency proposal presented during the workshop describes a possible solution in this space that could be worth standardizing. The proposal was submitted to the Web Platform Incubator Community Group shortly after the workshop. If the proposal continues to build on top of Web Bundles, the standardization status and cross-browser support for Web Bundles needs to be looked into as well.


Regarding cookies, the takeaway from the workshop is that the deprecation of third-party cookies creates a unique opportunity for revisiting same-origin cookie defaults for security reasons.

There have been lots of discussions on privacy-forward technologies and standards which support and evolve use cases that, until this point, have been dependent on third-party cookies and other tracking mechanisms. These discussions led to a proposed Private Advertising Technology Working Group Charter, currently under review at W3C.

There are also proposals under discussion in the W3C Privacy Community Group on mechanisms that may be needed to avoid breaking existing content when third-party cookies get dropped.

These discussions are driven by privacy considerations. That said, security overlaps with privacy, and it seems a good idea to seek further alignment on a new robust and secure model for cookies on the web in the Privacy Community Group and the Web Application Security Working Group. The current plan, outlined in the Technical Architecture Group (TAG) review request, is to publish a Working Group Note within the Web Application Security Working Group on the security aspects of third-party cookie deprecation to build consensus on the new model before actual changes get brought to the relevant specifications (HTML, Fetch, Cookies).

Documentation and guidelines

There was general consensus at the workshop that documentation plays a major role in promoting security best practices and in helping web application developers understand security threats and mechanisms at their disposal. This is particularly true on the web as security requirements have drastically evolved since the platform was created, requiring developers to understand and set additional directives (e.g., CORS, CSP, SRI) to override default security settings and create a more secure web application.

MDN is a natural home for documentation targeted at web application developers. Possible work items for Open Web Docs from the workshop to guide their contributions to MDN related to security aspects include:

Discussions on Web standardization efforts start from end users scenarios. Documenting these user stories for security would help prioritize actions and the development of suitable best practices and guidelines for developers. It would also help inform policy makers developing regulations about the ins and outs of security in web technologies. See next section for a concrete proposal to organize the work.

A companion effort to document threat models on the web seems warranted as well, to provide a reference document that could inform web application developers, but also standardization groups, documentation platforms, and policy makers.

The OpenSSF operates a Best Practices working group which develops guides and educational material. There may be an opportunity to do some joint work with that working group to develop further such material aimed specifically at web developers.

Towards a holistic approach to security

As web applications grow in complexity, so do security issues that web application developers need to handle. A major takeaway from the workshop is the need to take a holistic approach to educate, empower, and guide the entire ecosystem on security issues, best practices, threat models, and available measures.

Such a holistic approach requires active collaboration between organizations. This collaboration should start with the organizations represented at the workshop: W3C, the Open Source Security Foundation (OpenSSF), the Open Worldwide Application Security Project (OWASP) Foundation, and the OpenJS Foundation. It should also include other relevant groups and work such as the Supply Chain Integrity, Transparency, and Trust (scitt) Working Group at IETF, SPDX within the Linux Foundation, Open Web Docs and MDN.

The collaboration should leverage respective expertise from organizations: expertise on security best practices for OWASP and OpenSSF, expertise on open source JavaScript projects for the OpenJS Foundation, expertise on web technologies for W3C, and expertise on writing documentation for Open Web Docs and MDN.

W3C used to have a forum for discussions on improving standards and implementations to advance the security of the Web, but the Web Security Interest Group was closed at the end of 2019. The workshop may signal the need to re-instantiate a similar forum, perhaps through the creation of a Community Group dedicated to security topics, open to all.

Actions in scope of this Community Group could include:

  • Document threat models on the web.
  • Formulate end-user stories related to security to inform groups developing technical APIs and policy makers developing regulations.
  • Align security best practices targeted at web applications.
  • Review possible directions to sanitize web APIs for use in isolated contexts (compartments).
  • Track specifications and vendor implementations related to security.
  • Recommend new specifications to be produced and find group homes for them.
  • Clarify documentation needs to inform documentation writers.
  • Track and promote software supply chain approaches to ease security assessments.
  • Coordinate actions on the above points with external organizations.

Progress on this proposal is tracked in a GitHub issue. Interested parties may also join the #security channel on the W3C Community Slack instance.

Thank you!

The organizers express deep gratitude to those who helped with the organization and execution of the workshop, starting with the members of the Program Committee who provided initial support and helped shape the workshop. Huge kudos to those who not only took the time to submit position papers as input to the workshop, but also prepared top-notch presentations to initiate discussions during the live sessions (presentations were recorded and are available from the position papers page). Thanks to the Mozilla MDN team for allowing us to run a developer survey and to W3C WebDX Community Group participants for reviewing the survey. Many thanks to Marie-Claire Forgue for editing the videos after the workshop and to those who took an active role under the hood. Finally, a big thank you to workshop participants for their active and constructive role during the live sessions, which contributed to a productive and inspiring event!