Bezpieczeństwo przy wdrażaniu na Vercel

„Bezpieczeństwo Vercela" dzieli się na dwie połowy, których lepiej nie mieszać. Pierwsza to to, czym Vercel zarządza za Ciebie i co pozwala skonfigurować w panelu: ochrona wdrożeń, zmienne per środowisko, firewall, role zespołu. Druga to to, co Cursor, v0 czy Bolt wpisują do Twojego projektu, a Vercel wdraża bez zmian, z publicznymi kluczami i niechronionymi ścieżkami. Ten przewodnik wyjaśnia model Vercela, omawia, co AI robi źle przy wdrażaniu tam, zostawia Ci gotowy do wklejenia vercel.json, prompt do przeglądu i cztery kontrole z zewnątrz. Szczegóły każdego błędu są w bezpieczeństwo przy wdrażaniu na Vercelu.

Część 1: jak działa bezpieczeństwo na Vercelu

Co Vercel robi sam

Certyfikat TLS wystawiany i odnawiany automatycznie, przekierowanie z HTTP na HTTPS, funkcje serverless izolowane między projektami, globalna sieć z ochroną przed DDoS i dziennik każdego wdrożenia z informacją, kto je zrobił i z jakiego commita. Niczego z tego nie musisz konfigurować. Ustawia też nagłówek, żeby wyszukiwarki nie indeksowały podglądów.

Co jest Twoją konfiguracją

• Deployment Protection. Domyślnie podglądy są publiczne dla każdego z URL-em. W Settings możesz wymagać konta Vercel z zespołu (za darmo), hasła (plany płatne) albo ograniczyć po IP. To pierwsze pole do zaznaczenia.
• Zmienne środowiskowe per środowisko. Każda zmienna jest przypisana do Production, Preview lub Development. Klucze produkcyjne nie powinny istnieć w Preview, a wrażliwe oznacza się jako Sensitive, żeby nie dało się ich ponownie odczytać z panelu.
• Firewall. Vercel Firewall ma reguły zarządzane, tryb wyzwania przeciw botom i własne reguły limitu żądań per IP lub per ścieżka. Włącza się je z panelu bez dotykania kodu i są odpowiedzią na „ktoś zużywa mój limit OpenAI".
• Git i wdrożenia. Każdy push na dowolną gałąź wdraża. Chroń gałąź produkcyjną na GitHubie, sprawdź, które konta mają dostęp do projektu, i wymuś uwierzytelnianie dwuskładnikowe w zespole.
• Tokeny i usługi. Tokeny CLI, tokeny Vercel Blob czy zintegrowanych baz danych to sekrety serwerowe. Token Vercela z zakresem zespołu wdraża, co chce, we wszystkich Twoich projektach.

Co zależy od frameworka, nie od Vercela

Które zmienne trafiają do przeglądarki (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_), czy publikowane są source mapy i jakie nagłówki są wysyłane, decyduje Twój framework i Twoja konfiguracja, nie platforma. Vercel tylko uruchamia build. Dlatego dwie aplikacje na Vercelu mogą mieć A i F w nagłówkach.

Część 2: co AI robi źle przy wdrażaniu na Vercelu

• Sekretne klucze z publicznym prefiksem, bo komponent „ich potrzebował". Podróżują w bundle'u do wszystkich odwiedzających. Poszukaj sk_live, service_role lub AKIA w swoich chunkach.
• Wdrożone ścieżki testowe. /api/debug, /api/seed czy /api/admin stworzone do testów i wypchnięte na produkcję bez uwierzytelnienia.
• Cron bez sekretu. Vercel wywołuje Twoją ścieżkę cron z nagłówkiem Authorization zawierającym Twój CRON_SECRET; jeśli handler go nie sprawdza, każdy uruchomi zadanie.
• Funkcje bez limitów. Endpoint wywołujący model albo wysyłający e-maile bez limitu na użytkownika i bez reguły firewalla.
• Pliki w public/. Skopiowany .env, backup.json, config.yml. Wszystko w tym katalogu jest publiczne.
• CORS z wildcardem i poświadczeniami na ścieżkach API, bo „tak działało z localhosta".
• Brak vercel.json. Ani nagłówków bezpieczeństwa, ani przekierowania domeny .vercel.app na własną, która dubluje się w Google.

