Skanowanie swagger.json – ciche zagrożenie dla API firm. Jakie kroki podjąć?
Atakujący od lat skanują internet w poszukiwaniu plików swagger.json, które zdradzają strukturę API. Dla firm to ryzyko wycieku danych i ułatwienie ataku. Eksperci radzą, jak prewencyjnie identyfikować i zabezpieczać te zasoby.
Pliki swagger.json, będące sercem standardu OpenAPI, to dla programistów wygodny sposób opisywania interfejsów aplikacji. Dla atakujących to jednak gotowa mapa ataku – pokazuje wszystkie dostępne endpointy, parametry i metadane aplikacji. Jak wynika z danych SANS Internet Storm Center, skanowanie w poszukiwaniu tych plików trwa nieprzerwanie od lat, a liczba żądań sięga dziesiątek tysięcy. Dla polskich firm, szczególnie tych pracujących nad API i rozwiązaniami AI, to sygnał, by przyjrzeć się własnej infrastrukturze.
Czym jest swagger.json i dlaczego atakujący go szukają?
Swagger, obecnie rozwijany jako OpenAPI, to zestaw narzędzi do projektowania, budowania i dokumentowania interfejsów REST. Kluczowym elementem jest plik swagger.json, który definiuje wszystkie dostępne ścieżki, metody, parametry oraz typy danych. Johannes Ullrich, dziekan ds. badań w SANS, opisuje go jako „swego rodzaju listing katalogu dla API” – nie jest sam w sobie złośliwy, ale stanowi doskonałą mapę drogową dla atakujących.
Dlaczego jest tak cenny? Pozwala szybko zidentyfikować nie tylko strukturę aplikacji, ale często też wersję oprogramowania, co może ujawnić podatności. Co więcej, wiele firm nie zdaje sobie sprawy, że plik jest publicznie dostępny – bywa domyślnie publikowany przez frameworki lub pozostawiony po testach.
Skala zjawiska – dziesiątki tysięcy żądań
SANS ISC odnotowuje stały, wysoki poziom zainteresowania atakujących. Najczęściej skanowany jest adres /swagger.json – od grudnia 2020 roku do czerwca 2026 roku zarejestrowano ponad 32 tysiące żądań. Kolejne popularne ścieżki to /api/v2/swagger.json (14,5 tys.) oraz /swagger/v1/swagger.json (13,8 tys.). Co istotne, pojawiają się też nowe warianty, np. z kodowaniem procentowym czy nietypowymi prefiksami, co świadczy o ciągłym dostosowywaniu technik.
Badacze obserwują fale wzmożonego skanowania, ale ogólna liczba żądań utrzymuje się na wysokim poziomie przez lata. Jak komentuje Ullrich:
„Ciągłe zainteresowanie pokazuje, że atakujący widzą w tym wartość.”
Oznacza to, że każde publicznie dostępne API jest potencjalnym celem.
Jak się bronić? Cztery praktyczne kroki
Eksperci nie zalecają rezygnacji ze swagger.json – jest on potrzebny programistom. Zamiast tego proponują działania defensywne:
- Preemptywne skanowanie własnych zasobów. Zespoły bezpieczeństwa powinny regularnie przeszukiwać swoją infrastrukturę pod kątem nieautoryzowanych plików swagger.json. Narzędzia takie jak crawler lub skaner sieciowy mogą pomóc w identyfikacji przypadkowo opublikowanych dokumentów.
- Ograniczenie dostępu. Jeśli plik jest niezbędny, warto umieścić go za uwierzytelnianiem lub ograniczyć do zaufanych sieci. W żadnym wypadku nie powinien być dostępny bez autoryzacji z poziomu publicznego internetu.
- Minimalizacja metadanych. W pliku swagger.json często znajdują się dane o wersji aplikacji, serwerze czy frameworku – warto usuwać te informacje przed publikacją, by utrudnić atakującym identyfikację potencjalnych podatności.
- Monitorowanie żądań. Włączenie logowania i alertów dla nietypowych zapytań do ścieżek API może pomóc w szybkim wykryciu skanowania. Telemetria z warstwy API powinna trafiać do SIEM lub SOAR, co ułatwi analizę.
Większy kontekst – bezpieczeństwo API w dobie AI
Kwestia zabezpieczenia swagger.json wpisuje się w szersze wyzwanie, jakim jest ochrona API, szczególnie w środowiskach wykorzystujących sztuczną inteligencję. Joshua Goldfarb, Field CISO w F5, w swoim artykule dla SecurityWeek podkreśla, że podstawą jest widoczność: „Nie możemy bronić czegoś, czego nie widzimy”. To samo dotyczy API – zespół bezpieczeństwa musi wiedzieć, które interfejsy są wystawione i jakie niosą ryzyko.
Goldfarb wymienia też konieczność budowania zaufania między zespołem bezpieczeństwa a deweloperami, a także wdrażania zarówno kontroli prewencyjnych (np. ograniczenia dostępu, uwierzytelnianie), jak i detekcyjnych (monitoring, alerty). W przypadku API, które często stanowią bramę do systemów AI i CI/CD, te praktyki są szczególnie istotne. Polskie firmy, które wdrażają rozwiązania oparte na API, powinny potraktować skanowanie swagger.json jako sygnał do przeglądu własnych procedur.
Podsumowując: zagrożenie jest realne, ale przede wszystkim stanowi dobrą okazję do poprawy higieny bezpieczeństwa. Zamiast panikować, warto systematycznie sprawdzać swoją ekspozycję i wdrażać proste, ale skuteczne zabezpieczenia.
