Vercel kan hantera Stripe-nyckeln – vilka risker försvinner?

Vad Vercel har ändrat

Vercel Connect kan nu skapa och lagra begränsade Stripe-nycklar åt din applikation. Funktionen presenterades i Vercels ändringslogg den 23 oktober 2026 och kallas Managed API Key.

Tidigare var ett vanligt upplägg att du skapade en Stripe-nyckel, kopierade den och lade den som en miljövariabel i Vercel. Samma hemlighet kunde sedan ligga kvar länge, följa med mellan miljöer och ibland också hamna i lokala filer, dokumentation eller andra tjänster.

Med den hanterade metoden skapar Vercel i stället en begränsad API-nyckel direkt i ditt Stripe-konto. Du väljer vilka Stripe-resurser nyckeln får läsa eller ändra. Vercel lagrar nyckeln och kopplar anslutningen till de projekt och miljöer som ska få använda den.

När applikationen behöver prata med Stripe anropar den getToken via Vercel Connect. Din körande applikation identifierar sig mot Vercel med OIDC – en kortlivad identitet som är knuten till bland annat projektet och miljön. Vercel kontrollerar sedan om projektet får använda den aktuella Stripe-anslutningen.

Det är viktigt att skilja på identiteterna i kedjan:

• Applikationen använder en kortlivad Vercel-identitet för att nå Vercel Connect.
• Vercel Connect använder den begränsade Stripe-nyckeln för att nå Stripe.
• Stripe avgör vad nyckeln får göra utifrån de valda behörigheterna.

Det betyder inte att Stripe-nyckeln i sig automatiskt har blivit kortlivad. Den har flyttats från din applikations konfiguration till Vercels hantering. Säkerhetsvinsten kommer främst från att nyckeln inte behöver kopieras runt och från att den kan få snävare behörighet.

Riskerna som faktiskt minskar

Den tydligaste förbättringen är att färre personer och system behöver se själva Stripe-nyckeln. Du behöver inte klistra in den i Vercels miljövariabler, skicka den till en utvecklare eller lägga den i en lokal .env-fil för att få integrationen att fungera.

Det minskar flera vanliga risker.

Hemligheten sprids inte lika lätt. Varje plats där en nyckel kopieras blir en plats som måste skyddas, inventeras och städas vid en incident. Hanteringen blir enklare när Vercel skapar och förvarar nyckeln.

Applikationen behöver inte använda Stripes fullständiga hemliga nyckel. En begränsad Stripe-nyckel kan exempelvis få läsa betalningsinformation utan att kunna skapa återbetalningar eller ändra kunder. Om nyckeln exponeras begränsas skadan till det som nyckeln faktiskt tillåter.

Olika arbetsuppgifter kan få olika behörigheter. Ett rapportjobb behöver kanske bara läsa data. Ett flöde som skapar Stripe-kunder behöver skrivåtkomst till kunder men inte åtkomst till utbetalningar. När dessa funktioner använder egna anslutningar behöver du inte ge båda samma breda nyckel.

Rotation kräver inte samma ingrepp i driftsättningen. Vercel låter dig rotera nyckeln från anslutningens inställningar utan att först ändra en miljövariabel och driftsätta applikationen på nytt. Det minskar risken att gamla värden ligger kvar i fel miljö eller att en brådskande rotation skjuts upp.

Projektets identitet kan ersätta en långlivad Vercel-token. När koden körs på Vercel kan Connect använda projektets OIDC-identitet. Du behöver då inte skapa ännu en statisk åtkomsttoken för länken mellan applikationen och Vercel Connect.

Förbättringarna handlar alltså om färre manuella överlämningar, mindre hemlighetsspridning och en mindre möjlig skada om något går fel. De innebär inte att åtkomsten till Stripe har blivit riskfri.

Riskerna som finns kvar

Den största kvarvarande risken är felaktiga behörigheter. En hanterad nyckel med bred skrivåtkomst kan fortfarande ändra viktig data. Att Vercel förvarar nyckeln gör inte behörigheterna mindre kraftfulla.

Utgå därför från minsta möjliga behörighet. Börja med vad funktionen ska göra i verksamhetstermer och översätt sedan det till Stripe-resurser. Ett jobb som sammanställer betalningar behöver normalt läsbehörighet. Ett kundflöde som skapar eller uppdaterar kunder behöver skrivbehörighet till den resursen. I Stripe innebär skrivbehörighet även att nyckeln kan läsa samma resurs.

Du måste också skydda det som får begära ut nyckeln. Om ett Vercel-projekt är kopplat till anslutningen kan kod i en tillåten miljö anropa Connect. En sårbar serverfunktion, felaktig autentisering eller manipulerad agent kan därför använda Stripe inom nyckelns behörigheter. Connect ersätter inte kontroller i din egen applikation.

Kontrollera exempelvis att:

