Bezpieczeństwo API: uwierzytelnianie, autoryzacja i exploity

Dlaczego API są głównym celem ataków

API stały się dominującym wzorcem architektonicznym nowoczesnych aplikacji — klienci mobilni, aplikacje jednostronicowe, mikroserwisy i integracje zewnętrzne komunikują się właśnie przez nie. Ta wszechobecność czyni je atrakcyjnym celem: jeden podatny endpoint API może ujawnić dane milionów użytkowników, ominąć uwierzytelnianie lub dać nieautoryzowany dostęp administracyjny. OWASP prowadzi osobną listę API Security Top 10, ponieważ podatności aplikacji webowych nie oddają w pełni ryzyk specyficznych dla API.

Uwierzytelnianie: potwierdzanie tożsamości na poziomie API

Klucze API

Klucze API to najprostszy mechanizm uwierzytelniania — statyczny sekret współdzielony z klientem. Nadają się do komunikacji serwer–serwer, gdy klientem jest zaufany system backendowy. Kluczowe praktyki:

• Traktuj klucze API jak hasła: nigdy ich nie loguj, nie umieszczaj w adresach URL (używaj nagłówka Authorization), nie commituj do repozytorium
• Wydawaj osobne klucze dla każdego klienta, aby móc unieważnić pojedynczy klucz bez wpływu na pozostałe
• Ustawiaj daty wygaśnięcia i regularnie rotuj klucze
• Ograniczaj uprawnienia kluczy do niezbędnego minimum

Uwierzytelnianie oparte na JWT

Tokeny JWT (JSON Web Tokens) zawierają oświadczenia (claims), które serwer może zweryfikować bez zapytania do bazy danych, dlatego są popularne w bezstanowych API. JWT składa się z nagłówka, ładunku i podpisu: header.payload.signature, każdy zakodowany w Base64URL.

Kluczowe kroki walidacji:

1. Verify the signature using the correct algorithm (reject alg:none)
2. Check iss (issuer) matches your expected authority
3. Check aud (audience) is your API
4. Check exp (expiration) — reject expired tokens
5. Check nbf (not before) if present

Czyli: zweryfikuj podpis właściwym algorytmem (odrzucaj alg:none), sprawdź, czy iss (wystawca) jest oczekiwany, czy aud (odbiorca) to Twoje API, czy token nie wygasł (exp) i — jeśli występuje — pole nbf (nie wcześniej niż).

Nigdy nie ufaj polu alg w nagłówku tokena przy wyborze logiki walidacji — zawsze ustal oczekiwany algorytm po stronie serwera.

Zakresy OAuth do autoryzacji

W API dla użytkowników stosuj OAuth 2.0 z precyzyjnymi zakresami (scopes): read:profile, write:orders, admin:billing. Każdy endpoint API powinien sprawdzać, czy przedstawiony token zawiera wymagany zakres. Ważny token nie oznacza dostępu do wszystkiego.

OWASP API Security Top 10: krytyczne ryzyka

Broken Object Level Authorization (BOLA)

BOLA — nazywane też IDOR (Insecure Direct Object Reference) — to niezmiennie ryzyko nr 1 w bezpieczeństwie API. Występuje, gdy endpoint przyjmuje w żądaniu identyfikator obiektu, ale nie sprawdza, czy użytkownik faktycznie jest jego właścicielem:

GET /api/orders/12345  →  returns order 12345
GET /api/orders/12346  →  returns another user's order (BOLA!)

Drugie żądanie zwraca zamówienie innego użytkownika — to właśnie BOLA.

Obrona: w każdym endpoincie dającym dostęp do obiektu sprawdzaj, czy uwierzytelniony użytkownik ma związek z żądanym obiektem. Nigdy nie polegaj wyłącznie na identyfikatorze obiektu.

Broken Function Level Authorization

