Solid Security Considerations

Draft Community Group Report,

More details about this document
This version:
Editor's Draft:
Feb 20, 2024
22 June 2024
Issue Tracking:
elf Pavlik

Copyright © 2024 the Contributors to the Solid Security Considerations, published by the Solid Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.


This document describes a few issues related to security in the Solid ecosystem.

Status of this document

This report was published by the Solid Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Attacks and Mitigations

1.1. Solid OIDC


solid/security-considerations/3Document attacks possible when WebID Document is hosted in a Solid Storage
solid/security-considerations/4Document attacks possible when hosting Soild-OIDC Provider on the same origin as storages
solid/security-considerations/5Document attacks possible when Solid-OIDC issuer is compromised
solid/security-considerations/6Document possible phishing attacks during authentication with Solid-OIDC

1.2. Serving user-created files

When Solid Servers [Solid.Protocol] serve files created by different users, they break the common Web assumption that files and/or applications served within the same origin are automatically equally trustworthy.

An attacker could be any agent — human, browser, browser-based application, etc. — with a WebID. They need append/write access to the user’s server to store a malicious HTML file. They might have this access because the user had allowed them to write a blog post, or because they have their own storage in a different path on the same domain, among other possibilities.

Impact of the scenario: The attacker, pretending to be the victim, can access anything that the victim’s account can access.

1.2.1. Use Solid-OIDC DPoP-bound ID tokens to make authenticated requests

If a user is logged in to an application hosted on the Solid server, a malicious application on the same Solid server could abuse this login to make authenticated requests. Here we use [SolidOS] as an example of a benign application. Prerequisites Attack

The attacker writes a malicious text/html file to the server. When this file is opened by the user:

  1. It opens [SolidOS] in a new tab and saves the window reference. (If the writer of this document recalls correctly, opening any non-existent resource from the server returns [SolidOS].)

  2. [SolidOS] automatically logs in, as the user who logged in there previously.

  3. The text/html file can access [SolidOS] via the window reference, including performing authenticated fetch.

  4. The text/html file can make any request in the name of the currently logged-in user, through this authenticated fetch.

1.2.2. Steal login credentials

If a user saves credentials for an application on the same site as the Solid server, a malicious application could steal these credentials. Prerequisites Attack

The attacker writes a malicious text/html file to the server. Depending on the tool used to store the login credentials, the actual autofill/suggestion behaviour can vary. For instance, if a user who saved login credentials with Chrome opens the malicious file:

  1. The victim performs any interaction with the site (e.g., clicking on a cookie banner).

  2. Chrome automatically fills in <input> fields for the user name and password with the saved credentials.

  3. The malicious text/html file can read and send the credentials to the attacker.

  4. The attacker can use the credentials to log in with the IDP of the victim.

1.2.3. Countermeasures Considerations

Servers are strongly encouraged to consider the countermeasures in the context of the use cases they want to enable or disable on a given storage. For instance, using Content-Security-Policy: sandbox will universally prohibit various functionalities for applications, including but not limited to accessing local storage, executing scripts, using forms, interacting with plugins, or including external content. This broad range of restrictions may not be desirable for various categories of applications that rely on client-side storage mechanisms, collaborative features, or dynamic content interaction.

1.3. Protecting WebID Document

Solid access policy enforcement relies heavily on the identities of agents. Requesting Parties are identified by [WebID] and applications by ClientID [Solid.OIDC]. A User’s WebID Document includes trust anchors, like designation of their [Solid.OIDC] Provider (also known as _issuer_). In other approaches, public keys could be published or discoverable via the user’s WebID Document.

1.3.1. Fully impersonate the user

If a malicious app can write or append to the user’s WebID Document, it could inject trust anchors, allowing complete impersonation. Exploit Prerequisites Attack

1.3.2. Countermeasures

solid/security-considerations/9initial WebID Document considerations


Informative References

Joachim Van Herwegen. Community Solid Server. URL:
Aaron Coburn; elf Pavlik; Dmitri Zagidulin. Solid OIDC. URL:
Sarven Capadisli; Tim Berners-Lee; Kjetil Kjernsmo. Solid Protocol. URL:
SolidOS Team. SolidOS. URL:
Andrei Sambra; Henry Story; Tim Berners-Lee. WebID 1.0. URL: