Nie musisz być ekspertem od bezpieczeństwa, żeby wiedzieć, czy Twoja strona ma najczęstsze błędy. Z przeglądarką, terminalem i pięcioma minutami możesz sprawdzić to, co zautomatyzowany atakujący próbuje w pierwszych sekundach: czy ruch jest szyfrowany, czy brakuje nagłówków, czy w kodzie są klucze, czy Twoje API akceptuje żądania skądkolwiek i czy są pliki, których nie powinno tam być. Ten przewodnik prowadzi Cię krok po kroku, z dokładnym poleceniem, znaczeniem każdego wyniku i tym, co zrobić w zależności od tego, co znajdziesz. Na końcu masz, jak priorytetyzować i czego ten test nie wykrywa.
Minuta 1: HTTPS i przekierowanie
Wpisz swoją domenę z http:// na początku, bez „s". Powinno od razu przenieść Cię do wersji https://. Z terminala:
curl -sI http://twojadomena.com | head -3
curl -sI http://twojadomena.com/cennik | head -3Obie odpowiedzi muszą być 301 z Location: https://.... Jeśli druga nie przekierowuje, Twoje przekierowanie obejmuje tylko stronę główną. Potem, z https://, sprawdź, czy pojawia się nagłówek Strict-Transport-Security: mówi przeglądarce, żeby nie używała już HTTP. Jeśli jesteś na Vercelu, Netlify lub Cloudflare, przekierowanie jest już ustawione, a HSTS musisz dodać sam. Co oznacza każdy szczegół certyfikatu, w co naprawdę oznacza Twoja ocena TLS.
Minuta 2: nagłówki bezpieczeństwa
curl -sI https://twojadomena.com | grep -iE "strict-transport|content-type-options|frame-options|referrer-policy|content-security-policy|permissions-policy"Powinno wyjść co najmniej pięć linii. Każda brakująca to ochrona, której przeglądarka nie może zastosować: bez X-Frame-Options Twoją stronę można osadzić w innej, żeby oszukać Twoich użytkowników; bez X-Content-Type-Options przeglądarka zgaduje typy plików; bez Content-Security-Policy każdy wstrzyknięty skrypt wykonuje się bez hamulca. Jeśli nie lubisz terminala, wklej swój URL do analizatora nagłówków. Znaczenie każdego z nich w nagłówki HTTP wyjaśnione dla ludzi.
Minuta 3: sekrety w JavaScripcie
Otwórz swoją stronę, prawy przycisk, „Pokaż źródło strony". Poszukaj .js, żeby zobaczyć, jakie pliki skryptów ładuje, otwórz główny i użyj wyszukiwarki przeglądarki z tymi hasłami:
sk_live sk_test service_role AKIA eyJhbGci api_key apiKey secret passwordZ terminala możesz to zrobić za jednym zamachem na wszystkich skryptach strony głównej:
curl -s https://twojadomena.com/ | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | while read s; do
case "$s" in http*) u="$s";; /*) u="https://twojadomena.com$s";; *) u="https://twojadomena.com/$s";; esac
curl -s "$u" | grep -oE "sk_live_[A-Za-z0-9]+|service_role|AKIA[A-Z0-9]{16}|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
doneNiektóre rzeczy znaleźć to normalne: klucz publiczny Stripe (pk_live), klucz anon Supabase czy konfiguracja Firebase są zaprojektowane, żeby być w przeglądarce. Co nigdy nie może się pojawić: sk_live, service_role, klucze AWS (AKIA), tokeny OpenAI ani nic, co nazywa się secret. Jeśli coś takiego znajdziesz, uznaj to za skompromitowane i zrotuj, zanim usuniesz z kodu. Pełna lista jest w sekrety, które Twoja aplikacja wycieka w przeglądarce.
Minuta 4: CORS i ciasteczka
CORS decyduje, które inne strony mogą z przeglądarki wysyłać żądania do Twojego API. Poproś o jeden ze swoich endpointów, udając, że przychodzisz z innej domeny:
curl -sI -H "Origin: https://evil.example" https://twojadomena.com/api/me | grep -i "access-control"Jeśli odpowiada Access-Control-Allow-Origin: https://evil.example albo * razem z Access-Control-Allow-Credentials: true, każda strona może czytać dane Twoich użytkowników z ich sesją. Dozwolony origin musi być Twój i tylko Twój. Skoro już tu jesteś, spójrz na ciasteczka w odpowiedzi logowania albo w narzędziach przeglądarki: sesyjne potrzebują Secure, HttpOnly i SameSite=Lax lub Strict. Szczegóły w źle skonfigurowany CORS.
Minuta 5: wystawione pliki
Narzędzia i niedokończone wdrożenia zostawiają ślady. Sprawdź te ścieżki i zobacz, jaki kod zwracają:
for p in .env .env.local .env.production .git/config .DS_Store config.json backup.zip database.sql phpinfo.php server-status api/debug api/seed swagger.json; do
printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://twojadomena.com/$p"
doneChcesz widzieć 404 (albo 301 na swoją stronę błędu). 200 na .env lub .git/config to poważna sprawa: pierwszy zawiera Twoje dane logowania, a drugi pozwala pobrać cały kod źródłowy. 200 na swagger.json lub api/debug nie jest wyciekiem samym w sobie, ale daje atakującemu mapę Twojego API.
Dodatkowa minuta: co widzą boty
Jeśli zostaje Ci minuta, zajrzyj do /robots.txt i /sitemap.xml: czy istnieją, czy nie blokują wszystkich i czy sitemapa ma tylko strony, które chcesz indeksować. To nie bezpieczeństwo w ścisłym sensie, ale zapomniane z fazy testów Disallow: / kosztuje miesiące pozycjonowania.
Jak priorytetyzować to, co znajdziesz
Nie wszystko waży tyle samo. Oto kolejność, której używamy:
- Krytyczne, dziś. Sekretny klucz w JavaScripcie; dostępne
.envlub.git; API akceptujące dowolny origin z poświadczeniami. Zrotuj, usuń, zamknij. Potem sprawdź, czy ktoś z tego skorzystał. - Wysokie, w tym tygodniu. Brak przekierowania na HTTPS; ciasteczka sesyjne bez
HttpOnlylubSecure; ścieżki debugowe na produkcji. - Średnie, w tym miesiącu. Brakujące nagłówki; brak HSTS; certyfikat wygasający wkrótce bez automatycznego odnawiania.
- Niskie. Wystawiona dokumentacja API, zaniedbane
robots.txtisitemap, nagłówki zdradzające wersję serwera.
Czego te pięć minut nie wykrywa
Bądź szczery co do ograniczeń. Ten test patrzy na powierzchnię, którą każdy może zobaczyć z zewnątrz. Nie sprawdza, czy Twoja baza danych pozwala czytać wiersze innych użytkowników (w Supabase to RLS, w Firebase reguły), czy Twoje zależności mają znane podatności, czy Twoja logika biznesowa pozwala pominąć płatność ani czy formularz akceptuje dowolne dane wejściowe. Co do pierwszego, przewodnik po Supabase i ten o Firebase wyjaśniają, jak to przetestować. Reszta wymaga zajrzenia w kod, a checklista przed startem zbiera to, co najważniejsze.
Scanaris robi to i czterdzieści innych rzeczy w 30 sekund
Pięć powyższych kroków to rdzeń tego, co sprawdza Scanaris, plus około czterdziestu testów, które nie mieszczą się w pięciu minutach: każdy nagłówek osobno, sekrety według wzorców dziesiątek usług, wystawione pliki z dużo dłuższą listą, pełny TLS, ciasteczka, CORS na kilku ścieżkach, a do tego stan Twojego SEO i widoczności dla AI. Dla każdego błędu dostajesz fix prompt do wklejenia w Lovable, Bolt, Cursor lub v0 z dokładną zmianą, a skan może powtarzać się codziennie i ostrzegać Cię, jeśli coś się pogorszy. Wszystko to kontrole tylko do odczytu na tym, co już jest publiczne na Twojej stronie.
Często zadawane pytania
Czy skanowanie własnej strony w ten sposób jest legalne?
Tak. Wszystko tutaj to zwykłe żądania, jakie wykonuje każda przeglądarka; czytasz tylko to, co Twój serwer i tak odpowiada każdemu. Rób to wyłącznie na własnych domenach albo za zgodą.
A jeśli nie umiem używać terminala?
Kroki 1, 3 i 5 da się zrobić z przeglądarki (wpisywanie URL-i i podgląd źródła), krok 2 darmowym analizatorem nagłówków, a krok 4 to jedyny, który go wymaga. Albo pozwól, żeby skaner zrobił to za Ciebie.
Jak często powtarzać?
Przy każdym istotnym wdrożeniu i co najmniej raz w miesiącu. Aplikacje tworzone przez AI zmieniają się szybko, a ponowne wygenerowanie kodu może przywrócić błąd, który już naprawiłeś.