renza

Security

Renza hosts arbitrary HTML and arbitrary JavaScript made by anyone. That makes isolation the foundation the whole product sits on, not a feature bolted on top. The core rule: untrusted content is the guest, never the host. The artifact goes in the box; Renza's trusted chrome stays around it.

The origin split

Untrusted artifacts are served from a separate registrable domain — renzausercontent.com — never a subdomain of the app origin. This is the load-bearing decision:

  • The trusted app and authentication live on the Renza app origin.
  • Each artifact renders on its own per-artifact host, isolated from the app and from every other artifact.
  • Because the content domain is a different registrable domain, app-scoped session cookies are unreachable from inside an artifact. A malicious deck can't read your session.

The sandboxed iframe and the bridge

Artifacts render in a cross-origin iframe with sandbox="allow-scripts" and a strict CSP — no auth cookies reachable, no access to the parent page.

A cross-origin iframe is opaque both ways, which is exactly the boundary we want — and also what would block the comment and highlight layer. Renza resolves this with a thin postMessage bridge injected into the wrapper it serves. The bridge runs inside the iframe and does three things only:

  1. Measures element geometry and text ranges, so comments can anchor.
  2. Applies highlights and edit mutations to the iframe DOM.
  3. Talks to the parent over postMessage, carrying geometry and edit operations — never tokens, never privileged calls.

All comment UI, identity, and privileged API calls render parent-side, positioned over the iframe using the geometry the bridge reports. The artifact can never reach them.

The mental model is Stripe Elements inverted. Stripe iframes the sensitive thing so your page can't touch it; Renza iframes the untrusted thing so it can't touch the app. Whichever side is the risk goes in the box, and a thin postMessage channel is the only door.

Private artifacts and assets

Hosting private documents means the HTML and every asset — images, video, fonts, local files — is reachable only by authorized viewers. "Put your images on a public CDN" is incompatible with the product, so private media is a core feature.

  • Private at rest. Artifact bytes live in a private object store, read only server-side by the content origin — never a public bucket URL.
  • Capability-gated serving. The trusted parent — the only side that knows the viewer's identity and permission — mints a short-lived, revocable capability and frames the artifact at <capability>.renzausercontent.com. Every relative asset request goes to the same capability host, so assets inherit the same authorization automatically — no per-asset signing, no URL rewriting, even for URLs the deck builds at runtime in JS.
  • Revocable by construction. The capability is an opaque lookup key, not a self-contained token. Revoke by deleting the mapping; expire with a TTL.

Unspoofable chrome, not content policing

A sandboxed artifact can still paint a fake "Renza login" inside its box. Renza does not try to solve this by moderating content — that lever is trivially evaded and over-broad. Instead the trusted chrome is made unspoofable: a consistent frame around the artifact, a "rendered content" label, and a mono host indicator showing the real content origin (xyz.renzausercontent.com). The lesson it teaches every user: inside the box is the document; Renza's real controls are always outside it.

Data handling

All traffic between browsers, the API, and the content origin is encrypted in transit with TLS. At rest, metadata lives in Postgres (Neon) and artifact bytes in a private object store — both encrypt stored data by default, and nothing is ever served from a public bucket.

Governance

As a team's use of Renza grows, so do the controls available to govern it:

  • Roles and grants — per-person access at viewer / commenter / editor.
  • Version history as an audit trail — who changed what, when, with rollback.
  • SSO and SCIM — Google sign-in on Renza Pro; SAML SSO and SCIM directory sync on Enterprise.
  • Audit logs and log streaming, BYO storage with encryption controls, data residency, and a trust centre with a diligence pack and DPA — on Enterprise.

See Pricing for which controls land on which plan.

Reporting a vulnerability

Renza hosts untrusted HTML on purpose, so we expect — and welcome — security research. If you find a vulnerability, email security@renza.io with enough detail to reproduce it. We read every report. Good-faith research is welcome: please avoid accessing other users' data, and give us reasonable time to fix before public disclosure. Our machine-readable contact record lives at /.well-known/security.txt.