Vercel skyddar produktionen utan tillägg – prova att fel besökare faktiskt stoppas

Vad Vercel ändrade den 9 september

I changelogposten Protect production deployments for free on every plan skriver Vercel att Vercel Authentication nu kan skydda alla deployer i ett projekt, inklusive produktion, ”at no additional cost on every plan”. Tidigare krävde skydd av produktionsdomäner tillägget Advanced Deployment Protection för 150 USD per månad. Med skyddet påslaget måste besökaren logga in med ett Vercel-konto som har åtkomst till projektet. Vercel nämner interna verktyg, privata dashboards och sajter som ännu inte ska lanseras som användningsfall.

Inställningen finns enligt changeloggen under Security och Deployment Protection i projektet, där du väljer All Deployments. Samma val kan bli teamets standard för nya projekt. Två följdändringar nämns: Deployment Protection Exceptions ska inte längre kosta extra på någon plan, och Pro-team kan köpa Password Protection per projekt i stället för för hela teamet. En separat changelogpost samma dag anger priset till 20 USD per projekt och månad på Pro.

Planbeskedet är nu samstämmigt

Sidan Deployment Protection on Vercel anger vid kontrollen den 11 september att både All Deployments och Vercel Authentication finns på alla planer. Den säger också uttryckligen att kombinationen Vercel Authentication och All Deployments inte kräver något betalt tillägg. Det stämmer med changeloggen från den 9 september, trots att sidans metadata fortfarande visar 28 augusti som senaste uppdateringsdatum.

Öppna ändå projektets inställning och anteckna tre saker: teamets plan, vald skyddsmetod och valt omfång. Spara en skärmbild med datum. Då går det att skilja Vercel Authentication från exempelvis den avgiftsbelagda Password Protection på Pro och att i efterhand visa vad som faktiskt aktiverades.

Välj skyddsomfång

Dokumentationen beskriver två aktuella omfång. Standard Protection skyddar alla domäner utom produktionsdomäner. All Deployments skyddar alla URL:er, även produktionsdomänen och genererade URL:er av typen my-project-1234.vercel.app. Därutöver finns två legacyval. Att skydda enbart produktion görs enligt samma sida med Trusted IPs, som bara finns på Enterprise.

Avvägningen är enkel att formulera men lätt att missa. Standard Protection räcker när produktionssajten ska vara publik men previews inte ska vara det. All Deployments passar när även produktionen bara är till för personer med Vercel-konto: ett internt verktyg, en adminyta eller en prototyp före lansering. För en publik app är det fel val, eftersom dina användare möts av Vercels inloggning. Kundinloggning hör hemma i appens egen autentisering.

Skyddet sätts per projekt, och en teamstandard gäller nya projekt. Skriv därför upp varje befintligt projekt, dess produktionsdomäner och valt omfång innan du ändrar något. Via API motsvaras All Deployments av värdet all i ssoProtection.deploymentType och Standard Protection av prod_deployment_urls_and_all_previews, enligt Vercels sida om Vercel Authentication. Anteckna värdet i protokollet.

Besökarprov med fyra roller

Samma dokumentationssida listar sex grupper som når en skyddad deploy: teammedlemmar med minst Viewer-roll, projektmedlemmar med minst project Viewer, access groups med projektåtkomst, beviljade Vercel-användare, den som har en delbar länk och verktyg med bypass-headern för automation. Provet täcker fyra roller som var för sig kan ge ett falskt godkänt, och varje roll ska ha ett förväntat och ett underkänt utfall.

Kör varje roll i ett nytt privat fönster eller en ny webbläsarprofil. Dokumentationen varnar för att en användare som redan autentiserats mot en viss URL kan behålla åtkomsten via en cookie när skyddet slås på igen. Cookien gäller bara en URL, så prova produktionsdomänen och den genererade deploy-URL:en var för sig.

För roll 1 räcker ett litet skript. Byt sökvägarna mot routes som finns i din app och spara utskriften med tidpunkt. Dokumentationen säger att skyddet kräver autentisering för alla förfrågningar, även dem till Routing Middleware, så räkna inte med att en publik väg i din egen middleware öppnar en sökväg. Provet visar hur det faktiskt beter sig.

URL=https://app.example.se
for p in / /api/health /favicon.ico; do
  curl -sS -o /dev/null -w "$p %{http_code} %{redirect_url}\n" "$URL$p"
