Dlaczego bezpieczeństwo API jest krytyczne w bankowości
Open Banking i dyrektywa PSD2 zmieniły architekturę usług finansowych. Banki muszą udostępniać API zewnętrznym dostawcom (TPP — Third Party Providers), umożliwiając inicjowanie płatności i dostęp do informacji o rachunkach. Każdy endpoint API to potencjalny punkt wejścia dla atakujących.
W 2025 roku ataki na API bankowe wzrosły o 127%. Podatności w API umożliwiają: nieautoryzowany dostęp do danych klientów, inicjowanie fałszywych transakcji, wyciek danych osobowych i manipulację saldami. Tradycyjne firewalle sieciowe nie chronią warstwy aplikacyjnej API.
Najczęstsze podatności API w sektorze finansowym
BOLA (Broken Object Level Authorization)
Najpoważniejsza podatność API wg OWASP. Atakujący zmienia identyfikator obiektu w żądaniu (np. numer konta) i uzyskuje dostęp do danych innego klienta. W bankowości oznacza to dostęp do cudzych rachunków, transakcji i danych osobowych.
Broken Authentication
Słabe mechanizmy uwierzytelniania API: brak walidacji tokenów JWT, długi czas życia tokenów, brak rotacji kluczy. Umożliwia przejęcie sesji i dostęp do API z prawami legalnego użytkownika.
Excessive Data Exposure
API zwraca więcej danych niż potrzebuje klient (np. pełny numer karty, PESEL, historia transakcji). Implementacja filtrowania po stronie frontendu zamiast backendu.
Lack of Rate Limiting
Brak ograniczenia liczby żądań umożliwia brute force na uwierzytelnianie, scraping danych klientów, ataki DDoS na API i credential stuffing.
Mass Assignment
Atakujący dodaje nieoczekiwane pola do żądania (np. "role": "admin" lub "balance": 999999), wykorzystując automatyczne bindowanie parametrów.
Architektura bezpieczeństwa API bankowego
Warstwa 1: API Gateway
Centralny punkt zarządzania ruchem API. Funkcje: uwierzytelnianie (OAuth 2.0, mTLS), rate limiting, transformacja żądań, logowanie, caching, load balancing. Separacja ruchu Open Banking od wewnętrznych API.
Warstwa 2: Uwierzytelnianie i autoryzacja
OAuth 2.0 + OpenID Connect dla autoryzacji dostępu do zasobów. Silne uwierzytelnianie klienta (SCA) zgodne z PSD2. Certyfikaty eIDAS dla identyfikacji TPP. RBAC/ABAC dla granularnej kontroli dostępu do endpointów.
Warstwa 3: Walidacja danych
Schema validation na każdym endpointcie. Whitelist dozwolonych pól. Walidacja typów, zakresów i formatów. Sanityzacja danych wejściowych. Ochrona przed injection (SQL, NoSQL, Command).
Warstwa 4: Monitoring i SOC
Logowanie wszystkich wywołań API z kontekstem biznesowym. Detekcja anomalii: nietypowe wzorce wywołań, zmiana geolokalizacji, nadmierna liczba żądań. Integracja z SOC do korelacji alertów API z innymi zdarzeniami bezpieczeństwa.
Plan wdrożenia bezpieczeństwa API
Krok 1: Inwentaryzacja API
Mapowanie wszystkich API: wewnętrzne, zewnętrzne (Open Banking), partnerskie. Identyfikacja endpointów przetwarzających dane wrażliwe (PII, dane kart, salda). Dokumentacja w formacie OpenAPI/Swagger.
Krok 2: Threat modeling
Analiza zagrożeń dla każdego API: kto może atakować, jakie dane są narażone, jakie są konsekwencje. Priorytetyzacja ryzyk zgodnie z DORA i PCI DSS.
Krok 3: Implementacja API Gateway
Wdrożenie centralnego API Gateway z uwierzytelnianiem, rate limiting i logowaniem. Konfiguracja polityk per endpoint: różne limity dla Open Banking, aplikacji mobilnej i wewnętrznych systemów.
Krok 4: Zabezpieczenie endpointów
Implementacja walidacji danych, kontroli autoryzacji (BOLA prevention), ochrony przed mass assignment i injection. Code review bezpieczeństwa dla każdego nowego endpointa.
Krok 5: Testowanie
Testy penetracyjne API obejmujące OWASP API Top 10. Fuzzing endpointów. Testy uwierzytelniania i autoryzacji. Walidacja rate limiting. Regularne skanowanie podatności.
Krok 6: Monitoring i ciągłe doskonalenie
Integracja logów API z SIEM/SOC. Alerty na anomalie. Regularne przeglądy konfiguracji. Aktualizacja polityk bezpieczeństwa. Automatyczne testy w CI/CD pipeline.
Wymagania regulacyjne dla API bankowych
PSD2/Open Banking: Silne uwierzytelnianie (SCA), certyfikaty eIDAS dla TPP, dedykowane API z dostępnością 99.5%+, sandbox dla testów integracyjnych.
DORA: API jako element infrastruktury ICT objętej zarządzaniem ryzykiem, testowaniem odporności i raportowaniem incydentów.
PCI DSS: API przetwarzające dane kart muszą spełniać wymagania dotyczące szyfrowania, logowania i kontroli dostępu.
Jak nFlo zabezpiecza API bankowe
- Testy penetracyjne — dedykowane testy API, OWASP API Top 10, fuzzing, testy logiki biznesowej
- Audyt bezpieczeństwa — przegląd architektury API, ocena konfiguracji Gateway, analiza zagrożeń
- SOC as a Service — monitoring API w czasie rzeczywistym, detekcja anomalii, korelacja z innymi źródłami
- Wsparcie compliance — zgodność API z PSD2, DORA i PCI DSS
Cyberbezpieczeństwo w Twojej branży
Dowiedz się więcej o cyberbezpieczeństwie w Twojej branży:
