API SECURITY PENETRATION TESTING
REST, GraphQL un gRPC saskarņu drošības pārbaude ar vairākiem autorizācijas žetoniem un secīgiem uzbrukumu scenārijiem.
Kam tas noder
Kad šis pakalpojums ir piemērots
API drošības pārbaudes virzieni
- BOLA (Broken Object Level Authorization) un BFLA autorizācijas caurumu atklāšana
- JWT žetonu un OAuth 2.0 / OIDC autentifikācijas kļūdas
- Masveida piešķiršana (Mass Assignment) un pārmērīga datu atklāšana
- Rate Limiting un resursu izsmelšanas (DoS) aizsardzības pārbaude
Ko saņemsiet
- Endpointu, lomu un objektu piekļuves matrica
- Apstiprināti vairāku identitāšu uzbrukuma scenāriji
- OWASP API Security Top 10 kartējums
- Droši curl/HTTP vai testa koda reproducēšanas piemēri
- Izstrādātāju labošanas ieteikumi autorizācijas slānim
- Regresijas testa kandidāti CI/CD un retesta statuss
Darba gaita
Kā notiek darbs
Tvērums un drošības robežas. Apstiprinām mērķi, sistēmas, lomas, vidi, izņēmumus, atļautās darbības un avārijas apturēšanas kontaktu.
Informācijas un piekļuves sagatavošana. Drošā kanālā saņemam tikai darbam nepieciešamo dokumentāciju, kontus, konfigurācijas vai pierādījumus.
API saskarņu un mikroservisu testēšana. Pārbaudām autorizācijas loģiku, datu noplūdes riskus un saskarņu noturību pret ļaunprātīgiem pieprasījumiem.
Validācija un ziņošana. Apstiprinām atradumus, novēršam kļūdainus pozitīvus rezultātus un sasaistām risku ar biznesa ietekmi un īpašnieku.
Pārruna un turpinājums. Izskaidrojam prioritātes, atbildam komandām, vienojamies par labošanas termiņiem un, ja paredzēts, veicam retestu.
Pirms sadarbības
Biežāk uzdotie jautājumi
Cik ilgi parasti ilgst darbs?
Termiņu nosaka sistēmu skaits, lomas, vides, pieejamā dokumentācija un saskaņotie ierobežojumi. Pēc sākuma informācijas saņemšanas darba apjomā norādām posmus, klienta iesaisti un konkrētu grafiku.
Ko nepieciešams sagatavot pirms darba sākuma?
Parasti vajadzīgs sistēmas vai procesa īpašnieks, aktuāls tvērums, piekļuves un testa konti, arhitektūras vai procesu apraksts, kritiskie biznesa scenāriji un ārkārtas kontakts. Nekad nesūtiet paroles parastā tīmekļa formā.
Vai rezultātā saņemsim tikai tehnisku ziņojumu?
Nē. Paredzam vadības kopsavilkumu, prioritizētu detalizēto daļu, pierādījumus, labošanas ieteikumus un rezultātu pārrunu. Ja pakalpojumam tas ir piemērots, iekļaujam retestu vai ieviešanas ceļvedi.
Kāpēc API testam vajag vairākus kontus?
Objektu un funkciju autorizācijas defekti parādās, salīdzinot, ko drīkst darīt dažādi lietotāji, lomas vai nomnieki. Viens administratora konts nevar pierādīt, ka izolācija starp klientiem darbojas.
Ko darīt, ja nav OpenAPI dokumentācijas?
Endpointus var rekonstruēt no lietotnes trafika, koda vai vārtejas žurnāliem, taču tas palielina darbu un var neatklāt reti izmantotas funkcijas. Pēc testa izveidojiet uzturētu API inventāru un pievienojiet shēmas validāciju piegādes procesā.
Saistītie nākamie soļi
Tīmekļa lietotņu testēšana
Autentifikācijas, autorizācijas (BOLA/IDOR), sesiju un biznesa loģikas manuāls pentests dažādām lietotāju lomām.
Mobilo lietotņu testēšana
Binārā koda, lokālās datu glabāšanas, šifrēšanas un backend API kopēja pārbaude reālās iekārtās.
Pirmkoda pārbaude un DevSecOps
Manuāla un automatizēta pirmkoda analīze, SAST/SCA rīku noskaņošana un drošības vārtu ieviešana jūsu CI/CD izstrādes ciklā.
AI Pārvaldība un Atbilstība
Prompt Injection, RAG datu noplūžu, aģentu tiesību un generatīvā AI sistēmu drošības novērtējums.