done

Anteckna statuskod och eventuell omdirigering som observationer. Godkänt avgörs av att appens innehåll inte levereras, inte av en viss siffra.

Roll 3 kräver rätt behörighet. Enligt dokumentationen om delbara länkar får teammedlemmar med minst Member-roll och projektadministratörer skapa länkar för produktionsdomäner. Du återkallar genom att växla till Only people with access. Har deployen också delats med enskilda personer måste de tas bort separat. Alla länkar listas under Access i Deployment Protection; spara den listan före och efter provet.

Roll 4 använder headern x-vercel-protection-bypass. Vercel sätter en hemlighet som systemvariabeln VERCEL_AUTOMATION_BYPASS_SECRET, och ett projekt kan ha flera hemligheter. De två anropen nedan skiljer sig bara i headerns värde:

curl -sS -o /dev/null -w "%{http_code}\n" \
  -H "x-vercel-protection-bypass: $VERCEL_AUTOMATION_BYPASS_SECRET" "$URL/api/health"
curl -sS -o /dev/null -w "%{http_code}\n" \
  -H "x-vercel-protection-bypass: fel-varde" "$URL/api/health"

Den icke-självklara fallgropen: enligt Vercels dokumentation om Protection Bypass for Automation hoppar en giltig hemlighet även över förfrågningar som Vercel Firewalls systemmitigeringar normalt blockerar och över Bot protection-utmaningar. Aktiva DDoS-mitigeringar gäller däremot fortfarande. Hemligheten är alltså mer än en inloggningsnyckel och ska hanteras som en produktionshemlighet.

Hitta det som går sönder

Gör beroendelistan innan skyddet slås på i produktion. Börja med en sökning i kodbasen; mönstret träffar även ramverksvarianter som NEXT_PUBLIC_VERCEL_URL:

git grep -n -E "VERCEL_URL|VERCEL_BRANCH_URL|x-vercel-protection-bypass"

• VERCEL_URL-anrop: Dokumentationen säger att VERCEL_URL och VERCEL_BRANCH_URL inte längre är publikt nåbara när den genererade URL:en skyddas. Beskrivningen står under Standard Protection; All Deployments skyddar samma genererade URL:er och dessutom produktionsdomänen. På klientsidan byter du till en relativ sökväg, som skickar med användarens autentiseringscookie. På serversidan använder du den inkommande begärans origin och skickar vidare dess cookies.
• OG-bilder: De kräver en fullständig URL, och dokumentationen hänvisar då till den faktiska domänen. Med All Deployments är den domänen också skyddad. En extern tjänst som hämtar förhandsbilden utan Vercel-inloggning kan därför stoppas. Hämta din og:image-URL med curl utan cookies och se vad som kommer tillbaka.
• Webhooks: Tjänster som inte kan skicka egna headers, dokumentationen nämner Slack, Stripe och GitHub, kan få hemligheten som query-parameter. Då ligger den i en URL hos tredje part. Att regenerera eller ta bort en hemlighet ogiltigförklarar tidigare deployer och kräver omdeploy, så varje sådan URL måste in i rotationsrutinen.
• Externa kontroller: Upptidsövervakning, syntetiska tester och e2e-körningar i CI behöver headern. Ge varje verktyg en egen hemlighet, så kan du återkalla en utan att stoppa de andra.

Klientsidans byte ser ut så här, med samma anrop före och efter:

// Före
fetch(`${process.env.NEXT_PUBLIC_VERCEL_URL}/api/status`);

// Efter
fetch('/api/status');

Beslut, undantag och ägare

Aktivera All Deployments i produktion först när alla fyra rollerna och beroendelistan är gröna. Tre beslut behöver en namngiven ägare.

Behöver externa granskare utan Vercel-konto se produktionen kan Password Protection för 20 USD per projekt och månad på Pro vara ett alternativ att väga mot delbara länkar. Ett delat lösenord är dock svårare att knyta till en person än en länk med ägare.

Besökarprovet kompletterar den tekniska grinden före Vercel-produktion, som äger beslutet att publicera. Spara resultaten på samma sätt som i kedjan för Vercels säkerhetsfynd: före- och efterläge, tidpunkt och råutskrift, så att nästa granskare kan se att skyddet provades och inte bara slogs på.