• användaren bakom en begäran verkligen får utföra åtgärden
• en AI-agent inte kan välja godtyckliga Stripe-anrop utifrån okontrollerad text
• beloppsgränser och affärsregler valideras på serversidan
• administrativa funktioner inte exponeras genom publika API-rutter
• Stripe-nyckeln aldrig skrivs till loggar, felmeddelanden eller spårningsverktyg

Åtkomsten till Vercel-kontot blir samtidigt viktigare. Teammedlemmar med rätt att skapa, ändra eller koppla anslutningar kan påverka vilka projekt som når Stripe. Granska därför roller, inloggningsskydd och rutiner när någon lämnar teamet. Gör motsvarande kontroll i Stripe, där nyckeln och dess behörigheter ytterst finns.

Kom också ihåg att API-nyckeln inte är Stripes enda hemlighet. En webhook har normalt en separat signeringshemlighet som används för att verifiera att händelsen verkligen kommer från Stripe. Den ersätts inte av Vercel Connect. Publicerbara Stripe-nycklar, webhook-hemligheter och eventuella hemligheter i andra integrationer behöver fortfarande hanteras utifrån sina egna roller.

Separera testmiljö från produktion

Miljögränsen är särskilt viktig eftersom en Vercel-anslutning kan kopplas till produktion, preview och utveckling. Att en deployment är en preview betyder inte automatiskt att den får en ofarlig Stripe-nyckel.

Om samma anslutning är tillgänglig i flera miljöer kan kod från en testgren i värsta fall nå samma Stripe-konto och samma data som produktionen. Det gäller även om själva sidan ligger bakom en tillfällig Vercel-adress.

Använd därför separata Stripe-anslutningar för test och produktion. Testanslutningen bör använda en Stripe-sandbox eller testläge, medan produktionsanslutningen ska använda en live-nyckel med noggrant valda behörigheter. Koppla sedan varje anslutning enbart till rätt Vercel-miljö.

Det är en viktig skillnad mellan att begränsa vilken deployment som får begära en nyckel och att begränsa vilket Stripe-konto eller läge nyckeln når. Projekt- och miljökopplingen i Vercel styr den första delen. Separata anslutningar och separata Stripe-nycklar ger isolering hos Stripe.

När du testar övergången bör du inte bara kontrollera att en betalning lyckas. Gå igenom alla serverfunktioner som använder Stripe, till exempel kundskapande, prenumerationsändringar, återbetalningar, rapporter och bakgrundsjobb. Begränsade nycklar ger tydliga fel när en begäran saknar rätt behörighet, men felet kan ligga dolt tills en ovanlig funktion används.

Granska både applikationens loggar och Stripes logg över API-anrop. Där ser du vilka resurser som faktiskt används och om nyckeln försöker utföra något den inte får. Ta bort behörigheter som inte används i stället för att behålla dem för säkerhets skull.

Planera även för rotation och återställning. Vercel kan hålla den tidigare nyckeln giltig under en övergång när du roterar. Det underlättar ett planerat byte, men vid en misstänkt läcka behöver du förstå om den gamla nyckeln fortfarande fungerar och vid behov återkalla den direkt i Stripe.

Kontrollista innan du byter

Ett byte till hanterade Stripe-nycklar bör behandlas som en behörighetsmigrering, inte bara som en ändring av var en miljövariabel ligger.

• Inventera alla ställen där applikationen använder Stripe.
• Kontrollera om samma Stripe-nyckel används av flera tjänster, jobb eller projekt.
• Skapa egna anslutningar för funktioner med olika behov.
• Ge läsbehörighet där koden bara läser data.
• Ge skrivbehörighet enbart till resurser som faktiskt ändras.
• Använd en separat testanslutning mot Stripe-sandbox eller testläge.
• Kontrollera exakt vilka Vercel-miljöer varje anslutning är kopplad till.
• Säkerställ att preview-deployments inte kan nå produktionsanslutningen.
• Granska vilka teamroller som får ändra, koppla och rotera anslutningar.
• Kontrollera att tokenvärden inte loggas eller skickas till analysverktyg.
• Testa ovanliga flöden och bakgrundsjobb innan den gamla nyckeln tas bort.
• Granska API-loggar efter nekade anrop och oväntad användning.
• Dokumentera hur nyckeln roteras och återkallas vid en incident.
• Hantera webhookens signeringshemlighet separat.
• Ta bort gamla Stripe-nycklar när migreringen är verifierad.

Vercel Connect minskar alltså behovet av att bära runt på Stripe-hemligheter, men säkerheten avgörs fortfarande av vad nyckeln får göra, vilka miljöer som når den och vem som kan ändra anslutningen. Om du vill göra samma genomgång när en prototyp ska få riktiga betalningar, behörigheter och driftmiljöer kan du läsa om steget från prototyp till produkt.

---

Källa: Vercel changelog