Bezpieczeństwo API — najczęstsze luki i jak ich unikać

Bezpieczeństwo API to ochrona interfejsów, przez które aplikacje wymieniają dane, przed nieuprawnionym dostępem, nadużyciem i przeciążeniem. Najczęstsze luki nie wynikają z egzotycznych ataków, tylko z braku kontroli, czy dany użytkownik może odczytać konkretny obiekt, z braku limitów oraz z zapomnianych wersji interfejsów, o których nikt już nie pamięta.

Na skróty

Czego dowiesz się z artykułu:

• Które luki API są najczęstsze według aktualnej listy OWASP
• Jak działa atak na autoryzację na poziomie obiektu i jak go zablokować
• Czego wymaga bezpieczny OAuth 2.0 według aktualnych dobrych praktyk IETF
• Co zmieniła aktualizacja wytycznych NIST dotyczących ochrony API

Dla kogo jest ten artykuł:

• Programiści i architekci backendu
• Testerzy bezpieczeństwa i pentesterzy
• Zespoły DevSecOps odpowiedzialne za bramy API

Czas czytania: 7 minut

Dlaczego API to osobna kategoria ryzyka

Aplikacja webowa pokazuje użytkownikowi gotowy ekran, a API wystawia surowe operacje na danych. Dlatego OWASP prowadzi osobną listę ryzyk dla API. Aktualna edycja na owasp.org pochodzi z 2023 r. i zastąpiła listę z 2019 r. Lista ma charakter rankingu świadomości, a nie pełnego standardu, ale dobrze pokazuje, gdzie zespoły popełniają błędy najczęściej.

Wspólny mianownik wielu pozycji jest ten sam: serwer ufa temu, co przysłał klient. Klient może podać dowolny identyfikator obiektu, dowolne pole w treści żądania i dowolną liczbę żądań na sekundę. Każde z tych założeń trzeba sprawdzić po stronie serwera.

Najczęstsze luki według OWASP API Security Top 10

Poniżej pozycje z listy na owasp.org, które najczęściej wychodzą w testach interfejsów biznesowych:

• API1:2023 Broken Object Level Authorization (BOLA) — API przyjmuje identyfikator obiektu od klienta i nie sprawdza, czy ten użytkownik ma prawo do tego konkretnego obiektu. OWASP zaleca kontrolę dostępu na poziomie obiektu w każdej funkcji, która sięga do danych po identyfikatorze od użytkownika.
• API2:2023 Broken Authentication — błędy w uwierzytelnianiu pozwalają przejąć tokeny albo podszyć się pod innego użytkownika.
• API3:2023 Broken Object Property Level Authorization — API zwraca albo pozwala zmienić pola, do których klient nie powinien mieć dostępu, na przykład flagę uprawnień administratora.
• API4:2023 Unrestricted Resource Consumption — brak limitów na żądania, rozmiar odpowiedzi czy kosztowne operacje (wysyłka SMS, weryfikacja biometryczna) prowadzi do odmowy usługi albo wzrostu kosztów.
• API9:2023 Improper Inventory Management — stare wersje i środowiska testowe API działają dalej, bez aktualnych zabezpieczeń.

Typowy test BOLA jest prosty: zalogowany użytkownik pobiera własny zasób poleceniem curl -H "Authorization: Bearer $TOKEN" https://api.example.com/v1/invoices/1043, a potem zmienia identyfikator na cudzy. Jeżeli API zwraca dane, luka istnieje.

Jak ich unikać: techniki obronne

• Kontrola dostępu na poziomie obiektu — decyzja o dostępie zapada na serwerze, dla konkretnego rekordu i konkretnego użytkownika, a nie tylko na poziomie całego endpointu.
• Walidacja schematu — żądania i odpowiedzi sprawdzane względem kontraktu OpenAPI lub JSON Schema, z odrzucaniem nieznanych pól (additionalProperties: false). To utrudnia masowe przypisanie pól i wyciek nadmiarowych danych.
• Limitowanie żądań — limity per klient i per operacja na bramie API, odpowiedź 429 Too Many Requests z nagłówkiem Retry-After, osobne limity dla operacji kosztownych.
• Inwentarz API — rejestr wszystkich wersji, środowisk i hostów z właścicielem i datą wycofania.

