Vercel sprawia, że wdrażanie jest tak łatwe, że zapomina się, iż to nadal serwer w internecie. Sama platforma jest dobrze chroniona: automatyczny TLS, globalna sieć, izolacja między projektami. Dziury robi się samemu w konfiguracji i prawie zawsze są to te same pięć czy sześć. Ten przewodnik omawia je po kolei, z poleceniem do sprawdzenia i dokładną zmianą do załatania, z myślą o aplikacjach generowanych w Cursorze, Bolcie lub v0, które lądują na Vercelu.
1. Zmienne środowiskowe, które trafiają do przeglądarki
Na Vercelu definiujesz zmienne w panelu projektu, a framework decyduje, które docierają do klienta. W Next.js wszystko, co zaczyna się od NEXT_PUBLIC_; w Vite od VITE_; w Nuxt to, co jest pod runtimeConfig.public. To przydatna konwencja, dopóki ktoś nie ustawi NEXT_PUBLIC_STRIPE_SECRET_KEY, bo AI potrzebowała dostępu z komponentu. Ten klucz podróżuje w bundle'u do wszystkich odwiedzających.
Dwa nawyki, które temu zapobiegają. Po pierwsze sprawdzaj prefiks: jeśli zmienna ma publiczny prefiks, załóż, że jest publiczna, i zapytaj siebie, czy powinna być. Po drugie używaj środowisk Vercela (Production, Preview, Development), żeby klucze produkcyjne nie istniały na gałęziach testowych, i oznaczaj wrażliwe jako Sensitive, co uniemożliwia późniejsze podejrzenie ich w panelu. Żeby sprawdzić, co trafiło do bundle'a:
curl -s https://twojadomena.com/ | grep -o '/_next/static/chunks/[^"]*\.js' | sort -u | head -20Pobierz te pliki i poszukaj sk_live, service_role, AKIA albo nazw swoich zmiennych. Więcej w sekrety, które Twoja aplikacja wycieka w przeglądarce.
2. Publiczne wdrożenia podglądowe
Każda gałąź i każdy pull request generuje URL w stylu projekt-git-galaz-zespol.vercel.app. Wygodne do pokazywania zmian i publiczne: każdy z URL-em widzi wersję deweloperską, z niedokończonymi funkcjami, a czasem z danymi testowymi. Vercel domyślnie dodaje nagłówek, żeby wyszukiwarki nie indeksowały podglądów, ale to nie powstrzyma osoby przed ich otwarciem.
Rozwiązanie jest w Settings, Deployment Protection: włącz Vercel Authentication, żeby tylko członkowie zespołu mieli dostęp do podglądów (dostępne w planie darmowym), albo ochronę hasłem w planach płatnych. I pamiętaj, że produkcyjny URL projekt.vercel.app też istnieje obok Twojej domeny: przekieruj go na swoją domenę albo ustaw canonical, żeby nie konkurował z Tobą w Google.
3. Nagłówki bezpieczeństwa, których nikt nie ustawił
Vercel serwuje Twoją aplikację z minimalnymi nagłówkami; te bezpieczeństwa musisz dodać sam. Bez nich Twoja strona może zostać osadzona w cudzym iframie, przeglądarka zgaduje typy treści i nie ma polityki ograniczającej, jakie skrypty się wykonują. W vercel.json dodaje się je tak:
{
"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=()" }
]
}
]
}W Next.js możesz to też zrobić z next.config.js funkcją headers(). Content-Security-Policy zasługuje na osobny krok, bo trzeba ją dopasować do Twoich skryptów; wyjaśnienie każdego nagłówka jest w nagłówki bezpieczeństwa HTTP wyjaśnione dla ludzi, a swoje sprawdzisz w analizatorze nagłówków.
4. Opublikowane source mapy
Source mapy pozwalają zobaczyć oryginalny kod zamiast zminifikowanego. Przydatne do debugowania i zły pomysł na produkcji: oddają Twoją logikę, wewnętrzne ścieżki i komentarze w stylu „TODO: usunąć ten klucz". Next.js wyłącza je domyślnie w przeglądarce (productionBrowserSourceMaps: false); w Vite zależy to od build.sourcemap, które niektóre szablony ustawiają na true. Sprawdź, czy istnieją:
curl -sI https://twojadomena.com/_next/static/chunks/main-abc123.js.map | head -1Jeśli odpowiada 200, są opublikowane. Jeśli potrzebujesz map do śledzenia błędów, wgraj je przy buildzie do swojej usługi monitoringu i nie serwuj ich publicznie.
5. Pliki i ścieżki, które nie powinny odpowiadać
Wszystko w katalogu public/ jest serwowane bez zmian. .env skopiowany tam przez pomyłkę, backup.json, config.yml z danymi logowania: publiczne. Ścieżki API też się liczą: /api/debug, /api/seed czy /api/admin, które AI stworzyła do testów i które zostały na produkcji bez uwierzytelnienia. I ścieżki cron: Vercel wywołuje je z nagłówkiem Authorization zawierającym Twój CRON_SECRET; jeśli nie sprawdzasz go w kodzie, każdy może uruchomić Twoje zaplanowane zadanie.
for p in .env .env.local .git/config config.json backup.zip api/debug api/seed; do
printf "%s -> " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://twojadomena.com/$p"
doneWszystko, co odpowiada 200, zasługuje na spojrzenie.
6. Funkcje bez limitów
Ścieżka API, która wywołuje OpenAI albo wysyła e-maile bez limitowania żądań, to rachunek czekający na odkrycie. Vercel ma firewall z regułami rate limit per IP i tryb wyzwania przeciw botom, który włącza się z panelu bez dotykania kodu. Dla endpointów, które kosztują, dodaj dodatkowo limit per użytkownik we własnej logice i wymagaj sesji.
7. CORS i ciasteczka na ścieżkach API
Jeśli Twoje API odpowiada Access-Control-Allow-Origin: * i do tego używa ciasteczek, każda strona może wykonywać żądania w imieniu Twoich użytkowników. Na Vercelu konfiguruje się to per ścieżka w vercel.json albo w samym handlerze. Wymień dozwolone originy jawnie i nigdy nie łącz wildcarda z poświadczeniami. Szczegóły w źle skonfigurowany CORS.
8. Co Vercel już robi za Ciebie
Żebyś nie tracił czasu: certyfikat TLS jest wystawiany i odnawiany sam, HTTP automatycznie przekierowuje na HTTPS, funkcje działają w izolacji, a logi wdrożeń są rejestrowane. Czego nie robi: nie decyduje za Ciebie, co jest publiczne, jakie nagłówki wysyłasz ani kto może oglądać Twoje podglądy. Ta część należy do Ciebie.
Pięciominutowa checklista
- Żadna zmienna z publicznym prefiksem nie zawiera sekretnego klucza.
- Deployment Protection włączone dla podglądów.
- Nagłówki bezpieczeństwa w
vercel.jsonlubnext.config.js. - Source mapy niedostępne na produkcji.
- Nic wrażliwego w
public/; ścieżki testowe usunięte; cron chroniony swoim sekretem. - Rate limit na ścieżkach, które kosztują.
- CORS z jawnymi originami.
- URL
.vercel.appprzekierowuje na Twoją domenę.
Scanaris sprawdza to za Ciebie
Scanaris sprawdza z zewnątrz Twoje wdrożenie na Vercelu: nagłówki, sekrety w bundle'u, source mapy, wystawione pliki i ścieżki, CORS, ciasteczka i TLS, a dla każdego błędu daje fix prompt do wklejenia w Cursor, Bolt lub v0 z dokładną zmianą w vercel.json lub w Twoim kodzie. To kontrole tylko do odczytu na tym, co już jest publiczne; nigdy nie dotyka Twojego projektu. Ryzyka specyficzne dla platformy są w przewodniku bezpieczeństwa dla Vercela, a jeśli Twoja aplikacja to Next.js, w checkliście Next.js.
Często zadawane pytania
Czy podglądy Vercela są domyślnie prywatne?
Nie. Są publiczne dla każdego, kto ma URL, choć nie są indeksowane przez wyszukiwarki. Włącz Vercel Authentication w Deployment Protection, żeby ograniczyć je do swojego zespołu.
Czy Vercel ustawia nagłówki bezpieczeństwa automatycznie?
Tylko podstawowe, operacyjne. HSTS, X-Frame-Options, Content-Security-Policy i resztę musisz skonfigurować sam w vercel.json lub we frameworku.
Co, jeśli sekretny klucz został już opublikowany z publicznym prefiksem?
Uznaj go za skompromitowany, nawet jeśli usuniesz go z kodu: poprzedni bundle może być w cache'u lub pobrany. Zrotuj klucz w usłudze źródłowej, przenieś go do zmiennej bez prefiksu i wdróż ponownie.