Bezpieczeństwo API i filtrowanie żądań
1) Dlaczego go potrzebujesz
API - zewnętrzna i wewnętrzna granica platformy. Każdy błąd w uwierzytelnianiu, autoryzacji, walidacji lub normalizacji żądań zmienia się w wykorzystanie luk (BOLA/IDOR, wtrysk, SSRF, masowe wyliczenie, wyczerpanie zasobów). Cel: Tworzenie defense-in-depth od obwodu do zasad biznesowych, z wymiernych SLO i kontroli ryzyka.
2) Inwentaryzacja i klasyfikacja API
Katalog API: rejestr wszystkich usług/punktów końcowych, właścicieli, wersje, typy klientów (web, mobile, partners), tryb (public/partner/internal), PII/dane finansowe.
Krytyczność: Wysoka (transakcje finansowe/autoryzacja), Średnia (odczyt profili), Niska (katalogi publiczne).
Powierzchnia ataku: REST, GraphQL, gRPC, WebSocket, webhooks.
Status: prod/staging/experimental, deprecate policy, token/key lifetime.
Shadow/abandoned API: detection by ingrest logs, eBPF/Service Mesh telemetry, porównanie z katalogiem.
3) Model zagrożenia (krótki)
Identyfikacja: porwanie tokenów, commit sesji, MitM, powtórka.
Autoryzacja: BOLA/IDOR, eskalacja pozioma/pionowa.
Wejście: zastrzyki (SQL/NoSQL/LDAP), szablon/serializacja, przebieg ścieżki, nagłówki.
Ruch: DDoS/L7 powodzie, powolne prośby, fantom retras.
Integracje: niepewne haki internetowe, SSRF za pomocą parametrów URL, pobieranie plików/skanów.
Logika: nadużywanie premii, wyścigi, niespójność idempotencji.
4) Podstawowa norma bezpieczeństwa (minimum)
1. TLS 1. 2 + wszędzie; HSTS; słabe szyfry są wyłączone.
2. Uwierzytelnianie: OAuth2/OIDC dla klientów, mTLS/lub HMAC - service-to-service.
3. Autoryzacja: scentralizowany PDP (RBAC/ABAC), kontrola poziomu obiektu (BOLA).
4. Walidacja: ścisły schemat (OpenAPI/JSON Schema/Protobuf), awaria z dodatkowymi polami.
5. Limity: stawka/kwoty + pęknięcie, na klienta/na IP/na token.
6. Idempotencja w operacjach pisania, ochrona przed powtórzeniami/rasami.
7. Filtrowanie WAF/gateway: normalizacja ścieżki/nagłówka, zaprzeczanie listom, blok ładunku-anty-wzorców.
8. Sekrety: KMS/Vault, rotacja klucza/certyfikatu, kontrola przecieku.
9. Obserwowalność: śledzenie, dzienniki kontroli bezpieczeństwa (kto/co/kiedy/wynik), wpisy.
10. Procedury: incydenty playbook, przypadki testowe i regularne pentests/DAST.
5) Uwierzytelnianie i zarządzanie tokenami
OAuth2/OIDC: żetony dostępu krótkotrwałego, odświeżające ściśle zgodnie z OIDC; publiczność/emitent/exp są sprawdzane w bramie.
JWT: RS256/ES256; minimalny zestaw małży; "nbf/exp/aud' są wymagane; zakaz przechowywania PII. Rotacja klucza przez JWKS.
DPoP/PoP: Wiązać token z kluczem klienta, aby zmniejszyć ryzyko powtórki/porwania.
mTLS dla systemów wewnętrznych i zaufanych partnerów (kwalifikacje CN/SAN, CRL/OCSP).
HMAC (podpisy): kanonizacja deterministyczna (metoda + ścieżka + znacznik czasu + nonce + body-hash); prawidłowe okno czasowe (± 30s).
Sesje przeglądarki: Serwis internetowy = strict/lax, Na bieżąco, Bezpiecznie; Ochrona CSRF (podwójne żetony składane/stanowe).
Przechowywanie klienta: na telefonie komórkowym - bezpieczna pamięć masowa (Keychain/Keystore), ochrona debugowa, certyfikaty przypinania.
6) Autoryzacja (BOLA-first)
Poziom obiektu: każda operacja sprawdza prawo do określonego zasobu (właściciel zasobów/zakres/atrybuty).
RBAC/ABAC: role + atrybuty (kraj, segment, limity ryzyka, poziom KYC)
Zasady: odmowa domyślna; wprost pozwalają; Testy weryfikacji polityki w przypadku przypadków negatywnych.
Pamięć podręczna: adaptacyjna TTL + niepełnosprawność w zmieniających się rolach/segmentach.
7) Żądania filtrowania i normalizacji (na bramce/WAF)
Normalizacja: kompresja powtarzanych ukośników, zakaz '../', dekodowanie raz, przycinanie przestrzeni/zero bajtów.
Nagłówki: lista zezwoleń („Host”, „Content-Type”, „Accept”, „Authorization”, „Date”, „Idempotence-Key”, niezbędne nagłówki śladowe).
Metody: „GET/HEAD” bez ciała; „POST/PUT/PATCH” - z typem „application/json” lub ściśle dozwolone.
Wymiary: max-body, max-headers, max-path; early-reject 413/431.
Pliki: walidator MIME, antywirus/piaskownica, zakaz zawartości aktywnej, recykling obrazu/sanitaryzacja.
Przekierowania adresu URL/fetchi: blok SSRF (odmawiają prywatnych zakresów/IP metadanych, schemat tylko 'https', domeny listy zezwoleń).
Wzory SQL/NoSQL: podpisy wtryskowe za pomocą zestawów reguł WAF + parametryzacja serwera zapytań.
Przykład zasad nagłówka (Pseudo Format)
deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB8) Limity, kwoty i ochrona przeciwciał
Ograniczenie stawki: wiadro żetonowe/wiadro nieszczelne; poziomy - na IP, na klucz API, na użytkownika, na org.
Kwoty: dziennie/miesięcznie, oddzielnie dla metod pisania/rozbudowanych.
Adaptacyjność: dynamiczne dokręcanie w warunkach anomalii (nagłe wybuchnięcie/uwierzytelnienie).
Slow-loris/slow-POST: read/keep-alive timeouts, concurrent connection restriction.
Przeciwciała: odcisk palca, objawy behawioralne, dowód działania/captcha zwiększonego ryzyka, lista sieci torus/proxy.
IP control: filtry geo/ASN, zaprzeczają listom podsieci „brudnych”, pozwalają na listy dla partnerów/paneli administratorów.
9) Walidacja danych wejściowych i obwodów
Nieudane zamknięcie: Wszystko, co zawodzi program, wynosi 400. Dodatkowe pola - odrzucić.
Typy/zakresy: liczby, daty (UTC/ISO-8601), wartości enum, długości linii, regexps.
JSON-jakość: max-gniazdowanie, zakaz dużych tablic/klawiszy, porządek kanoniczny (opcjonalnie).
Walidacja przedsiębiorstw: idempotencja zgodnie z „Idempotency-Key”; przepisy dotyczące zwalczania nadużyć finansowych (limity częstotliwości operacji, pułapy kwot).
GraphQL: granice głębokości/złożoności, zapytania na liście, autoryzacja na pole.
gRPC: ścisłe schematy Protobufa, obowiązkowe pola, ograniczenia rozmiaru wiadomości.
10) Haki internetowe i połączenia zewnętrzne
Podpisy: HMAC ze znacznikiem czasowym/nonce; weryfikacja przed przetworzeniem; okno +/- 5 min.
Dostawa: Retrai z wykładniczą przerwą i jitter; maksymalne próby; Deduplikacja identyfikatora zdarzenia
Dostawca IP zezwala na listę oddzielnych subdomain/path; minimalny stos hostingowy.
Odpowiedzi: 2xx tylko po udanym nagraniu wewnętrznym; w przeciwnym razie 4xx/5xx z jasnym kodem.
Wychodząca kontrola SSRF: gdy URL wywołania - allow-list, odmówić adresów prywatnych.
11) Szyfrowanie i tajne zarządzanie
W kanale: TLS 1. 2+/1. 3, szpilki, ścisła polityka szyfrowania.
Sam: szyfrowanie DB/obiektu, oddzielne klucze do danych PII/finansowych.
KMS/Vault: scentralizowane przechowywanie tajemnic, krótki TTL, automatyczna rotacja.
Klucze i certyfikaty: oddzielne dla środowisk; audyt zagadnień; zakaz wydawania kłód.
Token-introspection: listy odwołań offline, short 'exp'.
12) Obserwowalność, audyt i reakcja
Dzienniki zabezpieczeń: próby/sukcesy uwierzytelniania, awarie autoryzacji, zdarzenia limitowane, zmiany ról/limitów.
Śledzenie: korelacja-ID end-to-end; zewnętrzne śledzenie połączeń.
Metryki: RPS, opóźnienie P95/P99, wskaźnik błędów według kodu, udział 401/403/429, limity trafień, anomalie.
Ostrzeżenia: 401/403/429 kolce, wzrost 5xx, częste konflikty idempotencji, ostre odchylenia wykresu QL-complexity.
Playbooks: blokowanie kluczy/żetonów, szybkie odwracanie zasad, rozgrzewanie listy odmowy, powiadamianie właścicieli usług.
Technicy: zachowanie kontrowersyjnego ładunku (z bezpieczną edycją PII), powtórzenie na pojedynczym stoisku.
13) Błędy i odpowiedzi klienta
Jednolity format błędu (kod, komunikat, identyfikator śladu, kategoria).
Brak przecieków: nie ujawniaj SQL, nazw tabel, wewnętrznych idies; 403 zamiast „dlaczego nie”.
Kody: 400 (walidacja), 401 (brak uwierzytelnienia), 403 (brak praw), 404 (maska istnienie), 405/406, 413/429, 500/503.
Retry-Hints: дла 429 - „Retry-After”; dla idempotencji - porady dotyczące powtarzania z tym samym kluczem.
14) Wzory architektoniczne
Zero-Trust: mTLS, wyraźna autoryzacja pomiędzy wszystkimi usługami, minimalne uprawnienia.
Brama API + siatka usług WAF +: rozdzielenie obowiązków - obwód, polityka L7, uwierzytelnianie wewnętrzne.
Canary/Blue-Green: Wprowadzenie nowych zasad filtracji w etapach z nadzorem.
Fiil-closed: w przypadku pisania krytycznego lepiej bezpiecznie odmówić niż zezwolić na nieprawidłowe działanie.
Backpressure: kolejki/bufory, wyłącznik, timeouts/budgets.
15) Przykłady zasad praktycznych (pseudo-config)
15. 1 Ograniczanie ścieżek i metod
/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB15. 2 Idempotencja
require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result15. 3 Wniosek o podpis (HMAC)
signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce15. 4 Ochrona SSRF
outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true15. Limit 5 GraphQL
graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true16) Szczegóły dotyczące iGaming/Finance
Limity segmentu: w zależności od profilu CCM/kraju/ryzyka.
Okna czasowe: reguły częstotliwości wpłat/wypłat, „schładzanie” między transakcjami.
Bonus anti-abuse: spójne blokady na koncie/urządzeniu/IP/narzędzie płatnicze.
Audyt wymogów regulacyjnych: przechowywanie dzienników działań i decyzji (KYC/AML), okresy przechowywania, niezmienione kłody.
17) Lista kontrolna Prod Ready
- Pełny katalog API i mapa przepływu danych (PII/finanse oznaczone tagiem).
- Schematy OpenAPI/Protobuf, testy walidacyjne i umowy w CI.
- mTLS/HMAC/OAuth2 skonfigurowane; krótkie żetony TTL; rotacja klucza.
- testy BOLA i przypadki negatywnego zezwolenia; scentralizowany PDP.
- Limity/kwoty/anty-bot, ochrona przed slow-loris; Filtry IP.
- Zasady normalizacji WAF/gateway, podpisy anty-wtryskowe.
- Idempotencja operacji pisania; ochrona przed powtórką.
- Podpisy pod hakiem i lista zezwoleń; odizolowane punkty końcowe.
- Tajemnice w KMS/Vault; zaszyfrowane magazyny; wpisy do anomalii.
- Deski rozdzielcze, wpisy, dzienniki audytu; pracował odtwarzania incydentów.
- Regularne pentest/DAST/SAST, ścieżki wrażliwości i pobieranie patch.
18) Antypattery (co nie jest możliwe)
Zaufaj 'X-Forwarded-' bez sztywnego TLS na jego obwodzie.
Akceptuj arbitralne 'Content-Type' i „miękkie” schematy JSON.
Długotrwałe JWT bez pamięci/rotacji.
Mieszanie ról i zasad biznesowych w kodzie bez scentralizowanych zasad.
Dzienniki z tajemnicami/PII; szczegółowe 500-wiadomość na zewnątrz.
„Tymczasowe” otwarte punkty końcowe bez ograniczeń i zezwoleń.
19) Wersioning i deprekate
Wersje w ścieżce/nagłówku; polityka wsparcia (np. N-2).
Ogłoszenia: terminy deprecate, monitorowanie stosowania starych wersji, kontrolowane wyłączenie.
Kompatybilność: kontrakty klienta/partnera i matryce testowe.
20) Badanie bezpieczeństwa
Testy kontraktowe programów/polityk, zamrażanie danych wejściowych, ujemne auth.
Profile wydajności z limitami/kwotami, test ochronny (ruch chaosu).
Red-team/bug-bounty: BOLA scripts, SSRF, signatures/replays, GraphQL-complexity.
TL; DR
1. Katalog API + ścisłe schematy.
2. OAuth2/OIDC dla klientów, mTLS/HMAC wewnątrz.
3. Obwód BOLA dla każdego zasobu (ABAC/RBAC).
4. Filtrowanie: normalizacja ścieżek/nagłówków, limity, zasady WAF.
5. Idempotencja, podpisy, powtórka/ochrona SSRF.
6. KMS/Skarbiec i tajna rotacja.
7. Obserwowalność, alerty, playbooks.