Wytyczne NIST SP 800-228 „Guidelines for API Protection for Cloud-Native Systems” w csrc.nist.gov porządkują te środki według cyklu życia API: osobno przed uruchomieniem i w czasie działania, z podziałem na zabezpieczenia podstawowe i zaawansowane. Aktualizacja z 13 marca 2026 r. zastąpiła wydanie z czerwca 2025 r. i dodała dodatek D z listą ryzyk API według kategorii oraz dodatek E z zalecanymi zabezpieczeniami według etapu cyklu życia. Warto korzystać z wersji zaktualizowanej.

OAuth 2.0 bez starych nawyków

Wiele API chroni się tokenami OAuth 2.0. Dokument RFC 9700 z datatracker.ietf.org (najlepsze praktyki bezpieczeństwa OAuth 2.0, opublikowany w styczniu 2025 r.) zmienia dawne zalecenia:

• przepływ niejawny (implicit grant) nie powinien być używany, jeżeli nie wyeliminowano ryzyka wycieku i wstrzyknięcia tokenu;
• przepływ z hasłem właściciela zasobu (resource owner password credentials) nie może być używany;
• klienci publiczni muszą stosować PKCE;
• tokeny dostępu powinny być ograniczone do konkretnego odbiorcy (audience), a tokeny odświeżania klientów publicznych muszą być powiązane z nadawcą albo rotowane.

Czytaj także

• Bezpieczeństwo aplikacji webowych według OWASP w praktyce — lista dla aplikacji webowych
• Testowanie API — narzędzia i dobre praktyki — gdzie wpiąć testy bezpieczeństwa
• Red teaming a pentesty — jaki rodzaj testu wybrać

Rozwijaj kompetencje

Temat rozwijają szkolenia Bezpieczeństwo API — ochrona i kontrola dostępu oraz Open Authentication (OAuth) — implementacja bezpiecznej autoryzacji. Pierwsze obejmuje modele zagrożeń dla API i strategie ochrony, drugie implementację OAuth 2.0 i zarządzanie tokenami. Skontaktuj się z nami, żeby dopasować zakres do swojego zespołu.

Najczęściej zadawane pytania (FAQ)

Czym jest lista ryzyk OWASP i czym różni się wersja dla API?

OWASP Top 10 to lista najważniejszych ryzyk bezpieczeństwa aplikacji webowych. Dla interfejsów programistycznych OWASP prowadzi na owasp.org osobną listę API Security Top 10, której aktualna edycja pochodzi z 2023 r. Większy nacisk kładzie na autoryzację obiektów i ich właściwości, zużycie zasobów oraz inwentarz interfejsów.

Jak przeprowadzić test penetracyjny REST API?

Zacznij od dokumentacji i inwentarza: specyfikacji OpenAPI, wersji i środowisk. Następnie sprawdź uwierzytelnianie, podmianę identyfikatorów obiektów między kontami, przesyłanie nieoczekiwanych pól, limity żądań oraz dostęp do funkcji administracyjnych zwykłym tokenem. Wyniki zestaw z listą ryzyk API opublikowaną na owasp.org.

Czym różni się bezpieczeństwo API od bezpieczeństwa aplikacji webowych?

Aplikacja webowa część kontroli realizuje w interfejsie użytkownika, a API wystawia operacje bezpośrednio, więc każda kontrola musi działać na serwerze. W API większą rolę odgrywają tokeny, autoryzacja pojedynczych obiektów, limity i zarządzanie wersjami. Wiele zasad, jak walidacja danych wejściowych, pozostaje wspólnych.

Jak testować API pod kątem bezpieczeństwa w codziennej pracy?

Dodaj do testów automatycznych przypadki negatywne: żądanie cudzego obiektu, żądanie bez tokenu, nieznane pole w treści i przekroczenie limitu. Uruchamiaj je w potoku CI przy każdej zmianie kontraktu. Narzędzia do testów funkcjonalnych API dobrze się do tego nadają, jeśli zespół celowo pisze scenariusze nadużyć.