TL; DR
Większość naruszeń bezpieczeństwa interfejsu API wynika z błędnego uwierzytelnienia, a nie z egzotycznych exploitów. Trzy z pięciu najważniejszych kategorii OWASP API Security Top 10 to błędy autoryzacji, na czele z BOLA.
Nie możesz zabezpieczyć czegoś, o czym nie wiesz, że istnieje. Niewłaściwe zarządzanie zapasami jest to odrębna kategoria ryzyka OWASP i fundament, na którym opiera się każda inna kontrola.
Wykryj narażenie przed wdrożeniem, a nie po nim. Statyczna analiza kodu i specyfikacji API pozwala wykryć uszkodzony punkt końcowy w pull request, za cenę jednego commit; testy w czasie rzeczywistym wykrywają ten sam problem w czasie rzeczywistym, za cenę incydentu.
Oto lista kontrolna, którą należy stosować w sposób ciągły. Na każdym pull request, nie jest to recenzja przedpremierowa: 10 praktykiod inwentaryzacji i autoryzacji po ograniczanie przepustowości, ujawnianie danych odpowiedzi i zaufanie stron trzecich.
Powierzchnia ataku Twojego API rośnie z każdym pull requestWiększość zespołów dowiaduje się, że punkt końcowy jest narażony dopiero wtedy, gdy jest aktywny i odbiera ruch, co oznacza, że naprawa, która kosztowałaby jednego commit W przeglądzie obecnie kosztują raporty o incydentach. Ten przewodnik omawia najlepsze praktyki bezpieczeństwa API, które faktycznie sprawdzają się w środowisku produkcyjnym, zorganizowane w formie listy kontrolnej, którą można uruchomić na własnej bazie kodu już dziś, a nie listy abstrakcyjnych zasad, których nikt nie wdraża.
Dlaczego najlepsze praktyki bezpieczeństwa API wyglądają teraz inaczej
Kiedyś interfejsy API były tkanką łączną między systemami. Teraz stanowią główny interfejs dla niemal wszystkiego: aplikacji mobilnych, integracji partnerskich, agentów AI i wewnętrznych mikrousług. Ta zmiana zmieniła to, co muszą obejmować najlepsze praktyki ochrony interfejsów API. Nie wystarczy już zabezpieczyć udokumentowane API; trzeba uwzględnić te, które zespoły utworzyły i zapomniały zapisać.
Dwie liczby wyjaśniają, dlaczego to jest ważne. Bezpieczeństwo API OWASP Top 10 Umieszcza problemy z niedziałającą autoryzacją w trzech z pięciu najważniejszych kategorii, co oznacza, że większość rzeczywistych incydentów API wynika z kilku możliwych do uniknięcia wzorców, a nie z egzotycznych błędów typu zero-day. Niewłaściwe zarządzanie zasobami znajduje się na tej samej liście, co własna kategoria ryzyka: zespoły padają ofiarą włamań przez API, o których nie wiedziały, że nadal działają.
To motyw przewodni przewijający się przez każdy z poniższych punktów. Dobre praktyki zarządzania API zaczynają się od znajomości tego, co się ma, a nie tylko od obrony tego, co zostało udokumentowane.
Najlepsze praktyki bezpieczeństwa API w skrócie
Zanim przejdziemy do szczegółowej listy kontrolnej, przedstawiamy jej skróconą wersję: co wdrożyć, przed czym to właściwie chroni i jak pilnie to zrobić.
Traktuj wiersz „Wymagane” jako niepodlegającą negocjacjom linię bazową dla dowolnego API, wewnętrznego lub publicznego. Elementy o „wysokim” priorytecie to elementy, które wyróżniają program, który wykrywa problemy w pull request od tego, który dowiaduje się o tym z raportu incydentu.
Lista kontrolna najlepszych praktyk bezpieczeństwa API
1. Zbuduj kompletny inwentarz, zanim zaczniesz budować obronę
Nie da się chronić punktu końcowego, o którego istnieniu się nie wie. Rozpocznij każde działanie w ramach najlepszych praktyk ochrony API od rzetelnego spisu: każdego punktu końcowego, jego metody, ścieżki, usługi i modułu, do których należy, oraz informacji o tym, czy wymaga uwierzytelnienia. Należy to zebrać z kodu źródłowego i specyfikacji API (OpenAPI, Swagger), a nie tylko z dokumentacji, ponieważ luka między nimi to właśnie miejsce, w którym ukrywają się zapomniane i osierocone punkty końcowe.
Gdzie pasuje Xygeni: Bezpieczeństwo interfejsu API Xygeni buduje ten inwentarz bezpośrednio na podstawie kodu źródłowego Twojej aplikacji i specyfikacji API, wyświetlając punkty końcowe udokumentowane przez Twój zespół i te, których nikt nie udokumentował, zanim którykolwiek z nich trafi do produkcji.
2. Wymuszaj autoryzację na poziomie obiektu i funkcji
Złamana autoryzacja na poziomie obiektów i funkcji stale znajduje się na szczycie listy 10 najbezpieczniejszych rozwiązań API OWASP. Najlepszą praktyką nie jest „dodawanie uwierzytelniania”, lecz sprawdzanie przy każdym żądaniu, czy ten konkretny użytkownik ma prawo dostępu ten konkretny obiekt, a nie tylko to, czy w ogóle jest zalogowany. Uwierzytelnianie pozwala ustalić, kim jest dana osoba. Autoryzacja pozwala ustalić, czego może dotykać, i musi być sprawdzana za każdym razem, a nie zakładana z prawidłowego tokena.
3. Zweryfikuj i zdezynfekuj wszystko, co otrzymuje API
Każdy parametr, nagłówek i pole treści są danymi wejściowymi, które nie są wiarygodne, dopóki nie zostanie udowodnione inaczej. Wymuszaj ścisłą walidację schematu, odrzucaj nieoczekiwane pola (to Twoja obrona przed masowym przypisaniem) i nigdy nie ufaj danym dostarczanym przez klienta w celu ustalenia zakresu dostępu lub logiki cenowej.
4. Ograniczenie przepustowości i dławienie są celowe, a nie dodane na końcu
Nieograniczone zużycie zasobów pozwala pojedynczemu klientowi wyczerpać infrastrukturę lub generować koszty usług back-endowych w modelu płatności za użytkowanie. Ustaw limity dla każdego punktu końcowego, użytkownika i klucza API i upewnij się, że limity skalują się wraz z rzeczywistym kosztem operacji, a nie są stałą kwotą stosowaną wszędzie.
5. Traktuj każdą odpowiedź jako potencjalny wyciek danych
Nadmierne ujawnienie danych ma miejsce, gdy API zwraca więcej danych niż potrzebuje klient i polega na filtrowaniu ich przez front-end. To nawyk, a nie rzadki błąd, i jedno z najczęstszych naruszeń dobrych praktyk ochrony API, ponieważ pozostaje niewidoczne, dopóki ktoś nie sprawdzi surowych odpowiedzi zamiast renderowanego interfejsu użytkownika.
Gdzie pasuje Xygeni: Rozwiązanie Xygeni API Security sygnalizuje ujawnienie danych osobowych bezpośrednio w odpowiedziach API. Dzięki temu można wykryć nadmierne udostępnianie informacji jeszcze przed ich wysłaniem, a nie dopiero po zauważeniu tego przez klienta lub organ regulacyjny.
6. Prowadź dokładny i aktualny spis interfejsów API, w tym tych wycofanych
Niewłaściwy inwentarz Zarządzanie API to odrębna kategoria na liście OWASP nie bez powodu: przestarzałe wersje API i nieudokumentowane środowiska testowe są często nadal dostępne i podatne na ataki, długo po tym, jak ktokolwiek przypomni sobie o ich istnieniu. Program najlepszych praktyk zarządzania API musi obejmować wycofywanie z eksploatacji, a nie tylko wykrywanie.
7. Sprawdź, jakim zaufaniom pod względem informacji od stron trzecich poddaje się Twoje API
Niebezpieczne korzystanie z interfejsów API innych firm to niedoceniane ryzyko. Programiści mają tendencję do ufania danym pochodzącym z innego interfejsu API bardziej niż danym wprowadzanym przez użytkownika, co jest dokładnie odwrotne; integracja z interfejsem innej firmy to nadal zewnętrzne, niezweryfikowane źródło i powinna być weryfikowana w ten sam sposób.
8. Przedstawiaj deweloperom dowody, a nie tylko alerty
Wynik informujący o „uszkodzonej autoryzacji na tym punkcie końcowym” to zgłoszenie, które ktoś musi zbadać, zanim w ogóle zacznie naprawiać problem. Wynik wskazujący na konkretny plik, klasę, metodę i wiersz to coś, na co programista może zareagować natychmiast. To najlepsza praktyka dla samego programu bezpieczeństwa, a nie tylko dla interfejsu API: wyniki wymagające zbadania przed podjęciem działań naprawczych spowalniają cały proces.
Gdzie pasuje Xygeni: każde odkrycie dotyczące bezpieczeństwa interfejsu API Xygeni wskazuje na dokładny program obsługi, plik, klasę, metodę i wiersz, który je wprowadził, więc naprawa rozpoczyna się w momencie znalezienia odkrycia.
9. Znajdź narażenie przed wdrożeniem, a nie po nim
Testowanie API w czasie wykonywania informuje, że punkt końcowy jest narażony na atak, gdy obsługuje już ruch. Statyczna analiza kodu i specyfikacji API ujawnia to samo narażenie, gdy punkt końcowy nadal znajduje się w pull request, gdy naprawa kosztuje jednego commit Zamiast reagowania na incydenty. Najlepsze praktyki zarządzania API traktują statyczne wykrywanie jako pierwszą warstwę, a testowanie w czasie wykonywania jako drugą, uzupełniającą kontrolę tego, co już działa.
Gdzie pasuje Xygeni: Bezpieczeństwo interfejsu API Xygeni jest statyczne z założenia, analizuje kod i specyfikacje przed wydaniem i działa równolegle Xygeni DAST do pokrycia czasu wykonania aplikacji znajdujących się już w produkcji.
10. Utrzymuj ryzyko API na tym samym poziomie, co ryzyko związane z resztą aplikacji
Interfejsy API nie zawodzą w izolacji. Luka w zabezpieczeniach interfejsu API często wynika z problemu z zależnościami, błędnej konfiguracji pipelinelub wyciek tajnego dokumentu. Traktowanie bezpieczeństwa API jako osobnego narzędzia z własną konsolą oznacza utratę tego kontekstu dokładnie wtedy, gdy jest to najbardziej potrzebne.
Gdzie pasuje Xygeni: Bezpieczeństwo API znajduje się obok SAST, SCA, Sekrety, IaCi DAST na jednej platformie Xygeni, dzięki czemu wynik API jest widoczny obok kodu i ryzyka zależności, które go wygenerowało, a nie w oddzielnym login.
Zmiana listy kontrolnej w nawyk
Najlepsze praktyki bezpieczeństwa API działają wyłącznie w ramach praktyki ciągłej, a nie przeglądu przed uruchomieniem. Przeprowadź inwentaryzację i analizę statyczną przy każdym pull request, a nie raz na kwartał. Traktuj nowy, nieudokumentowany punkt końcowy tak samo, jak traktujesz nową, nieudokumentowaną zależność: jako coś do natychmiastowego zbadania, a nie doraźnego. I mierz swoje najlepsze praktyki ochrony API w taki sam sposób, w jaki mierzysz każdą inną część. SDLC, na podstawie tego, jak wcześnie wykryjesz problem, a nie tego, czy w ogóle go wykryłeś.
Szybkie odpowiedzi: Pytania i odpowiedzi dotyczące najlepszych praktyk w zakresie bezpieczeństwa API
Na wynos
- Zapasy są ważniejsze od obrony. Nie można stosować autoryzacji, limitów przepustowości ani kontroli danych do punktu końcowego, o którego istnieniu się nie wie. Niewłaściwe zarządzanie inwentarzem stanowi odrębne ryzyko wymienione w raporcie OWASP API Security Top 10.
- Większość naruszeń bezpieczeństwa dotyczy nie tylko uwierzytelniania, ale również autoryzacji. Trzy z pięciu największych zagrożeń bezpieczeństwa API OWASP to błędy autoryzacji. Sprawdzenie, kim ktoś jest, to nie to samo, co sprawdzenie, czego może używać.
- Analiza statyczna wychwytuje to, co testy wykonawcze wychwytują zbyt późno. Znalezienie ekspozycji w pull request kosztuje jeden commitZnalezienie go w produkcji wiąże się z kosztami incydentu.
- Każda odpowiedź jest potencjalnym wyciekiem danych. Nadmierne ujawnianie danych to nawyk, a nie rzadki błąd, i pozostaje niewidoczne, dopóki ktoś nie sprawdzi surowych odpowiedzi API zamiast renderowanego interfejsu użytkownika.
- Najlepsze praktyki bezpieczeństwa API działają tylko jako stały nawyk, biegnij na każdym pull request, a nie kwartalny przegląd lub lista kontrolna przed premierą.
- Ryzyko związane z API nie powinno być przedmiotem oddzielnego narzędzia. Najbardziej przydatne najlepsze praktyki ochrony interfejsu API traktują ustalenia dotyczące interfejsu API jako część tego samego obrazu ryzyka, co kod, zależność i pipeline security, nie jest to odizolowana konsola.
FAQ
Jakie są najważniejsze dobre praktyki bezpieczeństwa API, od których warto zacząć?
Zacznij od inwentaryzacji. Nie możesz zastosować kontroli autoryzacji, limitów przepustowości ani kontroli dostępu do danych w punkcie końcowym, o którego istnieniu nie wiesz, dlatego kompletna i dokładna inwentaryzacja każdego punktu końcowego interfejsu API stanowi podstawę, od której zależy wszystko inne na tej liście kontrolnej.
Jaka jest różnica między najlepszymi praktykami bezpieczeństwa interfejsu API a najlepszymi praktykami bezpieczeństwa ogólnej aplikacji?
Interfejsy API niosą ze sobą zagrożenia, których ogólne praktyki AppSec nie obejmują w pełni: autoryzację na poziomie obiektów i funkcji na dużą skalę, specyficzne zagrożenie związane z zaufaniem do odpowiedzi API stron trzecich oraz wyzwanie związane ze śledzeniem przestarzałych lub nieudokumentowanych punktów końcowych. Najlepsze praktyki bezpieczeństwa interfejsów API to najlepsze praktyki bezpieczeństwa aplikacji, stosowane w odniesieniu do tych obszarów powierzchni ataku, o których najłatwiej zapomnieć.
Czy testy bezpieczeństwa interfejsu API należy przeprowadzać przed czy po wdrożeniu?
Oba, ale punkt o największej wadze jest przed. Statyczna analiza kodu i specyfikacji API pozwala wykryć narażenie, gdy jest ono jeszcze pull requestTestowanie w czasie wykonywania (DAST) weryfikuje, co jest faktycznie osiągalne po uruchomieniu aplikacji. Poleganie wyłącznie na testowaniu w czasie wykonywania oznacza, że każda poprawka kosztuje więcej, niż to konieczne.
Jak często należy aktualizować inwentarz API?
Ciągle, najlepiej co roku pull requestInwentarz utworzony raz i sprawdzany kwartalnie jest już nieaktualny w momencie wprowadzenia nowego punktu końcowego, a to właśnie ta luka jest wykorzystywana przez nieprawidłowe zarządzanie inwentarzem.
Czy najlepsze praktyki zarządzania interfejsami API mają zastosowanie do wewnętrznych interfejsów API, a nie tylko tych dostępnych publicznie?
Tak. Wewnętrzne interfejsy API często mają niższy poziom bezpieczeństwa, ponieważ „nie są wystawione na działanie internetu”, ale nadal przetwarzają poufne dane i są dostępne dla każdego, kto ma dostęp do wewnętrznej sieci, w tym dla osób z przejętym kontem lub osób z wewnątrz.
