API

API (ang. Application Programming Interface, czyli interfejs programowania aplikacji) to ustalony zbiór reguł, dzięki którym dwa programy mogą wymieniać dane i uruchamiać nawzajem swoje funkcje, nie znając swojej budowy w środku. Można je porównać do umowy: API mówi, jakie żądania wolno wysłać, w jakim formacie, jakie dane są wymagane i co druga strona odeśle w odpowiedzi. Dziś najczęściej spotykamy web API działające przez protokół HTTP (ten sam, na którym opierają się strony internetowe). Dane przesyła się w nich zwykle w formacie JSON lub XML.

Jak działa API?

Większość API działa w modelu klient–serwer. Program, który o coś prosi (wysyła żądanie, ang. request), to klient. System, który odpowiada (response), to serwer. Klient wysyła żądanie pod konkretny endpoint, czyli adres URL wskazujący dany zasób lub operację. Serwer przetwarza żądanie i odsyła odpowiedź razem z kodem statusu HTTP, który mówi, jak poszło.

Typowe żądanie do web API składa się z kilku elementów:

1. Metoda HTTP mówiąca, co chcemy zrobić: GET (odczyt), POST (utworzenie), PUT/PATCH (aktualizacja), DELETE (usunięcie).
2. Endpoint i parametry wskazujące zasób (np. fragment adresu, parametry zapytania).
3. Nagłówki, w tym dane logowania (np. Authorization) oraz format treści (Content-Type).
4. Treść żądania (payload), zwykle w JSON, gdy coś zapisujemy lub tworzymy.
5. Odpowiedź: kod statusu (np. 200, 201, 400, 401, 404, 429, 500) oraz dane wynikowe.

Jakie są rodzaje API?

API dzielimy na dwa sposoby: według tego, komu są udostępniane, oraz według stylu i protokołu komunikacji.

Podział według dostępności

• Prywatne (wewnętrzne) – używane tylko w jednej organizacji, do łączenia jej własnych systemów.
• Partnerskie – udostępniane wybranym, zaufanym firmom zewnętrznym na podstawie umowy.
• Publiczne (otwarte) – dostępne dla zewnętrznych programistów, często po rejestracji i z kluczem API.
• Złożone (composite) – łączą kilka wywołań do różnych usług w jednym żądaniu.

Podział według stylu i protokołu

• REST (Representational State Transfer) – najpopularniejszy styl web API. Jest bezstanowy, czyli serwer nie pamięta wcześniejszych żądań – każde traktuje osobno. Opiera się na zasobach i zwykłych metodach HTTP.
• SOAP – starszy protokół oparty na XML i sztywnym schemacie (WSDL). Wciąż spotykany w systemach firmowych i bankowych.
• GraphQL – język zapytań, w którym klient sam wskazuje, jakie dokładnie pola chce dostać. Dzięki temu nie pobiera ani za dużo, ani za mało danych.
• RPC (np. gRPC, JSON-RPC) – zdalne wywoływanie procedur, czyli uruchamianie funkcji na innym serwerze. gRPC korzysta z HTTP/2 i Protocol Buffers i dobrze sprawdza się w komunikacji między mikroserwisami.
• WebSocket – stały, dwukierunkowy kanał do przesyłania danych i zdarzeń na żywo.
• Webhooki – model odwrócony: to serwer sam wysyła żądanie HTTP pod ustalony adres klienta, gdy coś się wydarzy.

Czym jest endpoint i dokumentacja API?

Endpoint to punkt końcowy interfejsu – adres URL, pod którym dostępna jest konkretna operacja lub konkretny zasób. Zestaw wszystkich endpointów wraz z opisem metod, parametrów, formatów i kodów odpowiedzi tworzy razem kontrakt API.

Ten kontrakt zapisuje się w postaci specyfikacji, najczęściej w standardzie OpenAPI (dawniej Swagger) dla API typu REST. Na podstawie specyfikacji można automatycznie wygenerować dokumentację, gotowy kod oraz testy. W GraphQL rolę kontraktu pełni schemat, a w gRPC – pliki .proto.

Jak zabezpiecza się API?

API to fragment systemu wystawiony na zewnątrz, więc jest łatwo dostępnym celem ataku – udostępnia logikę działania aplikacji i dane na świat. Podstawowe sposoby ochrony to:

