ConceptFor engineers

Navi architecture and security

How Navi isolates embedded activities using a separate-origin iframe, scoped cross-origin messaging, and tokenization.

Navi's security model follows from its architecture, so this is the page to give a security reviewer.

  • A CDN loader (navi-loader.js) initializes the SDK and creates iframes.
  • An embedded portal on a separate origin renders activities and handles validation.
  • Backend APIs process submissions and advance care flows.

Because the portal runs on a separate origin, a host page can embed it without reaching into it.

Only three kinds of message cross the iframe boundary

The parent page and the iframe communicate through postMessage, and messages are strictly scoped to:

  • request and response for data collection
  • height and width changes
  • session status and completion

Nothing else crosses the boundary, which keeps the surface small enough to reason about.

An origin allow-list and tokenization keep data out of the parent page

  • Origin allow-list. Messages from an unexpected origin are ignored.
  • Tokenization. Sensitive data is never exposed to the parent page; only tokens and results cross origins.
  • Publishable keys are safe to ship in front-end code, unlike secret keys. See Quickstart.

The parent application never handles the clinical data

Keeping the data out of the parent page reduces what the host application is responsible for, which counts in a compliance review: activities render inside the product without that product becoming a processor of the responses.

Next steps

On this page