20.11.2025

Top 5 OWASP API Security Risks w 2026

API OWASP Bezpieczeństwo Podatności

API to nowy perimeter

Każdy nowoczesny SaaS to API z doklejonym frontendem. Twoja aplikacja mobilna, webowa, integracje — wszystkie komunikują się z tym samym API REST lub GraphQL. A atakujący to wiedzą.

OWASP API Security Top 10 stał się bardziej istotny niż oryginalny OWASP Top 10 dla produktów SaaS. Oto 5 ryzyk, na które trafiam najczęściej podczas testów penetracyjnych.

1. Broken Object-Level Authorization (API1:2023)

Co to jest: Endpoint API zwraca dane na podstawie ID podanego przez użytkownika, nie sprawdzając, czy żądający użytkownik jest właścicielem tego zasobu.

Prawdziwy przykład: GET /api/invoices/1452 zwraca fakturę #1452. Ale użytkownik z Firmy A zmienia ID na 1453 i otrzymuje fakturę Firmy B — wraz z adresem rozliczeniowym, NIP-em i pozycjami faktury.

Rozwiązanie: Nigdy nie ufaj ID obiektu z URL-a. Każde zapytanie do bazy musi zawierać kontekst użytkownika/dzierżawcy. Pseudokod:

// Źle
SELECT * FROM invoices WHERE id = $url_id;


// Poprawnie
SELECT * FROM invoices WHERE id = $url_id AND tenant_id = $session_tenant_id;

2. Broken Authentication (API2:2023)

Co to jest: Słaba lub brakująca autentykacja na endpointach API, albo autentykacja łatwa do obejścia.

Prawdziwy przykład: Endpoint admina pod /api/admin/users sprawdza poprawność JWT — ale akceptuje tokeny podpisane algorytmem none lub z pustym sekretem. Albo gorzej: środowisko stagingowe używa tego samego sekretu JWT co produkcyjne, zahardkodowanego w pliku .env.example, który trafił do publicznego repo.

Rozwiązanie:

  • Whitelistowanie algorytmów JWT (tylko RS256/HS256, nigdy none)
  • Rotowanie sekretów między środowiskami
  • Dodanie rate limiting do endpointów logowania i odświeżania tokenów

3. Broken Object Property Level Authorization (API3:2023)

Co to jest: API akceptuje więcej pól w body żądania niż zamierzono. Mass assignment pozwala użytkownikom ustawiać pola, których nie powinni.

Prawdziwy przykład: Endpoint „Aktualizuj profil" akceptuje POST /api/users/me z body JSON. Backend ślepo aktualizuje każde pole z żądania:

{
  "name": "Atakujący",
  "role": "admin",
  "plan": "enterprise",
  "is_verified": true
}

Rozwiązanie: Whitelisting dozwolonych pól. Nigdy nie używaj $model->update($request->all()). Zawsze jawnie wymieniaj, które pola mogą być aktualizowane:

$user->fill($request->only(['name', 'avatar', 'timezone']));

4. Unrestricted Access to Sensitive Business Flows (API6:2023)

Co to jest: Endpointy API wykonujące krytyczne biznesowo akcje bez zabezpieczeń przed nadużyciem.

Prawdziwy przykład: Program „Poleć znajomego" daje obu użytkownikom kredyt 50 zł. Brak rate limiting, brak sprawdzania duplikatów. Atakujący pisze skrypt, który tworzy 1 000 fałszywych kont i zbiera 50 000 zł kredytu.

Rozwiązanie: Modeluj wpływ biznesowy nadużycia API. Jeśli endpoint przenosi pieniądze, kredyty lub uprawnienia — dodaj rate limiting, wykrywanie duplikatów i monitorowanie anomalii.

5. Server-Side Request Forgery (API7:2023)

Co to jest: API akceptuje URL jako dane wejściowe i wykonuje do niego żądanie. Atakujący wykorzystują to do uderzania w wewnętrzne usługi.

Prawdziwy przykład: Endpoint rejestracji webhooka przyjmuje https://example.com/webhook, a serwer sprawdza, czy URL jest osiągalny. Atakujący podaje http://169.254.169.254/latest/meta-data/ (endpoint metadanych AWS) i otrzymuje dane uwierzytelniające AWS w odpowiedzi.

Rozwiązanie: Nigdy nie pozwalaj, by URL-e podane przez użytkownika sięgały do wewnętrznych zakresów IP. Używaj allowlisty URL-i, gdy to możliwe. Blokuj żądania do 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 i 127.0.0.0/8.

---

Wzorzec

Zauważasz wzorzec we wszystkich 5 ryzykach? Granice zaufania. Twoje API ufa, że klient wyśle właściwe ID, właściwe pola, właściwe URL-e. Atakujący wykorzystują to zaufanie.

Każdy endpoint API powinien pytać: „Czy podmiot wysyłający to żądanie jest upoważniony do dostępu do zasobu, którego to żądanie dotyczy?" Jeśli odpowiedź nie jest jednoznacznym tak — masz podatność.

Czego brakuje na tej liście

Injection (SQLi, NoSQLi) i security misconfiguration są wciąż powszechne — ale zostały zepchnięte przez nowoczesne frameworki z wbudowaną parametryzacją i bezpiecznymi domyślnymi ustawieniami. Powyższe ryzyka to te, których frameworki nie rozwiązują za Ciebie. Autoryzacja leży po Twojej stronie.

← Powrót do Bloga