Security

NDWeb is the browser interface to your organization’s data, but it is never where access decisions actually get made. This page covers how sign-in and sessions work, and why that distinction matters.

Interactive login

Signing in to NDWeb is a standard interactive login: an Authorization Code flow with PKCE, the same pattern used across modern web applications, rather than any custom password-handling logic in NetDefense itself. There’s nothing proprietary to trust here — it’s a well-understood, widely audited flow.

Where your session lives

Once you’re signed in, the session token lives in browser memory only — it is never written to localStorage, sessionStorage, or a cookie. That closes off an entire class of attack: script injected into the page (via a compromised dependency, a browser extension, or an XSS bug elsewhere) can’t read a token out of storage, because there’s no storage to read it from. The tradeoff is that a hard page refresh clears the in-memory token, at which point NDWeb transparently re-establishes your session — a deliberate choice, not an oversight.

Session renewal uses single-use, rotating refresh tokens: each refresh consumes the previous token and issues a new one, so a captured refresh token is only ever valid until its next legitimate use. This happens silently in the background; you shouldn’t notice it happening at all during normal use.

Browser-level hardening

NDWeb ships with strict browser security policies by default: HTTPS is enforced and preloaded (no unencrypted fallback the browser will accept), the app cannot be embedded in another page’s frame, and a strict content-security policy blocks inline and eval-based script execution — the categories of script that are hardest to audit and most commonly abused in injection attacks. None of this is configurable per-deployment; it’s baked into how the app is served.

A static app with no server to compromise

NDWeb itself ships as static files served from a CDN. There is no server-side session store to leak, no session database to compromise — the app has no backend of its own at all. Every action you take in the UI — viewing a device, editing a snippet, triggering a sync — is a bearer-token-authenticated API call to the control plane, and the control plane enforces every permission check server-side, independent of what the browser UI shows or hides.

That last point is worth being explicit about: the UI hiding a button or graying out a control for a Read-Only member is a convenience, not a security boundary. The actual boundary is enforced by the API on every request, using the same organization roles whether the request came from NDWeb, NDCLI, or the MCP server. A modified or instrumented client gets exactly the same server-side enforcement a normal browser session does.

See also

• Accounts & Organizations — roles and what each one can do.
• Personal Access Tokens — the equivalent token model for headless/CI use.
• Security — the full model, including the device-side and control-channel guarantees.