Secure browser document workflows

SuperDoc runs document editing in the browser. That improves data locality, but it does not make every integration private or make client code a trusted authorization boundary.

Identify every data boundary

• A URL document is fetched by the browser from its origin.
• A local File or Blob stays in browser memory until application code sends or persists it.
• Exported bytes remain local unless downloaded, uploaded, cached, or passed to another API.
• Collaboration providers transmit document updates and awareness data.
• Network proofing, AI, telemetry, logging, and upload handlers may transmit document content or metadata.

Publish this behavior in product privacy language. Minimize data, retention, and logs. Never log document bodies, clauses, comment text, credentials, signed URLs, or mutation payloads by default.

Keep trusted decisions on trusted services

Document mode, disabled buttons, permission resolvers, read-only comments, and hidden review controls guide normal browser interaction. They do not enforce access against a user who controls the browser. Authenticate document requests and enforce read, write, export, collaboration, and agent approval policy on trusted services.

Treat names and emails supplied in user as display identity unless they came from an authenticated application session. Validate uploaded DOCX files, set size and timeout limits, and isolate sensitive processing where your threat model requires it.

Configure the browser boundary

Use HTTPS, restrictive CORS, and a Content Security Policy that permits only the scripts, workers, connections, images, and fonts your deployment needs. Avoid unversioned third-party runtime dependencies, and decide whether Editor assets are self-hosted before production.

Pass a nonce to runtime styles

Leave cspNonce unset unless the page's CSP requires a nonce for <style> elements. SuperDoc creates layout and caret styles at runtime. The browser blocks those styles when their nonce does not match the page's policy.

Generate a nonce for each HTML response. Include it in the response policy and pass the same value to every SuperDoc Editor mounted in that browser document, including remounts. The relevant policy directives look like this:

Content-Security-Policy: style-src-elem 'self' 'nonce-{response-nonce}'; style-src-attr 'unsafe-inline'

Pass the server-provided value when you create the Editor:

function createEditor(file: File, responseNonce: string) {
  return new SuperDoc({
    selector: '#editor',
    document: file,
    cspNonce: responseNonce,
  });
}

cspNonce applies only to SuperDoc's runtime <style> elements. It does not configure CSP, authorize scripts or workers, or apply to styles created by your application. SuperDoc uses inline style attributes for document layout, so account for them in style-src-attr. For a custom theme, use buildTheme() and inject its CSS with the same nonce.

In the deployed application, confirm that the browser reports no style-src violations and that SuperDoc runtime <style> elements carry the response nonce.