#152·sshx

Blank page when embedded in a cross-origin iframe with third-party storage blocked (unguarded localStorage access)

Author: ManUtopiKCreated Jun 13, 2026Updated Jun 13, 2026

Summary

When an sshx session is embedded in a cross-origin <iframe> and the browser blocks third-party storage/cookies, the app fails to start and renders a blank page. The client appears to read localStorage unconditionally at startup; in that context the access throws and crashes initialization.

Environment

  • Chromium-based browser with third-party cookies/storage blocked (now a common default), or any top-level context with an opaque origin.
  • sshx session embedded via <iframe src="https://sshx.io/s/...#key"> from a different origin.

Steps to reproduce

  1. Serve a page on origin A containing <iframe src="https://sshx.io/s/XXXX#KEY">.
  2. Block third-party cookies/storage in the browser (or embed from a data: URL, which has an opaque origin).
  3. Open the page.

Expected

The "Welcome! — what should we call you?" join screen renders (as it does when third-party storage is allowed).

Actual

Blank iframe. Console shows:

SecurityError: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.

Notes / suggested fix

The site is otherwise iframe-friendly (no X-Frame-Options / CSP frame-ancestors), and it works fine in an iframe when storage is allowed. The only issue is that localStorage (and probably sessionStorage) access isn't guarded. Wrapping storage access in a try/catch with an in-memory fallback — or feature-detecting availability before use — would let the app start (perhaps degrading "remember my name" gracefully) instead of crashing.

Found while embedding sshx in splitr, a split-screen iframe viewer.