Testy bezpieczeństwa Web Services/API
API to 83% ruchu web - i główny cel ataków. Broken authentication, injection, nadmierne uprawnienia, brak rate limiting. Znajdziemy podatności i pokażemy jak naprawić. Chronisz dane klientów i integratiorów.

API są wszędzie - i pełne luk których nikt nie testuje
Kompleksowe testy bezpieczeństwa API
Rekonesans
Mapowanie endpointów i dokumentacji
Testy OWASP Top 10
Auth, authorization, injection, rate limiting
Business logic
Luki w logice aplikacji
Czym są Testy bezpieczeństwa Web Services i API?
Testy bezpieczeństwa Web Services i API to specjalistyczne testy penetracyjne interfejsów programistycznych (REST, SOAP, GraphQL) obejmujące autoryzację, uwierzytelnianie, injection, rate limiting i bezpieczeństwo danych przesyłanych przez API.
| Atrybut | Wartość |
|---|---|
| Typy API | REST, SOAP, GraphQL, gRPC |
| Metodologia | OWASP API Security Top 10 |
| Zakres | Authn, authz, injection, business logic |
| Czas realizacji | 5-10 dni roboczych |
| Cena | od 25 000 PLN (stan na 2026) |
nFlo oferuje testy bezpieczeństwa web services i api dla firm w Polsce, zapewniając profesjonalne wsparcie i zgodność z najlepszymi praktykami branżowymi.
Problem
Facebook - 50 mln kont zhackowanych przez lukę w API (2018)
W 2018 atakujący wykorzystali lukę w Facebook API do kradzieży tokenów dostępu dla 50 milionów kont. Broken access control w “View As” feature + brak rate limiting = masowy wyciek. Kara: 5 mld USD od FTC.
Bez testów bezpieczeństwa API:
- Luki w authorization (BOLA/IDOR) = dostęp do cudzych danych
- Broken authentication = przejęcie kont
- Brak rate limiting = brute force i credential stuffing
- Injection (SQL, NoSQL, command) = przejęcie bazy
- Excessive data exposure = wyciek wrażliwych danych
- Business logic flaws = obejście płatności, nadmierne uprawnienia
Nasze rozwiązanie
OWASP API Security Top 10 + business logic
Testujemy API tak jak zrobiłby to atakujący - odkrywamy nieudokumentowane endpointy, testujemy autoryzację, próbujemy injection, szukamy luk w logice biznesowej. Dla każdej luki - Proof of Concept i kroki naprawy.
Co dostajesz:
- Mapowanie wszystkich endpointów (dokumentowane + ukryte)
- Analizę dokumentacji API (Swagger/OpenAPI jeśli dostępne)
- Testy autoryzacji (BOLA/IDOR - czy mogę zobaczyć cudze dane?)
- Testy uwierzytelniania (broken auth, weak tokens, session mgmt)
- Injection testing (SQL, NoSQL, command, LDAP, XPath)
- Rate limiting & brute force protection
- Mass assignment & excessive data exposure
- Security misconfiguration (CORS, headers, verbose errors)
- Business logic flaws (price manipulation, privilege escalation)
- GraphQL specific (batching attacks, introspection, depth limits)
- SOAP specific (XXE, WSDL enumeration)
- Szczegółowy raport z Proof of Concept
- Rekomendacje naprawy dla devs
- Opcjonalny retest po wdrożeniu poprawek
Dla kogo?
Ta usługa jest dla Ciebie, jeśli:
- Rozwijasz API dla klientów lub integratorów
- Masz mobile app lub SPA (React/Vue/Angular) - używają API
- API są publiczne lub accessible z internetu
- Chcesz spełnić wymagania audytorów/klientów (security testing)
- Dodałeś nowe endpointy i chcesz sprawdzić czy są bezpieczne
- Planujesz launch i chcesz uniknąć skandalu bezpieczeństwa
OWASP API Security Top 10 (2023)
Co testujemy
API1:2023 - Broken Object Level Authorization (BOLA/IDOR)
- Najczęstsza luka w API
- Przykład:
GET /api/users/123/profile- czy mogę zmienić 123 na 124 i zobaczyć cudze dane? - Test: Manipulacja ID obiektów w URL/body
API2:2023 - Broken Authentication
- Weak password policy
- Brak rate limiting na login
- Predictable tokens
- JWT misconfiguration (słaby secret, brak weryfikacji)
API3:2023 - Broken Object Property Level Authorization
- Mass assignment - dodawanie pól których nie powinno być
- Excessive data exposure - API zwraca więcej niż trzeba
- Przykład: POST user z polem
"isAdmin": true
API4:2023 - Unrestricted Resource Consumption
- Brak rate limiting = brute force/credential stuffing
- Brak pagination = DoS przez duże response
- Brak timeout = slowloris attacks
API5:2023 - Broken Function Level Authorization
- Vertical privilege escalation (user -> admin)
- Horizontal privilege escalation (user A -> user B)
- Przykład: zmiana metody GET na PUT i mam dostęp admin
API6:2023 - Unrestricted Access to Sensitive Business Flows
- Business logic flaws
- Przykład: kupno biletu za 0 zł przez manipulację ceny
- Automated abuse (scalping, inventory hoarding)
API7:2023 - Server Side Request Forgery (SSRF)
- API robi requesty do innych systemów
- Atakujący może zmienić target
- Dostęp do internal services (AWS metadata, internal APIs)
API8:2023 - Security Misconfiguration
- Verbose error messages (stack traces)
- Default credentials
- Unnecessary HTTP methods (TRACE, OPTIONS)
- Missing security headers
- CORS misconfiguration
API9:2023 - Improper Inventory Management
- Nieudokumentowane endpointy
- Stare wersje API (v1, v2) bez security updates
- Shadow API (API o których security nie wie)
API10:2023 - Unsafe Consumption of APIs
- API konsumuje dane z third-party API
- Brak walidacji danych external
- Trust third-party data = injection
Metodyka testów
Jak testujemy API
1. Discovery & Reconnaissance
- Passive: analiza aplikacji web/mobile (Burp, OWASP ZAP)
- Active: fuzzing endpointów (common paths, old versions)
- Documentation: Swagger/OpenAPI/WSDL analysis
- GraphQL: introspection query (if enabled)
2. Authentication & Session Management
- Registration flaws (weak validation, no email confirm)
- Login: brute force protection, rate limiting
- Password reset: predictable tokens, account takeover
- JWT analysis: algorithm confusion, weak secret, no signature verify
- OAuth: authorization code interception, redirect_uri manipulation
3. Authorization Testing
- BOLA/IDOR: horizontal (user A -> user B) i vertical (user -> admin)
- Dla każdego endpointu: czy może wywołać nieautoryzowany user?
- Method manipulation: GET -> POST/PUT/DELETE
4. Input Validation
- SQL injection (klasyczne i blind)
- NoSQL injection (MongoDB, etc.)
- Command injection (OS command execution)
- XML External Entity (XXE) dla SOAP
- LDAP injection
- XPath injection
5. Business Logic
- Price/quantity manipulation (negative prices, overflow)
- Race conditions (concurrent requests)
- Workflow bypass (skip payment step)
- Privilege escalation via mass assignment
6. Rate Limiting & DoS
- Brute force protection na login/register
- API abuse (unlimited requests)
- Resource exhaustion (large response, complex queries)
7. GraphQL Specific
- Introspection (schema disclosure)
- Batching attacks (multiple queries in one request)
- Depth limit bypass (nested queries -> DoS)
- Field suggestions (typo -> schema leak)
8. Data Exposure
- Sensitive data in response (passwords, tokens, PII)
- Unnecessary fields (internal IDs, debug info)
- Error messages revealing structure
Przykładowe luki które znajdowaliśmy
Case 1: BOLA w banking API
Endpoint: GET /api/accounts/{accountId}/transactions
Luka: Brak weryfikacji czy user ma dostęp do accountId
Exploit: Zmiana accountId=12345 na 12346 = dostęp do cudzych transakcji
Impact: Wyciek danych finansowych wszystkich klientów
Fix: Backend sprawdza czy current user owns accountId
Case 2: Mass assignment w user profile
Endpoint: PUT /api/users/{userId}/profile
Luka: API przyjmuje dowolne pola w body
Exploit: Dodanie "role": "admin" w request body
Impact: Privilege escalation user -> admin
Fix: Whitelist dozwolonych pól (name, email, etc.) - reszta ignorowana
Case 3: JWT algorithm confusion
Auth: JWT z algorytmem RS256 (public key verification) Luka: Backend akceptuje też HS256 (symmetric key) Exploit: Zmiana algorymy na HS256 i podpisanie public key Impact: Forge arbitrary tokens = account takeover Fix: Enforce algorytm RS256, reject HS256
Case 4: GraphQL batching DoS
Query: 100x { users { posts { comments { author }}}} w jednym request
Luka: Brak depth limit i query complexity analysis
Exploit: DoS przez expensive queries
Impact: API down
Fix: Implement depth limiting, query complexity cost analysis, rate limiting
Case 5: SSRF przez file upload
Endpoint: POST /api/upload - file from URL
Luka: Brak walidacji URL
Exploit: "url": "http://169.254.169.254/latest/meta-data/" (AWS metadata)
Impact: Dostęp do AWS credentials
Fix: Whitelist dozwolonych domen, block private IPs
Często zadawane pytania
Czy potrzebujemy API documentation?
Lepiej mieć (Swagger/OpenAPI), ale nie musisz. Możemy zreverse-engineer API przez traffic analysis (Burp). Dla GraphQL introspection query daje schema (jeśli włączone).
Jak długo trwają testy API?
Zależy od wielkości API. Małe API (10-20 endpointów): 3-5 dni. Średnie (50-100 endpointów): 1-2 tygodnie. Duże (200+ endpointów, GraphQL): 3-4 tygodnie.
Czy testujecie też frontend (web/mobile)?
Tak, ale to osobna usługa. API testy fokusują się na backend logic. Dla full coverage rekomendujemy: API pentest + web app pentest + mobile app pentest.
Co jeśli API jest internal (nie public)?
Możemy testować przez VPN lub z Waszej sieci (on-site/VDI). Lub możemy przetestować przed publishem (staging environment).
Ile kosztują testy API?
Małe API (10-20 endpointów): 15000-25000 PLN. Średnie (50-100 endpointów): 30000-50000 PLN. Duże/złożone (GraphQL, microservices): 60000-100000+ PLN. Wycena po analizie scope.
Jak pracujemy
Sprawdzony proces realizacji usługi.
Discovery
Mapowanie API i dokumentacji
Authentication tests
Broken auth, weak tokens, session mgmt
Authorization tests
BOLA/IDOR, privilege escalation
Input validation
Injection, XXE, fuzzing
Raport
PoC dla każdej luki + kroki naprawy
Korzyści dla Twojej firmy
Co zyskujesz wybierając tę usługę.
Chronisz dane klientów
Znajdź BOLA/IDOR zanim wyciekną dane
Unikasz kar RODO
Wyciek danych przez API = do 20M EUR kary
Zaufanie partnerów
Integratorzy wymagają security testów
Lepsza jakość kodu
Znajdź błędy logiczne i design flaws
Powiązane artykuły
Pogłęb swoją wiedzę z naszej bazy wiedzy.
Dlaczego SOC jest praktycznie niezbędny dla zgodności z KSC/NIS2?
Przepisy KSC/NIS2 nie wymagają wprost posiadania SOC. Jednak 24-godzinny obowiązek zgłaszania incydentów poważnych sprawia, że bez dojrzałych mechanizmów monitorowania spełnienie wymogów staje się praktycznie niemożliwe.
Czytaj więcej →Vulnerability Disclosure - Jak odpowiedzialnie zgłaszać podatności
Kompletny przewodnik po odpowiedzialnym zgłaszaniu podatności. Responsible disclosure, CVE, security.txt, aspekty prawne w Polsce.
Czytaj więcej →Łańcuchowa eksploitacja n8n: jak RidgeBot wykrywa przejęcie workflow w praktyce
Seria krytycznych podatności w n8n pokazuje, jak łańcuchowa eksploitacja może prowadzić do całkowitego przejęcia infrastruktury automatyzacji. RidgeBot jako platforma do ciągłej walidacji bezpieczeństwa wykrywa takie scenariusze zanim zrobią to atakujący.
Czytaj więcej →Skontaktuj sie z opiekunem
Porozmawiaj o Testy bezpieczeństwa Web Services/API z dedykowanym opiekunem handlowym.
