Currently Solid pods serve html files which get rendered in the browser. This breaks one base assumption of web security, namely that html files from the same origin are equally trustworthy, and leads to various potential security issues. From my point of view this should be addressed in the specification, to ensure the pods have the same behaviour in this regard.

Security issue

In web security it is assumed that apps on the same origin are equally trustworthy. Many security mechansisms block cross-origin communication and access, but within the same origin apps are less limited. Citing MDN: "The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin.".

Solid pods break the assumption that apps on the same origin are equally trustworthy. I could give someone access to /music/index.html and someone else to /banking/index.html. I do not want someone with access to /music to be able to access my banking details, hence I trust them in different ways. However, they are on the same origin and thus the browser does not prevent access between these apps. Frankly, we throw away the "critical security mechanism".

EDIT: this does not only apply to html files. For instance opening malicious svg files in the browser can execute javascript on the same origin.

Example issues

The following issues arise from the fact that html files on the same pod share the same origin. The first ones require that the user already uses one app (e.g. /banking/index.html) and someone with access to /drawing/index.html creates a malicious app:

1. LocalStorage: this storage is shared within the same origin. The drawing app would be able to access stored data from the banking app.
2. Cookies: By default cookies use SameSite: Lax which means they are not send cross-origin, but are sent on the same origin. Requests from the drawing app would include cookies from the banking app. A real case is this issue where the Drawing would be able to use the NSS session cookies.
3. Iframes: The drawing app can include the banking app as an iframe. As it is same origin, it can access its contents. A real case is this issue where Mashlib accidentically gives html files it displays access to its window.
4. Url history: the url is modifiable as long as the origin stays the same. Thus the drawing app could use window.history.pushState('page2', 'Title', '/banking/index.html'); to trick the user into believing they are looking at the banking app.

The following example does not require any previously used app on the pod, ie it is a security issue even when there are currently no html files on the pod:

1. Service Workers: Service Workers are installed client side and then have control over all the network traffic within their scope. The scope is everything within the same folder or subfolders (eg /foo/serviceWorker.js can intercept requests to /foo/**/*). This can circumvent access control and other pod restrictions.

I’m pretty sure there are other cases, where it could be troublesome that apps of different trust-level are hosted on the same origin.

Example usages

So far I have heard of @josephguillaume that he uses custom html files to add custom extensions to SolidOS (see this issue). He also mentioned other possible usages in this thread: direct use of web components, local add-ons as per the other thread, hosting apps yourself, not having to run a separate server.

There are probably more unknown usages that rely on pods serving html files.

Solution ideas

Following potential solutions were mentioned so far. Note that they are mostly intended as a starting idea, not fully thought through solution proposals.

1. Do not serve html files at all (ie nothing with content-type: text/html)
2. Sandbox html files, for instance with the CSP sandbox header
3. Sanitize html, eg remove javascript (on save or when serving)
4. "placing additional restrictions on where public resources can be stored and how clients are allowed to interact with pods, etc." (by @joachimvh, not sure how this could look like)
5. (EDITED) Add the Content-Disposition: attachment header for all files, to ensure they are downloaded and not rendered in the browser

One thing to note is, that it is not only about html files, but anything that is served as text/html. For instance CSS can serve markdown files as html files with the same security implications.

Related links

• Original discussion: https://forum.solidproject.org/t/is-it-secure-for-pods-to-serve-html-files/6379
• small discussion on CSS: Prevent or sanitise HTML on write by default for unauthenticated users CommunitySolidServer/CommunitySolidServer#1596
• iframe XSS and some html-as-a-feature discussion: IFrame can access mashlibs window causing XSS SolidOS/solid-panes#372