Funkcje administracyjne są dostępne pod przewidywalnymi adresami, a chroni je jedynie ukrycie w interfejsie, a nie egzekwowanie po stronie serwera:

POST /api/admin/deleteUser  →  accessible to regular users

Obrona: egzekwuj kontrolę dostępu opartą na rolach w każdym endpoincie, po stronie serwera. Regularnie testuj wszystkie endpointy, niezależnie od tego, czy widzisz je w interfejsie dla swojej roli.

Broken Object Property Level Authorization

API może poprawnie ograniczać, do których obiektów masz dostęp, ale ujawniać lub pozwalać na modyfikację wewnętrznych pól tych obiektów:

PUT /api/users/me  {"role": "admin"}  →  mass assignment vulnerability

To podatność typu mass assignment — użytkownik nadaje sobie rolę administratora.

Obrona: stosuj jawne listy dozwolonych pól do odczytu i zapisu dla każdego endpointu. Nigdy nie przekazuj obiektu z treści żądania bezpośrednio do metod ORM (np. update(params[:user]) w Rails bez permit).

Unrestricted Resource Consumption

Bez limitowania żądań jeden klient może wyczerpać moc obliczeniową API, połączenia z bazą danych lub limit usług zewnętrznych:

• Wprowadź limity żądań na użytkownika, adres IP i klucz API
• Zwracaj 429 Too Many Requests z nagłówkiem Retry-After
• Ograniczaj rozmiar treści żądania, aby zapobiec DoS przez zbyt duże ładunki
• Stosuj paginację i limity wyników: nigdy nie zwracaj nieograniczonych kolekcji
• W API GraphQL ograniczaj głębokość zapytań

Do limitowania używaj np. modułu limit_req w nginx, throttlingu w AWS API Gateway lub dedykowanych bramek API (Kong, Envoy).

Security Misconfiguration

Typowe błędy konfiguracji API to:

• CORS ustawiony na Access-Control-Allow-Origin: * w endpointach wymagających uwierzytelnienia
• Rozbudowane komunikaty błędów ujawniające ślady stosu, zapytania do bazy lub ścieżki wewnętrzne
• Nieograniczone metody HTTP (PUT/DELETE włączone tam, gdzie powinny działać tylko GET/POST)
• Brak wymuszania HTTPS
• Dokumentacja Swagger/OpenAPI publicznie dostępna na produkcji

Błędy w logice biznesowej

Nie wszystkie podatności API są techniczne — niektóre wykorzystują samą logikę biznesową:

• Wielokrotne użycie tego samego kodu rabatowego
• Przelew ujemnej kwoty w celu dodania środków
• Pominięcie wymaganych kroków płatności przez bezpośrednie wywołanie późniejszego endpointu

Znalezienie ich wymaga wiedzy dziedzinowej i samymi automatycznymi skanerami ich nie wykryjesz. Uwzględniaj testy logiki biznesowej w przeglądach bezpieczeństwa API.

Praktyczne wzmacnianie bezpieczeństwa API

• Używaj HTTPS wszędzie i przekierowuj HTTP na HTTPS; ustaw nagłówek Strict-Transport-Security
• Waliduj wszystkie dane wejściowe — odrzucaj nieoczekiwane pola, sprawdzaj typy, zakresy i formaty
• Zwracaj minimum danych — nie umieszczaj w odpowiedziach wewnętrznych identyfikatorów, znaczników czasu serwera ani metadanych systemowych
• Loguj wszystkie wywołania API z kontekstem wystarczającym do analizy kryminalistycznej (ID użytkownika, endpoint, kod odpowiedzi, czas trwania)
• Używaj bramki API do scentralizowanego uwierzytelniania, limitowania, logowania i wykrywania zagrożeń
• Testuj za pomocą OWASP ZAP lub Burp Suite na podstawie własnej dokumentacji API — każdy endpoint ze specyfikacji OpenAPI powinien zostać sprawdzony pod kątem obejścia uwierzytelniania i BOLA