Skaner wewnętrznych odniesień

Jak działa ta kontrola

Scanaris analizuje HTML Twojej strony głównej i przechodzi przez wszystkie elementy z atrybutem src, href lub action: skrypty, obrazy, arkusze stylów, linki, formularze. Dla każdej wartości sprawdza, czy wskazuje na host, który nie powinien istnieć poza Twoją maszyną lub siecią: localhost, 127.0.0.1, 0.0.0.0, prywatne adresy IP 10.x.x.x, 192.168.x.x oraz od 172.16.x.x do 172.31.x.x, a także każdą domenę kończącą się na .local. Jeśli coś znajdzie, otwiera ustalenie o niskiej wadze z pierwszymi odniesieniami. Badany jest tylko początkowy HTML; tego, co JavaScript zbuduje później, tą drogą nie widać.

Dlaczego to ważne

Odniesienie do http://localhost:3000/api/... na produkcji ma dwa skutki. Pierwszy jest funkcjonalny: dla Twojego użytkownika localhost to jego własny komputer, więc ten obraz się nie ładuje, ten formularz wysyła się donikąd, a ten skrypt zawodzi po cichu. Drugi jest informacyjny: mówisz każdemu, że Twoje API działa na porcie 3000, że Twój wewnętrzny backend nazywa się api.firma.local albo że Twoja sieć używa zakresu 10.0.1.x. Nic z tego nie jest samo w sobie luką do wykorzystania, stąd niska waga, ale to elementy, które atakujący odkłada na później, a do tego zdradzają, że wdrożenie wyszło bez przeglądu.

Dlaczego tak się dzieje

Prawie zawsze to adres wpisany ręcznie podczas rozwoju, którego nikt nie zmienił. AI, która wygenerowała projekt, wstawiła http://localhost:8000 do fetch formularza albo do src testowego obrazka, lokalnie działało, więc zostało. Inne przyczyny: deweloperski .env, który trafił do builda produkcyjnego, WordPress migrowany ze środowiska lokalnego bez zaktualizowania adresu strony, albo action formularza skopiowany z przykładu.

Jak to naprawić

• Wynieś adresy z kodu. Baza Twojego API trafia do zmiennej środowiskowej (NUXT_PUBLIC_API_BASE, NEXT_PUBLIC_API_URL, VITE_API_URL) z inną wartością na każde środowisko. Na produkcji platforma (Vercel, Netlify, Railway) wstrzykuje ją podczas builda.
• Używaj ścieżek względnych, gdy zasób mieszka na Twojej własnej domenie: /api/kontakt zamiast http://localhost:3000/api/kontakt. Działają tak samo lokalnie i na produkcji.
• WordPress: zaktualizuj adresy strony w Ustawieniach ogólnych i zamień stare adresy w bazie narzędziem, które respektuje serializację.
• Przeszukaj build przed wdrożeniem. Krok CI, który zawodzi, jeśli skompilowany wynik zawiera te hosty, ucina problem u źródła:

grep -rEl "localhost|127\.0\.0\.1|192\.168\.|\.local\b" dist/ .output/public/ 2>/dev/null

Jeśli pojawi się jakiś plik, jest odniesienie do poprawienia przed publikacją.

Sprawdź, czy naprawione

curl -s https://twojadomena.pl | grep -oE '(src|href|action)="https?://[^"]+"' | grep -iE "localhost|127\.0\.0\.1|0\.0\.0\.0|10\.[0-9]+\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.|\.local\b"

Nic nie powinno się pojawić. Sprawdź też jedną lub dwie podstrony, zwłaszcza te z formularzami.

Często zadawane pytania

To testowy obrazek, którego nikt nie widzi. Czy to ma znaczenie?

Przeglądarka każdego odwiedzającego próbuje załadować go z jego własnego komputera, a HTML nadal ogłasza Twój wewnętrzny host. Zmień go albo usuń; to minuta.

Czy skompilowany JavaScript też jest sprawdzany?

Nie przez tę kontrolę, tylko HTML. Ale wewnętrzny adres w bundle'u zwykle idzie w parze z innymi rzeczami, których nie powinno tam być; sekrety w JavaScript szuka kluczy i tokenów, a komentarze HTML szuka pozostałości w samym HTML-u. Te trzy razem pokrywają to, co zwykle zostaje ze środowiska deweloperskiego.

Mój link celowo wskazuje na domenę .local.

Domeny .local są zarezerwowane dla sieci lokalnych (mDNS) i nie rozwiązują się w internecie. Jeśli chcesz podlinkować wewnętrzne narzędzie, użyj prawdziwej subdomeny z uwierzytelnianiem. To, co Twoja aplikacja wycieka niechcący, z większą liczbą przykładów, jest w sekrety, które Twoja aplikacja wycieka w przeglądarce.