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.
Navi has a CDN loader, an embedded portal and backend APIs
- 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
- Sessions and JWTs for how access is granted.
- Administer & secure for organization-level security.