• Szyfrowanie połączenia – komunikacja tylko przez HTTPS (TLS) i wyłączenie przestarzałych wersji (SSLv3, TLS 1.0/1.1). Przy usługach o podwyższonym ryzyku stosuje się mTLS, czyli wzajemne potwierdzanie tożsamości certyfikatem po obu stronach.
• Uwierzytelnianie – potwierdzenie, kto wysyła żądanie: klucze API, tokeny JWT, OAuth 2.0 (krótko ważne tokeny dostępu), OpenID Connect, HMAC.
• Autoryzacja – sprawdzanie uprawnień przy każdym żądaniu, dla każdego obiektu i każdej operacji, według zasady minimalnych uprawnień (każdy ma dostęp tylko do tego, czego naprawdę potrzebuje).
• Sprawdzanie danych wejściowych – kontrola typu, długości, zakresu i formatu, odrzucanie zbyt dużych żądań (kod 413) oraz użycie parserów odpornych na atak XXE.
• Ograniczanie liczby żądań (rate limiting) – limity wywołań i odpowiedź 429, które chronią przed nadużyciami, masowym odpytywaniem i atakami DoS.
• Higiena odpowiedzi – ogólne komunikaty błędów (bez ujawniania szczegółów działania), nagłówki bezpieczeństwa (Strict-Transport-Security, X-Content-Type-Options: nosniff) oraz restrykcyjna polityka CORS.

Dlaczego API jest istotne dla bezpieczeństwa i monitoringu?

API to dziś jeden z głównych celów ataków na aplikacje. Lista OWASP API Security Top 10 wskazuje jako największe ryzyko BOLA (Broken Object Level Authorization, czyli błędną kontrolę dostępu do obiektów). Polega ono na tym, że klient podmienia w żądaniu identyfikator i sięga po cudze dane, bo serwer nie sprawdza, do kogo dany zasób należy. Do ważnych zagrożeń należą też błędne uwierzytelnianie, ujawnianie w odpowiedzi zbyt wielu danych oraz brak limitów zużycia zasobów.

Z punktu widzenia zespołu bezpieczeństwa (SOC), systemów wykrywania zagrożeń w sieci (NDR) i monitoringu API jest ważne na dwa sposoby:

• Jako źródło ryzyka. Ruch API trzeba obserwować pod kątem nietypowych zachowań: nagłego wzrostu liczby błędów 401/403 (próby obejścia kontroli dostępu), kolejnego odpytywania o identyfikatory (sygnał ataku BOLA), pobierania nietypowo dużej ilości danych (możliwa kradzież danych) czy wywołań z nieoczekiwanych adresów. Częstym punktem wejścia są „shadow API”, czyli zapomniane lub nieudokumentowane endpointy.
• Jako źródło danych i punkt integracji. Systemy monitorujące same udostępniają i wykorzystują API, żeby pobierać alerty, wzbogacać zdarzenia o kontekst (np. dane o zasobach czy informacje o zagrożeniach), przekazywać dane do systemów SIEM/SOAR i automatyzować reakcję na incydenty. Logi dostępu do API – z czasem zdarzenia, adresem IP i tożsamością wywołującego – są ważnym materiałem dowodowym przy analizie incydentu.

Dowiedz się więcej

• Podatność IDOR – jak wykryć atak na aplikacje webowe przez analizę ruchu HTTP — IDOR dotyczy błędów w API, gdy dostęp do zasobów zależy od manipulacji identyfikatorem w żądaniu.
• REST API — REST API to popularny styl tworzenia interfejsów API oparty na zasobach i metodach HTTP.
• Integracja logów audytu Sycope z SIEM w celu zwiększenia zgodności i monitorowania — API służy do przekazywania logów audytu z Sycope do SIEM i automatyzacji integracji.
• ARP Spoofing – jak wykryć atak Man-in-the-Middle i zatruwanie ARP w sieci LAN — ARP Spoofing nie dotyczy API, lecz może wpływać na ruch do usług API w sieci LAN.
• Architektura Zero Trust – rola widoczności sieci i mikrosegmentacji w bezpieczeństwie — API w modelu Zero Trust wymaga kontroli dostępu, uwierzytelniania i stałej weryfikacji.
• Application Layer Attack (L7) — API działa w warstwie aplikacji, więc jest częstym celem ataków L7.