Jamstack API Key Management: Transitioning from Client-Side to Serverless Proxies

Question

Securing Sensitive Credentials in Decoupled Architectures
In Jamstack deployments using Static Site Generators (SSGs), environment variables prefixed for client-side exposure are embedded directly into the build artifacts. This makes them accessible to anyone inspecting the browser source or network traffic.
To mitigate this, a common architectural shift involves moving sensitive API calls to serverless functions or edge middleware. These functions act as a secure proxy, keeping private keys on the server side and performing validation before forwarding requests to the upstream API.
The primary challenge lies in balancing the performance benefits of build-time data fetching with the security requirements of request-time dynamic fetching, especially when dealing with frequently updated secrets.

How can a project maintain the speed of static generation while ensuring that sensitive keys are never baked into the CDN-distributed assets?
What is the recommended strategy for rotating leaked keys when they have already been deployed as immutable static assets?

Tasadduq Burney · Answer

Direct answer
Keep sensitive API calls behind a serverless function (or edge middleware) that injects the secret at request time, and fetch all non‑sensitive data at build time via SSG/ISR.
Why this works (likely explanation)
Client‑side environment variables are bundled into the static JS and are visible to anyone. By moving the secret to a serverless runtime, the key never touches the CDN‑served bundle, eliminating exposure while preserving the speed of static generation for public data.
What is verified (confirmed facts)

Build‑time env vars prefixed for public exposure (e.g., NEXT_PUBLIC_, VITE_) are embedded in the produced bundle and can be read from the Network tab.
Serverless functions can access private env vars that are never sent to the browser.
Rotating a key that is already baked into static assets requires a new build and redeployment to purge the old key from the CDN cache.

Identify which API calls need the secret (e.g., payment, auth).
Create a serverless endpoint (e.g., /api/proxy) that:
  
    receives the client request,
    adds the private key from its environment,
    validates any user‑supplied parameters,
    forwards the request to the third‑party API,
    returns the filtered response.

Update the frontend to call /api/proxy instead of the third‑party URL directly.
Keep all public data fetching in getStaticProps, getServerSideProps (if using Next.js) or the SSG’s data layer so the site remains fast.
Deploy the function with the secret stored as a private environment variable on your platform.
To rotate a leaked key:
  
    Update the secret value in the platform’s environment‑variable store.
    Trigger a new build of the site (this forces a fresh deployment).
    Invalidate or purge the CDN cache for the previous deployment (most platforms do this automatically on a new deploy).
    Verify that the old key no longer appears in any network request or in the downloaded bundles.

Missing diagnostic detail: Which Jamstack hosting platform (Vercel, Netlify, Cloudflare Pages, etc.) are you using? The exact steps for creating the serverless function and setting private env vars differ slightly between providers.

Jamstack API Key Management: Transitioning from Client-Side to Serverless Proxies

Securing Sensitive Credentials in Decoupled Architectures

1 answer

Direct answer

Why this works (likely explanation)

What is verified (confirmed facts)

Your perspective belongs here.

0 question comments