How to Keep Your Stripe Secret Key Server-Side

1. Know your keys: only one belongs in the browser

Stripe gives you different keys for different trust levels. Mixing them up is the whole problem. Per Stripe’s docs, only publishable keys are safe to expose outside your backend; you’re responsible for protecting every other key, including restricted keys. Stripe: API keys

Test vs. live matters too: _test_ keys only touch sandbox data and _live_ keys touch real money, but a leaked test secret in your bundle is still a red flag. It usually means the live one is one env-var swap away from the same mistake.

2. How it leaks in vibe-coded apps

AI coding tools optimize for “it works.” If a Stripe call fails in the browser, the fastest patch is to move the key where the browser can reach it. These three patterns are the most common:

Pattern A: the NEXT_PUBLIC_ trap

In Next.js, any env var starting with NEXT_PUBLIC_ is inlined into the JavaScript sent to every visitor. Naming your secret NEXT_PUBLIC_STRIPE_SECRET_KEY doesn’t make it a different key. It publishes it.

Pattern B: Stripe initialized in a client component

Any file with "use client", and anything it imports, can end up in the client bundle. If that file imports stripe (the server SDK) and reads STRIPE_SECRET_KEY, the key (or the code path holding it) ships.

Pattern C: the key in GitHub

Hardcoded fallback like const key = process.env.X || "sk_live_…", or a committed .env / .env.local. Even if you delete it later, it lives in git history and in any fork or clone.

// ❌ This whole file runs in the browser
"use client";
import Stripe from "stripe";

// ❌ Secret key in client code: anyone can View Source and take it
const stripe = new Stripe(process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY!);

export default function Pricing() {
  async function buy() {
    const session = await stripe.checkout.sessions.create({ /* … */ });
    window.location.href = session.url!;
  }
  return <button onClick={buy}>Buy</button>;
}

// ✓ Browser never sees the secret. It only asks YOUR server
"use client";

export default function Pricing() {
  async function buy() {
    const res = await fetch("/api/checkout", { method: "POST" });
    const { url } = await res.json();
    window.location.href = url;
  }
  return <button onClick={buy}>Buy</button>;
}

3. Check if you’re exposed (60 seconds)

grep -rE "sk_(live|test)_|rk_(live|test)_|whsec_" --exclude-dir=node_modules .
grep -r "NEXT_PUBLIC_.*STRIPE_SECRET\|NEXT_PUBLIC_.*SK_" --exclude-dir=node_modules .

4. The fix: move every secret-key call server-side

The rule is simple: the browser should never need to prove it’s you to Stripe. Your server proves it (with the secret key), creates the thing, and hands the browser a one-time URL or client secret.

# ✓ Safe to expose: publishable only
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_...

# ✓ Server-only: NO NEXT_PUBLIC_ prefix
STRIPE_SECRET_KEY=sk_live_...
STRIPE_WEBHOOK_SECRET=whsec_...

import "server-only";
import Stripe from "stripe";

if (!process.env.STRIPE_SECRET_KEY) {
  throw new Error("STRIPE_SECRET_KEY is not set");
}

export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

import { NextResponse } from "next/server";
import { stripe } from "@/lib/stripe";

export async function POST() {
  const session = await stripe.checkout.sessions.create({
    mode: "payment", // or "subscription"
    line_items: [{ price: "price_...", quantity: 1 }],
    success_url: `${process.env.NEXT_PUBLIC_APP_URL}/success?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${process.env.NEXT_PUBLIC_APP_URL}/pricing`,
  });
  return NextResponse.json({ url: session.url });
}

import { NextResponse } from "next/server";
import { stripe } from "@/lib/stripe";

export async function POST() {
  const intent = await stripe.paymentIntents.create({
    amount: 1900, // $19.00: calculate this on the server, never trust the client
    currency: "usd",
    automatic_payment_methods: { enabled: true },
  });
  return NextResponse.json({ clientSecret: intent.client_secret });
}

import { headers } from "next/headers";
import { stripe } from "@/lib/stripe";

export async function POST(req: Request) {
  const body = await req.text(); // raw, NOT req.json()
  const sig = (await headers()).get("stripe-signature")!;
  const event = stripe.webhooks.constructEvent(
    body, sig, process.env.STRIPE_WEBHOOK_SECRET!
  );
  if (event.type === "checkout.session.completed") {
    // Fulfill the order here. This is the signal you can trust
  }
  return new Response("ok");
}

5. Already leaked? Rotate first, refactor second

Deleting the key from your code does not un-leak it. Anyone who copied it still has it until you roll it in Stripe. Do these in order:

6. Harden it further

Prefer a restricted key for your app

Create a restricted key (rk_live_…) with only the permissions your server needs (for a typical checkout flow, write access to Checkout Sessions / PaymentIntents and read access to the objects you reconcile), and use it instead of the unrestricted secret. If it ever leaks, the blast radius is smaller. It still never goes in the browser.

One key per environment, one per app

Don’t reuse the same secret across staging, a side project, and production. Separate keys mean you can roll one without breaking everything, and Stripe’s logs tell you which app made a call.

Don’t log keys, don’t paste them into AI chats

Never console.log(process.env), never include a real key in a prompt, screenshot, or support ticket. If a key appears in a log or chat, treat it as leaked and roll it.

Stripe key checklist

• Only pk_… has a NEXT_PUBLIC_ prefix. Search env names for NEXT_PUBLIC_ + SECRET / SK_ returns nothing.
• No sk_, rk_, or whsec_ in live JS. Searched the deployed /_next/static/ files and found nothing.
• Stripe SDK lives in one server-only file. No client component imports stripe or lib/stripe.
• Checkout / PaymentIntents are created on the server. Browser only receives a Checkout URL or a single-payment client_secret.
• Amounts are calculated server-side. The price the user pays never comes from a value the browser sent unchecked.
• Webhooks verify signatures with the raw body and are the only trigger for fulfillment, not the success redirect.
• Any key that ever shipped has been rolled in Stripe, and Stripe Logs were reviewed for unfamiliar activity.
• .env* is gitignored and a restricted key is used in production where practical.

FAQ

Keep reading

Sources: Stripe Documentation: API keys. Code patterns follow Stripe’s Checkout Sessions / PaymentIntents model: create on the server, confirm in the browser, fulfill on verified webhooks.