# Is it secure for pods to serve html files?

**URL:** <https://forum.solidproject.org/t/is-it-secure-for-pods-to-serve-html-files/6379>\
**Category:** Security\
**Created:** [March 16, 2023, 12:06pm UTC](https://forum.solidproject.org/t/is-it-secure-for-pods-to-serve-html-files/6379 "2023-03-16T12:06:00Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![A\_A](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/a_a/32/786_2.png) [@A\_A](https://forum.solidproject.org/u/A_A)\
**Post date:** [March 18, 2023, 9:39am UTC](https://forum.solidproject.org/t/is-it-secure-for-pods-to-serve-html-files/6379/8 "2023-03-18T09:39:03Z")

</div>

I think using SolidOS on a different domain would fix some of the issues for this application, but not resolve the discussion about pods serving/sandboxing html files.

For LocalStorage: Apps running on the pod won’t be able to access SolidOS’s local storage

For Cookies: N/A (It does not set cookies, see below)

For IFrames: Partial fix (see below)

Url history: Apps running on the pod can’t change there url to look SolidOS-ish, as it’s now a different domain

Service Workers: Apps running on the pod won’t be able to create a service worker that interfere with SolidOS on a different domain

Regarding the cookies it is a problem of NSS only. In the [issue here](https://github.com/nodeSolidServer/node-solid-server/issues/1719), NSS sets a session cookie in the login process (nssidp.sid) that will be attached to requests to [solidcommunity.net](http://solidcommunity.net). This will be set regardless from where the login process is started, so it does not matter where SolidOS is served. I previously thought it’s a solution, but I didn’t understand the cookies well enough back then.

Regarding IFrames: It seems to prevent it, **if** there is no content type `!= text/html` that gets executed in the browser. SolidOS has three ways to create iframes: [https://github.com/SolidOS/solid-panes/blob/282a8fe795cb0dd7503ee1e26c59708c041236d0/src/humanReadablePane.js#L103-L121](https://github.com/SolidOS/solid-panes/blob/282a8fe795cb0dd7503ee1e26c59708c041236d0/src/humanReadablePane.js#L103-L121)

1. Files with content type `text/html` will be rendered directly. If SolidOS runs on [github.io](http://github.io), the browser will realize it is cross origin and set the security context accordingly. Thus in this case [the iframe accessing its parent](https://github.com/SolidOS/solid-panes/issues/372) is prevented.
2. Files with `text/markdown` will be sanitized and rendered as markdown, so it should be safe.
3. Files with other content types are manually fetched and the src set with the blob. This is dangerous, as (I think, not tested) the blob has the same origin as SolidOS and thus, if the content is executable, it can access its parent (which is the issue we’d like to prevent). I’m not sure if any mime type `!= text/html` executes in the browser. For instance, I’ve tried `application/vnd.ms-htmlhelp` which sounds like it could be interpreted as html by the browser, but NSS throws a 500 when saving such a file.

> [@A\_A](#):
>
> Anyway, mashlib loads the html files manually, thus it doesn’t really matter if the server would sandbox them. So I think it’s an issue that needs to be discussed mashlib-specific and is independent of sandboxing html files in pods.

These 3 ways of creating iframes also invalidate my statement here. For case 1, if the server sandboxes html it would make a difference.

---

_[View the full topic](https://forum.solidproject.org/t/is-it-secure-for-pods-to-serve-html-files/6379)._
