← Poradniki stacków

v0

Bezpieczeństwo Twojej aplikacji v0

v0 generuje piękne interfejsy w React i Next.js, ale skupia się na frontendzie: bezpieczeństwo backendu jest po Twojej stronie. To właśnie tędy przemykają odsłonięte klucze, niezabezpieczone fetche i „ukryte” przyciski, które niczego nie chronią. Przeskanuj aplikację i sprawdź to.

Typowe ryzyka przy v0

Fetch po stronie klienta z kluczem na widoku

Kod, który generuje v0, często wywołuje API bezpośrednio z komponentu. Jeśli takie wywołanie niesie klucz, wędruje on do przeglądarki i każdy odczyta go w DevTools.

Akcje, które nigdy nie sprawdzają sesji

v0 ukrywa przycisk, gdy nie powinieneś go widzieć, ale nie waliduje sesji po stronie serwera. Akcja nadal jest publicznym URL-em, który każdy może wywołać bezpośrednio.

Brak nagłówków i CSP domyślnie

Skoro to kod stawiający UI na pierwszym miejscu, to, co wychodzi z v0, jedzie bez nagłówków bezpieczeństwa i bez Content-Security-Policy. Musisz je skonfigurować tam, gdzie wdrażasz.

„Bezpieczeństwo v0" to dwie rzeczy, które warto rozdzielić. Pierwsza to projekt w v0: kto może widzieć Twoje czaty, gdzie żyją zmienne środowiskowe, co dodają integracje i gdzie trafia wdrożenie. Druga to kod, który v0 generuje: bardzo dopracowane interfejsy Next.js, które z założenia skupiają się na tym, co widać, a odkładają na później to, czego nie widać, czyli właśnie uwierzytelnianie, walidację i nagłówki. Ten przewodnik obejmuje obie, z blokiem instrukcji dla projektu, promptem do przeglądu przed wdrożeniem i kontrolami z zewnątrz. Model tego, co działa na serwerze, a co trafia do przeglądarki, jest w przewodniku po Next.js.

Część 1: zabezpieczenie projektu w v0

Czaty publiczne i prywatne

Czat w v0 można udostępnić linkiem albo opublikować w społeczności i w obu przypadkach pokazuje on pełny kod i historię promptów, łącznie z każdym kluczem wklejonym do rozmowy i nazwami Twoich zmiennych środowiskowych. Sprawdź widoczność każdego czatu przed udostępnieniem i załóż, że wszystko, co napisałeś w publicznym czacie, ktoś już przeczytał.

Zmienne środowiskowe i integracje

