Copy page

Securing Your Backend

Securing your backend

When using a gateway, it's important to ensure that your backend API is only receiving traffic via the gateway to be confident that your policies are being correctly applied to all traffic.

That means securing the communication between Zuplo and your backend API (origin). Several options do this, and the right one depends on where your backend runs and what it can already verify.

Approach	Use it when	Plan
Shared secret	Your backend can check a header. The most common choice, and the simplest.	All
IAM authentication	Your backend runs behind AWS, Azure, or Google Cloud IAM.	Enterprise
mTLS	You want both sides to authenticate each other with certificates.	Enterprise
Secure tunnel	Your backend has no public endpoint, or runs on bare metal or on premises.	Enterprise
Custom networking	You're on managed dedicated and want VPC peering or PrivateLink.	Dedicated

The rest of this page covers the shared secret approach in full. Each other approach has its own section in the sidebar.

Shared secret or API key

This is the most popular option and is used by companies like Supabase, Firebase, and Stripe to secure their own APIs. In this solution the backend requires a secret that's known only by the gateway. This is usually an opaque key sent as a header on every request to the origin. Zuplo adds this to the request - the client is never aware of the secret.

Step 1: Set an environment variable

Set an environment variable in your Zuplo project. This variable is a secret that only your Zuplo project and your backend know. It is sent as a header on every request to your backend API.

Open the Settings section of your project and select Environment Variables. Create a new variable and name it BACKEND_SECRET. Set the value to a secure, random value. Ensure that the value is marked as a secret.

Step 2: Create a set header policy

Create a policy that sets the BACKEND_SECRET as a header on the request to your backend API. This policy is an inbound policy that runs before the request is sent to your backend.

Navigate to the route you want to secure and add a new policy. Select the Add or Set Request Headers policy type and configure it as follows:

The configuration uses the environment variable via the $env(BACKEND_SECRET) selector as shown below.

Code
{
  "name": "set-backend-secret",
  "policyType": "set-headers-inbound",
  "handler": {
    "export": "SetHeadersInboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "headers": [
        {
          "name": "backend-secret",
          "value": "$env(BACKEND_SECRET)"
        }
      ]
    }
  }
}

Add this policy to any of the routes in your API that call your secure backend.

Step 3: Verify the secret on your backend

Verify the secret on your backend. The implementation depends on the framework and language you use, but the typical pattern is to use middleware to check the header value. If the header does not match the secret, return a 401 Unauthorized response.

An example using a Node.js Express middleware:

Code
const express = require("express");
const app = express();

app.use((req, res, next) => {
  if (req.headers["backend-secret"] !== process.env.BACKEND_SECRET) {
    return res.status(401).send("Unauthorized");
  }
  next();
});

IAM authentication

Let your cloud provider decide whether a request from Zuplo is allowed through. Your gateway proves its identity to AWS, Azure, or Google Cloud, and your provider's authorization rules apply — so there's no shared secret to distribute.

Where the provider supports it, Zuplo can present a short-lived OIDC token and exchange it for temporary credentials, which means no long-lived key exists at all. Otherwise the policies use a key or client secret you store as an environment variable.

For the policy for each provider and the trade-off between the two approaches, see IAM authentication for your backend.

mTLS authentication

Mutual TLS establishes a trust relationship between your gateway and your backend using client certificates. Both sides authenticate each other, which gives you a zero trust posture between the two.

Zuplo manages the client certificates, presents them on upstream requests, and supports rotation and per-environment certificates. See Gateway to origin mTLS authentication. For a worked example against an AWS load balancer, see Connect to an AWS ALB with mTLS. This is an enterprise feature.

Secure tunneling

A secure tunnel runs a small connector inside your VPC or private data center that makes an outbound connection to your Zuplo gateway. It suits workloads without IAM or mTLS capabilities — bare metal, on premises, or a non-cloud provider. Your backend needs no public endpoint at all.

This is a more involved setup than the other options and is available on the enterprise plan.

Custom networking (managed dedicated only)

On the managed dedicated plan, Zuplo can provide custom networking to reach your backend, using your cloud provider's VPC connectivity — AWS Transit Gateway, PrivateLink, or VPC peering.

For more information, see the networking documentation.

Get help choosing

To discuss security and connectivity options, the Zuplo Discord has active participation from the Zuplo team, or contact support.