Introducing the OpenZiti Browser SDK – embedded zero-trust for web apps
The Problem
Modern single-page applications (SPAs) run entirely in the browser. Every click, every update, every dashboard refresh — it all happens through JavaScript, making API calls directly to backend services.
That architecture is fast and elegant. But there’s a catch: SPAs can only talk to APIs that are reachable from the public internet. Once you expose those APIs, you inherit every modern attack vector — scanning, credential stuffing, API key theft, and more.
Traditional defenses like WAFs, IP whitelists, or OAuth2 help, but they don’t eliminate exposure. You still have something listening on the open internet.
In short: SPAs are easy to build, but hard to secure — unless you can make their backend APIs completely invisible.
The Traditional Options (and Their Gaps)
| Approach | Pros | Cons |
| WAF / API Gateway | Easy to integrate | Still exposes endpoints publicly |
| VPN / Tunneler | Keeps APIs private | Requires client install; poor UX |
| Reverse Proxy | Simplifies routing | Adds attack surface |
| Zero-Trust Broker | Policy-based access | Doesn’t embed directly in app; often opaque or costly |
SPA Developers and operations teams need something that:
- Keeps APIs off the internet
- Doesn’t require installing a tunneler
- Works natively from the browser
- Supports modern identity and policy models
The NetFoundry Approach
OpenZiti is an open-source, zero-trust overlay network technology, developed by NetFoundry, that embeds secure connectivity directly into applications. Instead of building a perimeter around your network, you bring zero-trust into the app itself.
Connections are mutually authenticated, encrypted, and policy-controlled. No open inbound ports. No VPNs. No public exposure.
For those unfamiliar, NetFoundry provides a cloud-managed service built on OpenZiti — adding:
- Hosted, dedicated, private overlays
- Automated provisioning and lifecycle management
- Deep telemetry and observability
- Compliance options (FIPS, HIPAA, NIST, PCI, NERC CIP)
- Hybrid/air-gapped deployment flexibility
- Enterprise performance, integrations, features, SLAs, and support
And now, a way to extend all of that directly into the browser.
Introducing the OpenZiti Browser SDK
As we modernized our NetFoundry cloud-managed service from a multi-page app (MPA) to a single-page app (SPA), we faced a challenge: how to let the SPA securely call protected management APIs without exposing them to the internet.
Running a local tunneler would have worked — but that’s friction for users.
So we built and open-sourced the @openziti/ziti-sdk-browser, an SDK that brings OpenZiti’s zero-trust connectivity directly into web apps.
This SDK:
- Authenticates with the OpenZiti Controller
- Negotiates an ephemeral x509 certificate
- Establishes a mutual TLS (mTLS) connection
- Routes HTTPS requests securely over the OpenZiti network
All without exposing any backend to the public internet or requiring extra software.
In essence, your browser becomes a zero-trust endpoint.
How it Works in NetFoundry Cloud
Typically, the OpenZiti Edge API is Internet-facing, while the OpenZiti Management API is protected. Since OpenZiti is purpose-built for secure connectivity, we secure the management API within NetFoundry Cloud by using OpenZiti itself, making the management API invisible to the open internet.
The OpenZiti Controller defines the edge API, and it is intended for use by endpoints/clients to authenticate, discover services, dial (connect), or bind (host) services over the Ziti overlay.
The management API is also exposed by the OpenZiti Controller, but is used to manage the network – configuring identities, services, policies, etc. It is intended for administrative control-plane tasks (creating, updating, and deleting entities) rather than actually connecting services.
| Management API | Edge API | |
| Purpose | Configuration/administration of the Ziti overlay (identities, services, roles/policies) | Runtime connectivity: manage an endpoint’s participation (auth, discovery, connect/bind) |
| Typical users | Human Admins and automated orchestration tooling | Endpoint apps, SDKs embedded in apps, and client devices |
| Permissions/usage | Needs elevated privileges (create identity, service, policy) | Less privileged relative to the overlay (once identity is enrolled) |
As you can see, the management API is quite powerful. If it were to become compromised, bad actors could do catastrophic damage to an OpenZiti network.
API security is a critical part of modern web, mobile, and cloud architecture. Some industry-standard mechanisms used to secure APIs today include:
- API Keys
- OAuth2/OIDC
- Mutual TLS (mTLS)
- JWTs
- WAFs
- IP Whitelists/CIDR restriction
- Security Headers in HTTP requests
- And of course, Zero Trust
The NetFoundry Cloud’s management API does not suffer from the typical API attack vector exposures. In addition to the robust authentication-security that OpenZiti employs, an additional and very effective way to eliminate API attack vectors is to make the API invisible to the open internet.
Let’s explore what that means and how NetFoundry Cloud achieves “invisibility” for the management API, thus boosting the defensive posture of all NetFoundry networks.
Achieving Invisibility
OpenZiti supports the innovative approach of embedding secure zero-trust connectivity directly into applications (even browser-based web apps).
The NetFoundry Cloud SPA now embeds and integrates with our newly open-sourced OpenZiti SDK for browser-based web apps (@openziti/ziti-sdk-browser).
Again, within the NetFoundry Cloud SPA, the ziti-sdk-browser takes care of all operations related to:
- authenticating with the OpenZiti Controller
- doing the necessary negotiations with the OpenZiti Controller to acquire an ephemeral x509 certificate
- using this certificate to make the required mTLS connection to the network
- mapping any HTTPS Requests initiated by the NetFoundry Cloud console that target the management API onto the OpenZiti network and then
- routing them to the nf-mgmt-service described below.
Admin users simply open a Chrome Tab on any computer, log in to the NetFoundry Cloud console, and they’re ready to go!
Before the availability of our new browser SDK, the most common way to facilitate client access to remote OpenZiti Services was to:
- Create an Identity, then
- Install an OpenZiti Tunneler on the client machine, then
- Enroll the Identity within the tunneler, then
- Configure the various role attributes for the Identity, then
- Connect the tunneler to the network, then
- Finally, open a Chrome browser tab and go to the NetFoundry Cloud web console, and have access to any UI gestures that leverage the management API
As you can see, by leveraging the ziti-sdk-browser, NetFoundry Cloud now has a much more streamlined approach.
Representing the Management API in a NetFoundry Cloud Network
Let’s begin by discussing how the management API is manifested in the networks provisioned by NetFoundry Cloud (i.e., this does not happen by default in a self-hosted OpenZiti network).
When NetFoundry Cloud provisions your network, it automatically performs the tasks necessary to represent the management API as an OpenZiti Service.
NetFoundry Cloud names the Service the nf-mgmt-service, as shown here:
Like all Services, steps are taken during network cloud-provisioning to ensure the management API does not listen on any open inbound ports on the underlying IP network.
Furthermore, NetFoundry Cloud also ensures that client access to the nf-mgmt-service is granted only after strict authentication and authorization is achieved – based on strong, cryptographically verifiable Identities.
Micro-segmentation
Another fundamental feature delivered by the NetFoundry Cloud is micro-segmentation.
Having a valid Identity on a NetFoundry network (i.e., completion of successful authentication) does not necessarily mean access to the nf-mgmt-service is possible for the Identity.
Access to the nf-mgmt-service is controlled by Roles and Policies assigned to the nf-mgmt-service, and which are mapped onto any Identities that require access due to their administrative needs (i.e., authorization is necessary).
If an Identity is justified in needing access to the nf-mgmt-service, that Identity will be granted Dial (connect) access by virtue of being assigned the nf-mgmt-access Attribute, as shown here:
Above, you can see that the Identity used in this example is “managed”. A “managed” Identity is one that NetFoundry Cloud automatically provisioned on behalf of the privileged admin user (me in this case) as derived from OIDC-based credentials, which are used to log in to the NetFoundry Cloud console.
Developer Experience
The ziti-sdk-browser is designed to simplify routing HTTP Requests originating from the web app onto a protected OpenZiti Service.
The SDK exposes a fetch API that mimics the native browser fetch API, so the structure and flow should feel familiar.
For example, once the target resource (API Server) has been properly configured as an OpenZiti Service (similar to what was described in the previous section), HTTP Requests can be easily routed to the Service as shown in the following TypeScript code.
Here’s what it looks like in practice:
Instantiate a zitiBrowserClient (one-time operation during app initialization):
Make a fetch request (this code shows how to map Angular HttpRequest’s onto OpenZiti):
The same API URLs and code patterns continue to work — the SDK simply intercepts and routes them through the OpenZiti network.
Why This Matters
By embedding the OpenZiti Browser SDK into our SPA, NetFoundry Cloud now offers:
- True zero exposure: no public-facing APIs
- Frictionless user experience: no tunneler installation
- Granular access control: micro-segmented, role-based authorization
- Strong cryptographic identity: every connection is authenticated
- Drop-in simplicity: works like native fetch()
Who This Is For
Use the OpenZiti Browser SDK if you:
- Build SPAs or web consoles that call backend APIs
- Need those APIs to remain invisible to the internet
- Want zero-trust connectivity without installing tunnelers
- Already use or plan to use OpenZiti or NetFoundry Cloud
If that’s you, your browser can now be a first-class, zero-trust endpoint.
Conclusion (Come Talk to Us)
Zero trust doesn’t have to live in a gateway or VPN client. It can live directly inside your application — even your browser.
While a deeper discussion of the internals of the ziti-sdk-browser (e.g., how we use WASM for PKI and nested TLS operations) is beyond the scope of this article, we hope this high-level discussion demonstrates how NetFoundry’s state-of-the-art technology is constantly improving ways to make your networks not only more secure but also more convenient to use.
If this sounds interesting to you, reach out and talk to us about getting access to NetFoundry Cloud.