v0 ma panel zmiennych środowiskowych per projekt, używany w podglądzie i synchronizowany z Vercelem przy wdrożeniu. To jedyne miejsce na klucze: nigdy czat, nigdy plik w kodzie. Integracje (Supabase, Neon, Upstash, Blob i pozostałe z marketplace'u Vercela) dodają tam swoje zmienne automatycznie; te zaczynające się od NEXT_PUBLIC_ trafiają do przeglądarki, pozostałe tylko na serwer. Jeśli sekretny klucz ma ten prefiks, jest wystawiony, choć wpisałeś go w panelu.

Podgląd i wdrożenie

Podgląd w v0 uruchamia Twoją aplikację z prawdziwymi zmiennymi. Wdrożenie idzie na Vercel, ze wszystkim, co z tego wynika: domyślnie publiczne podglądy, zmienne per środowisko, firewall i ochrona wdrożeń. Przewodnik po Vercelu to omawia; pierwsza rzecz do włączenia to Deployment Protection.

Jeśli podłączasz bazę danych

Z Supabase, Neon czy dowolnym Postgresem tabele tworzone przez v0 rodzą się bez polityk dostępu i ze schematem, który wymyślił model. Jeśli to Supabase, przewodnik po Supabase ma trzy zapytania SQL do audytu w minutę; przy innych bazach dostęp kontroluje Twój kod serwerowy i obowiązują reguły z części 2.

Część 2: błędy, które v0 wkłada do Twojego kodu

  • Brak uwierzytelniania. v0 buduje panel, tabelę i przyciski; logowanie przychodzi „w następnym prompcie" albo nigdy. Wdrożona aplikacja z panelem bez sesji jest w całości publiczna.
  • Dane przykładowe, które zostają. Fikcyjni użytkownicy, klucze testowe i admin / admin w pliku z danymi, który ląduje na produkcji.
  • fetch z komponentu z kluczem w środku. Wywołanie zewnętrznego API siedzi w komponencie klienckim, z kluczem widocznym w narzędziach przeglądarki.
  • Server Actions i Route Handlers bez sprawdzania sesji. Przycisk jest ukryty, jeśli nie jesteś adminem, ale akcja pozostaje endpointem, który każdy może wywołać.
  • Ładne formularze bez walidacji serwerowej. Pole ma reguły po stronie klienta; akcja przyjmuje, co przyjdzie.
  • dangerouslySetInnerHTML dla bogatej treści. Idealne na demo, XSS na produkcji, jeśli treść pisze użytkownik.
  • Zdalne obrazy z wildcardem. remotePatterns z hostname: '**', żeby „każdy obraz działał".
  • Bez nagłówków i CSP. next.config wychodzi z generowania pusty.

Blok instrukcji dla projektu

Wklej go do instrukcji projektu w v0 albo, jeśli z nich nie korzystasz, na początek pierwszego promptu, żeby obowiązywał we wszystkich generowaniach:

Reguły bezpieczeństwa tego projektu:
- Każda strona panelu i każda akcja czytająca lub zapisująca dane sprawdza sesję na serwerze. Jeśli nie ma systemu uwierzytelniania, zbuduj go przed jakimkolwiek panelem.
- Wywołania usług z kluczem idą do Route Handlers lub Server Actions, nigdy do komponentów klienckich. Żaden sekretny klucz nie ma prefiksu NEXT_PUBLIC_.
- Każda Server Action i każdy Route Handler waliduje dane wejściowe schematem, zanim dotknie danych.
- Przekazuj komponentom klienckim tylko potrzebne pola, nigdy cały obiekt użytkownika.
- Żadnych danych przykładowych z poświadczeniami; jeśli potrzebne są dane testowe, oznacz je i powiedz mi, żebym usunął je przed wdrożeniem.
- Nie używaj dangerouslySetInnerHTML z treścią użytkownika.
- images.remotePatterns wymienia konkretne domeny. next.config definiuje nagłówki bezpieczeństwa i nie włącza productionBrowserSourceMaps.

Prompt do przeglądu przed wdrożeniem

Przejrzyj bezpieczeństwo tego projektu i na razie niczego nie zmieniaj. Odpowiedz listą:
1. Strony, Server Actions i Route Handlers, które czytają lub zapisują dane bez sprawdzania sesji.
2. Komponenty klienckie wywołujące zewnętrzne usługi z kluczem oraz zmienne NEXT_PUBLIC_ zawierające sekretne klucze.
3. Dane przykładowe, poświadczenia lub klucze testowe w kodzie.
4. Akcje bez walidacji danych wejściowych i użycia dangerouslySetInnerHTML.
5. remotePatterns z wildcardem, brak nagłówków bezpieczeństwa i włączone productionBrowserSourceMaps.
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|content-security|x-frame|x-content-type"
curl -s -o /dev/null -w "%{http_code}\n" https://twojadomena.com/dashboard
curl -s https://twojadomena.com | grep -oE '/_next/static/chunks/[^"]+\.js' | head -3

Oczekiwane: obecne nagłówki i przekierowanie (302 lub 307) do logowania w drugiej linii; 200 oznacza, że panel jest publiczny. Otwórz chunki z trzeciego polecenia i poszukaj sk_, Bearer i nazw Twoich usług. Scanaris wykonuje te kontrole i około czterdziestu innych w 30 sekund: wykrywa, że aplikacja to Next.js wdrożony na Vercelu, szuka sekretów w chunkach, sprawdza source mapy, nagłówki, CSP, ciasteczka, CORS i wystawione pliki, weryfikuje metadane i daje fix prompt dla każdego błędu do wklejenia w v0. I może skanować ponownie codziennie, bo ponowne wygenerowanie może przywrócić naprawiony błąd.

Często zadawane pytania

Czy kod z v0 jest gotowy na produkcję?

Interfejs tak; bezpieczeństwo nie jest w pakiecie. Zanim wdrożysz coś z prawdziwymi danymi, potrzebuje uwierzytelniania, walidacji serwerowej i nagłówków, czyli tego, co omawiają blok i prompt powyżej.

Czy wdrożenie z v0 czyni moją aplikację prywatną?

Nie. Wdrożenie jest publiczne jak każde inne na Vercelu, podglądy też. Prywatność dają Twój system sesji i Deployment Protection.

Co zrobić, jeśli wkleiłem klucz do czatu?

Zrotuj go w usłudze źródłowej, nawet jeśli go usuniesz: czat go zachowuje, a jeśli był publiczny, każdy już go widział. Potem dodaj go w panelu zmiennych środowiskowych i poproś v0 o przeniesienie wywołania na serwer.

Powiązane testy

Czy twoja aplikacja v0 przechodzi te testy?

Przeskanuj ją za darmo i otrzymaj prompt naprawczy dla każdego znalezionego problemu.

Przeskanuj moją stronę za darmo