How to Secure SPA API Calls Without Exposing Your Backend

Curt Tudor — Tue, 11 Nov 2025 15:32:15 +0000

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.

The post How to Secure SPA API Calls Without Exposing Your Backend appeared first on NetFoundry.

How Mendix Customers Use NetFoundry for Private Connectivity Without VPNs

Philip Griffiths — Mon, 16 Dec 2024 19:07:51 +0000

Mendix accelerates application development and provides rich functionality for operations and security. Mendix Public Cloud does not support VPN-based private networking because VPNs are more pain than they are worth. This is why Mendix and NetFoundry have partnered – to give Mendix customers a private networking option which is simple and software-only.

Mendix customers can now add private networking directly into the Mendix-powered software, as software. It includes built-in authentication, authorization, mTLS, E2E encryption, MFA and posture check. It can secure interactions between Mendix applications and external resources – such as databases, APIs, or third-party services – instead of the existing options available today to secure outgoing connections. Our private connectivity solution will be turned into a Mendix-supported module in the Mendix marketplace, allowing developers to incorporate secure, invisible connections with minimal hand-coding, leveraging visual modelling and a robust set of tools.

For now, the Mendix developer adds NetFoundry code to their Mendix application (example below), and that code controls the private networking, with all the functionality provided as turnkey SaaS. The Mendix customer gets a private network connection, embedded into the app, without managing a private network.

This makes it simpler and quicker for Mendix customers to connect with the Mendix cloud – enterprises no longer need to open up ports, whitelist IP addresses, or deal with proxies and certificates:

Topic	Before NetFoundry	After NetFoundry
Private Connections	Not available	Turnkey SaaS
Enterprise WAN Integration	Firewall ACL management	No firewall ACL management
Security and Compliance	Public connections	mTLS, E2E encryption, posture, least privileged access, telemetry, audit logs
Quality and Reliability	Internet-dependent	Dynamic latency optimization, load balancing, and HA
Enterprise Network Exposure	Enterprise DC & cloud firewalls are open	No open inbound firewall ports

If you want to learn more, get a demo or spin up your own sandbox for free, please contact NetFoundry. The following section shows a working example.

How NetFoundry Enables Mendix Low-Code Developers to Embed Simple, Private Connectivity as Software

Using the NetFoundry SDKs, Mendix developers can establish private connections for any protocol to ensure support for any use case. Our example connects the Mendix application to a database in the enterprise cloud or private data center, using the NetFoundry Java SDK and our ZDBC driver, which apps use to access databases and other sensitive resources without exposing network endpoints. The result is simple, private connectivity from the Mendix Cloud to anywhere, without any inbound ports, complex firewall rules, public DNS, and more:

After exporting the project to Eclipse:

Add the NetFoundry Java SDK library to “userlib” (“ziti-x.x.x-full.jar”).
Then add this code:

And just like that, a secure connection to our database, no open ports, no client installed, easy low-code zero trust connectivity.

Building a Secure, Scalable Future for Mendix and Low-Code Applications

Mendix and NetFoundry made private connectivity for low-code apps simple and powerful. If you would like to learn more, get a demo or spin up your own connection for free then please contact us anytime.

The post How Mendix Customers Use NetFoundry for Private Connectivity Without VPNs appeared first on NetFoundry.

Category Archive - Embeddable Zero Trust - NetFoundry