Jak działa ta kontrola
Scanaris wyciąga wszystkie komentarze HTML z Twojej strony głównej, czyli wszystko między <!-- a -->, i szuka w nich sześciu wzorców sekretów. Cztery to rozpoznawalne formaty kluczy: tajne klucze Stripe (sk_live_ i 20 lub więcej znaków), klucze dostępu AWS (AKIA i 16 znaków), klucze API Google (AIza i 35 znaków) oraz nagłówki klucza prywatnego (-----BEGIN PRIVATE KEY----- i warianty RSA lub EC). Dwa pozostałe to jawne przypisania: password, passwd lub pwd z wartością o długości co najmniej 6 znaków, oraz api_key, secret, token lub bearer z wartością o długości co najmniej 16. Jeśli któryś pasuje, otwiera ustalenie o wysokiej wadze wskazujące typ znalezionego sekretu, nigdy wartość. Wzorce są celowo ścisłe: komentarz „tu wstawić token" bez wartości nie jest oznaczany.
Dlaczego to ważne
Komentarze HTML nie są widoczne na stronie, ale są widoczne w kodzie źródłowym, a kod źródłowy widzi każdy przez Ctrl+U albo curl. Nie ma praktycznej różnicy między wstawieniem klucza do komentarza a opublikowaniem go na forum. Tajny klucz Stripe pozwala tworzyć obciążenia i zwroty; klucz AWS, używać Twojego konta i Twojego rachunku; hasło do bazy danych, czytać wszystko. A zautomatyzowani łowcy sekretów przeczesują całą sieć w poszukiwaniu dokładnie tych prefiksów, więc czas między publikacją klucza a jego użyciem liczy się w minutach.
Dlaczego tak się dzieje
Ktoś zostawia sobie notatkę podczas rozwoju („<!-- użytkownik admin / password Tymczasowe2024 -->"), komentuje blok konfiguracji „na próbę" zamiast go usunąć, albo wkleja przykład integracji z prawdziwym kluczem. Szablony WordPressa i ręcznie robione strony statyczne są najbardziej podatne, bo ich komentarze docierają do przeglądarki bez zmian. W nowoczesnych frameworkach zdarza się rzadziej, ale się zdarza: komentarz w statycznym .html w katalogu publicznym albo w komponencie, który nie jest kompilowany.
Jak to naprawić
- Najpierw zrotuj dane dostępowe. Załóż, że już je ktoś przeczytał. Wygeneruj nowe u dostawcy, podmień na serwerze i unieważnij stare. Potem usuń komentarz; nie odwrotnie.
- Przeszukaj projekt przed wdrożeniem, nie tylko stronę główną:
grep -rnE "sk_live_|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|BEGIN (RSA |EC )?PRIVATE KEY|(password|api_key|secret|token)\s*[:=]" --include=*.html --include=*.vue --include=*.php --include=*.hbs .- Usuwaj komentarze na produkcji. Vue i Nuxt usuwają je przy kompilacji; w Next.js komentarze JSX nigdy nie trafiają do HTML-u. Dla statycznego HTML-u lub WordPressa usuwa je minifikator (
html-minifier-terserzremoveComments) albo używana wtyczka optymalizacyjna. W PHP używaj komentarzy PHP (<?php // ... ?>), które nie opuszczają serwera. - Dane dostępowe trzymaj w zmiennych środowiskowych, nigdy w plikach, które są serwowane. I dodaj do repozytorium detektor sekretów (
gitleaksalbo skanowanie sekretów GitHuba), żeby nie wróciły.
Sprawdź, czy naprawione
curl -s https://twojadomena.pl | tr -d '\n' | grep -oE '<!--.{0,200}' | grep -iE "sk_live_|AKIA|AIza|PRIVATE KEY|password|api_key|secret|token|bearer"Nic nie powinno się pojawić. Idealnie, żeby pierwsza część, bez ostatniego filtra, też nie zwracała komentarzy: na produkcji nie są potrzebne.
Często zadawane pytania
To klucz testowy, nie produkcyjny.
Wzorce to rozróżniają: sk_test_ Stripe nie jest oznaczany, sk_live_ tak. Jeśli ustalenie się pojawiło, format pasuje do prawdziwego klucza albo do jawnego przypisania hasła. Jeśli to naprawdę wartość zastępcza, zmień ją na coś, co nie wygląda jak dane dostępowe, np. DO_ZAMIANY.
Czy komentarze w JavaScript też są sprawdzane?
Ta kontrola patrzy tylko na HTML. Kluczy w bundle'ach JavaScript, z komentarzem czy bez, szuka sekrety w JavaScript, a odniesień do hostów wewnętrznych odniesienia wewnętrzne. Co jeszcze wycieka niechcący, jest w sekrety, które Twoja aplikacja wycieka w przeglądarce.
Czy liczą się komentarze warunkowe Internet Explorera?
To komentarze HTML i są analizowane tak samo, ale nie zawierają sekretów i nie są oznaczane. Mimo to w 2026 roku są zbędne: żadna wspierana przeglądarka ich nie interpretuje.