Web

Bezpieczeństwo API: Checklist dla Zespołów, Które Nie Chcą Skończyć w Nagłówkach

Po 47 audytach bezpieczeństwa stworzyliśmy listę najczęstszych błędów. 73% zespołów popełnia błąd #4.


W ciągu ostatnich dwóch lat przeprowadziliśmy 47 audytów bezpieczeństwa API dla klientów z różnych branż. Fintech, e-commerce, healthcare, SaaS. Pattern jest zawsze podobny - te same błędy, te same podatności.

91% audytowanych API miało co najmniej jedną krytyczną podatność

Top 10 błędów, które znajdujemy najczęściej

1

Brak rate limiting (87% przypadków)

Endpoint logowania bez limitu prób = brute force attack gotowy. Endpoint wysyłki emaili bez limitu = Twój serwer spamuje i ląduje na blacklistach.

Fix: Rate limiting per IP, per user, per endpoint. Różne limity dla różnych operacji.

2

IDOR - Insecure Direct Object Reference (81%)

GET /api/users/123/invoices - zmień 123 na 124 i widzisz cudze faktury. Klasyka.

Fix: Zawsze weryfikuj, czy user ma dostęp do zasobu. Nie ufaj ID z URL-a.

3

Verbose error messages (79%)

"User with email jan@firma.pl not found" - właśnie potwierdziłeś atakującemu, że ten email nie istnieje w systemie.

Fix: Generyczne komunikaty dla użytkownika, szczegóły tylko w logach.

4

JWT w localStorage (73%)

XSS = kradzież tokenu = przejęcie konta. localStorage jest dostępny dla każdego skryptu JS na stronie.

Fix: HttpOnly cookies dla tokenów. Refresh token rotation. Short-lived access tokens.

5

Brak walidacji input (68%)

API przyjmuje wszystko co wyślesz. age: "DROP TABLE users", email: "".

Fix: Schema validation (Zod, Joi, JSON Schema). Whitelist, nie blacklist.

Praktyczny checklist przed deployem

Authentication & Authorization
  • ☐ Czy każdy endpoint sprawdza autentykację?
  • ☐ Czy sprawdzasz autoryzację (nie tylko "czy zalogowany" ale "czy ma dostęp")?
  • ☐ Czy tokeny mają rozsądny czas życia?
  • ☐ Czy masz mechanizm unieważniania tokenów?
Input & Output
  • ☐ Czy walidacja jest server-side (nie tylko frontend)?
  • ☐ Czy sanityzujesz dane przed zapisem do DB?
  • ☐ Czy error messages nie ujawniają implementacji?
  • ☐ Czy response nie zawiera więcej danych niż trzeba?

Narzędzia, które używamy

  • OWASP ZAP - automatyczny skan podatności, darmowy
  • Burp Suite - manual testing, interceptowanie requestów
  • SQLMap - testowanie SQL injection
  • JWT.io - debugowanie tokenów (uwaga - nie wklejaj produkcyjnych!)
Chcesz audyt bezpieczeństwa swojego API?

Znajdziemy podatności zanim zrobią to inni. Raport z priorytetami i konkretnymi fixami.

Kategoria: Web
Udostępnij:

Krzysztof Nowicki

Ekspert Halo Soft

Potrzebujesz pomocy z podobnym projektem?

Skontaktuj się z nami - chętnie pomożemy!

Powiązane artykuły