Gotowy do wklejenia vercel.json

Nagłówki bezpieczeństwa dla wszystkich ścieżek i przekierowanie subdomeny Vercela na Twoją domenę. Podmień dwie nazwy, a jeśli używasz Next.js, nagłówki możesz zamiast tego umieścić w next.config:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=63072000; includeSubDomains; preload" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
      ]
    }
  ],
  "redirects": [
    {
      "source": "/(.*)",
      "has": [{ "type": "host", "value": "moj-projekt.vercel.app" }],
      "destination": "https://twojadomena.com/$1",
      "permanent": true
    }
  ]
}

Content-Security-Policy idzie osobno, bo zależy od Twoich skryptów; zacznij w trybie raportowania, jak wyjaśnia nagłówki bezpieczeństwa HTTP.

Prompt do przeglądu przed wdrożeniem

Przejrzyj bezpieczeństwo tego projektu wdrożonego na Vercelu i na razie niczego nie zmieniaj. Odpowiedz listą:
1. Zmienne z publicznym prefiksem (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_) zawierające sekretne klucze.
2. Ścieżki API bez sprawdzania sesji, ścieżki testowe lub debugowe oraz ścieżki cron, które nie weryfikują CRON_SECRET.
3. Endpointy wywołujące płatne usługi bez limitu na użytkownika.
4. Pliki w public/, które nie powinny być publiczne.
5. Ścieżki API z Access-Control-Allow-Origin: * i poświadczeniami.
6. Czy istnieje vercel.json lub next.config z nagłówkami bezpieczeństwa i czy source mapy są wyłączone na produkcji.
Dla każdego punktu zaproponuj dokładną zmianę i poczekaj na moje potwierdzenie.

Sprawdź wynik z zewnątrz

curl -sI https://twojadomena.com | grep -iE "strict-transport|x-frame|x-content-type|content-security"
curl -sI https://moj-projekt.vercel.app | grep -iE "^HTTP|^location"
curl -sI https://moj-projekt-git-main-zespol.vercel.app | grep -iE "^HTTP"
for p in .env .env.local config.json backup.zip api/debug api/seed; do printf "%-14s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://twojadomena.com/$p"; done

Oczekiwane: obecne nagłówki, 301 na Twoją domenę pod URL-em .vercel.app, 401 pod URL-em podglądu, jeśli ochrona jest włączona, i 404 na każdej ścieżce z listy. Scanaris wykonuje te kontrole i około czterdziestu innych w 30 sekund: wykrywa, że aplikacja jest na Vercelu i w jakim frameworku, szuka sekretów w bundle'u, sprawdza source mapy, nagłówki, CSP, ciasteczka, CORS, TLS i wystawione pliki, a dla każdego błędu daje fix prompt do wklejenia w Cursorze, v0 lub Bolcie. Jeśli Twoja aplikacja to Next.js, przewodnik po Next.js wyjaśnia, który kod działa na serwerze, a co trafia do przeglądarki.

Często zadawane pytania

Czy podglądy Vercela są prywatne?

Domyślnie nie: każdy z URL-em je otworzy, choć nie są indeksowane. Włącz Vercel Authentication w Deployment Protection; jest dostępne w planie darmowym.

Czy Vercel chroni moje ścieżki API?

Nie. Ścieżka API to publiczny URL; sesję sprawdzasz Ty w kodzie. Firewall może limitować żądania i hamować boty, ale nie decyduje, kto jest autoryzowany.

Czy potrzebuję vercel.json, jeśli używam Next.js?

Do nagłówków nie: next.config ma funkcję headers(). Do przekierowania domeny .vercel.app na Twoją możesz użyć dowolnego z dwóch. Ważne, żeby istniało w którymś z nich.