Is It Safe to Host HTML That Runs Its Own JavaScript? · ShareMyPage<br>English<br>Sign inGet started

Someone evaluating ShareMyPage asked the sharpest question we get. You host whatever HTML people upload, JavaScript included, so what stops that code from injecting something, or hijacking a session with a bit of script? It is exactly the right thing to ask. Hosting arbitrary HTML is the entire product, and a lot of that HTML is generated by an AI and pasted in without anyone reading it line by line first. So the honest answer is not "we scrub it clean." It is that we assume every page is hostile and make that assumption not matter.

Why we do not sanitize the HTML

The obvious instinct is to strip anything dangerous out of the upload. We deliberately do not, for two reasons.

The first is that it would break the product. The pages people share here are real pages: dashboards that fetch and chart data, prototypes you can click through, small interactive tools. The JavaScript is the point. Strip it and you are left with a screenshot.

The second is that sanitizing untrusted HTML is a permanent arms race, and the defender loses the day they miss one case. The moment your safety depends on catching every dangerous construct, a single gap is a breach. So we took the opposite approach: run the page exactly as written, but somewhere it can do no harm to you, to us, or to anyone else who opens it.

The whole trick. Instead of trying to make the HTML safe, we make where it runs safe. Nothing about the file has to be trusted.

Every page runs in a sandbox with no origin

A shared page is never rendered directly on the site. It is loaded inside a sandboxed iframe, and the sandbox grants exactly enough for it to be a real page and nothing that would let it reach anyone.

iframe<br>src="{a short-lived signed URL on the content origin}"<br>sandbox="allow-scripts allow-popups allow-forms allow-downloads<br>allow-popups-to-escape-sandbox allow-top-navigation-by-user-activation"<br>referrerpolicy="no-referrer"<br>>iframe><br>What is missing from that sandbox list matters more than what is in it: there is no allow-same-origin. That single omission gives the framed document an opaque, null origin. Its scripts still run, so charts animate and forms submit, but document.cookie comes back empty, localStorage is unavailable, and it cannot read or reach the page that framed it. It is a live page that belongs to no origin at all.

The last two entries, allow-popups-to-escape-sandbox and allow-top-navigation-by-user-activation, are a different kind of permission. They let a person's click reach the outside world, so a "book a call" link or a mailto opens instead of silently failing. They are gated to a genuine user gesture and they govern navigation only, never data. Everything above about cookies, storage, and origin is untouched.

The one rule we never break. allow-scripts and allow-same-origin must never appear together. Combined, they hand the framed scripts a real origin back and quietly undo the entire protection. Keeping those two apart is the load-bearing line.

The page lives on a separate, cookieless origin

The sandbox is the first layer. The second is where the content is served from.

The HTML does not come from the app you sign in to. It is served from a different origin, over a short-lived signed URL, and that origin never sets or reads a cookie. Your login session lives on the app origin. It simply does not exist on the content origin. So even in the hypothetical where a script somehow broke out of the sandbox, there is nothing on that origin to take: no session cookie, no token, no logged-in anything. The comment sitting in our own code says it plainly: even a sandbox escape finds nothing to steal.

We also lock down who is allowed to frame that content to our app alone, so a page cannot be lifted out and reused to dress up a convincing frame somewhere else.

So, injection and session hijacking, directly

Those were the two words in the original question, so here they are, head on.

Injection , the bug usually meant by cross-site scripting, is untrusted HTML executing inside your trusted, cookie-bearing origin, where it can read the DOM and the cookies that belong to you. On ShareMyPage the untrusted HTML never touches that origin. There is no trusted context for it to inject into. It is quarantined by construction, not by inspection.

Session hijacking with JavaScript works by reading a session cookie or token and replaying it. In our sandbox the script has a null origin, so cookie and storage access are gone before it starts. And the origin it runs on carries no session to begin with. Two independent reasons the attack finds nothing to grab.

The worryWhy it does not landScript injection (XSS)The uploaded page never runs on the app origin, so there is no trusted DOM or cookie to inject into.Session hijacking via JSThe null-origin sandbox blocks cookie and storage access, and the content origin holds no session to steal anyway.<br>Layers,...