W3C Workshop Secure the Web Forward

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.

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

Technologies

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:

• Create guidelines for documenting security requirements consistently in MDN reference pages. See also a proposal for how these requirements might be defined.
• Organize a follow-up workshop to develop a content outline for structured documentation on web security including the four quadrants of documentation (tutorials, how-tos, guides, reference).
• Get more insights into developer needs and misunderstandings in the web security field (maybe through additional surveys or user interviews).

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.