Jak z perspektywy testera wejść do obszaru cybersecurity?

Tester może wejść do cybersecurity bez zaczynania kariery od zera, bo już umie to, czego security potrzebuje najbardziej: szukać nieoczywistych scenariuszy, myśleć ryzykiem i porządnie raportować. Jeśli jesteście testerami, brakuje Wam zwykle trzech rzeczy: podstaw HTTP i autoryzacji, znajomości OWASP i praktyki na legalnych środowiskach. Ten artykuł daje Wam ścieżkę w czterech etapach, kompletny test IDOR w Postmanie krok po kroku i mapę certyfikatów z cenami sprawdzonymi 11 października 2026.

Różnica między QA a security zaczyna się od pytania. W klasycznym testowaniu pytacie: „czy funkcja działa zgodnie z wymaganiem?”. W cybersecurity dochodzi drugie: „czy tę funkcję da się wykorzystać w sposób niezamierzony?”. Czy użytkownik zobaczy dane innej osoby? Czy API ujawnia za dużo? Czy backend naprawdę pilnuje uprawnień?

Jeśli odpowiadacie za produkt i chcecie sprawdzić jego odporność, zacznijcie od testów bezpieczeństwa aplikacji dla firm. Jeśli jesteście testerami i chcecie wejść w ten obszar praktycznie, najkrótsza droga to szkolenie Cybersecurity: Testy bezpieczeństwa.

Dlaczego tester ma dobrą bazę do wejścia w cybersecurity?

Tester ma dobrą bazę, bo wiele podatności to w praktyce błędy logiki, wymagań i uprawnień, czyli teren, który QA zna na co dzień. Według OWASP Top 10:2025 pierwsze miejsce zajmuje Broken Access Control, a każda ze zbadanych aplikacji miała jakąś formę tego błędu. Do jego wykrycia rzadko potrzeba exploita. Częściej wystarczy dwa konta testowe i cierpliwość.

Czym różni się testowanie oprogramowania od testowania bezpieczeństwa?

Testowanie oprogramowania sprawdza, czy system działa zgodnie z wymaganiami. Testowanie bezpieczeństwa sprawdza, czy system jest odporny na nieuprawnione użycie, manipulację i błędną konfigurację. Różnicę najlepiej widać na jednym ekranie.

• Test funkcjonalny: użytkownik loguje się poprawnym loginem i hasłem, system pokazuje jego panel. Działa.
• Test bezpieczeństwa: zalogowany użytkownik zmienia identyfikator dokumentu w adresie albo w żądaniu API. Sprawdzacie, czy dostanie dokument innej osoby.

W pierwszym przypadku funkcja działa. W drugim sprawdzacie, czy system chroni dane i egzekwuje uprawnienia po stronie serwera. Jak łączyć oba podejścia w zespole, opisujemy w artykule testowanie bezpieczeństwa: rola testów manualnych i automatycznych.

Jak tester może wejść do cybersecurity krok po kroku?

Najpierw podstawy techniczne, potem OWASP, potem kontrola dostępu i API, a narzędzia na końcu. Najgorszy start to skakanie po narzędziach. Skaner bez zrozumienia HTTP generuje wyniki, których nie umiecie ocenić ani opisać developerowi.

Krok 1. Wzmocnijcie podstawy techniczne

Nikt nie wymaga od Was, żebyście byli administratorami Linuxa ani programistami backendu. Musicie rozumieć, jak elementy systemu ze sobą rozmawiają.

• HTTP i HTTPS, kody statusu, nagłówki, request i response
• cookies, sesje i tokeny, różnica między uwierzytelnianiem (401) a autoryzacją (403)
• API i JSON, podstawy SQL
• podstawy sieci: DNS, adresy IP, porty, plus Linux w terminalu
• podstawy jednego języka: Python, JavaScript albo Java

Uporządkować te podstawy pomogą szkolenia Wprowadzenie do testowania API w Postmanie, Bazy danych SQL dla testerów oraz Programowanie Python dla testerów. Ściągę z metod HTTP znajdziecie w artykule Metody HTTP: przewodnik dla testera API.

Krok 2. Poznajcie OWASP Top 10

OWASP Top 10 to lista najważniejszych ryzyk aplikacji webowych, którą łatwo przełożyć na scenariusze testowe. Według edycji OWASP Top 10:2025 kategoria Broken Access Control utrzymała pierwsze miejsce. OWASP podaje, że 100 procent przebadanych aplikacji miało jakąś jej formę, średni wskaźnik występowania wyniósł 3,74 procent, a kategoria obejmuje 40 słabości CWE. Wśród przykładów OWASP wprost wymienia IDOR, czyli dostęp do cudzego konta przez podanie jego identyfikatora.

Drugi dokument dla testera to OWASP API Security Top 10 z 2023 roku. Jego pozycja API1:2023 to Broken Object Level Authorization, czyli ten sam problem w API: serwer nie sprawdza, czy zalogowany użytkownik ma prawo do obiektu, o który prosi. Kiedy zespół chce wejść w temat od strony kodu, przyda się szkolenie Bezpieczne tworzenie aplikacji (OWASP).

Szerszy kontekst dają dwa dokumenty. OWASP Web Security Testing Guide opisuje metodykę testów aplikacji webowych. NIST Cybersecurity Framework 2.0 z 2024 roku pokazuje bezpieczeństwo jako zarządzanie ryzykiem w całej organizacji.

Krok 3. Testujcie kontrolę dostępu i API

Kontrola dostępu to najlepszy punkt wejścia, bo wymaga rozumienia ról i scenariuszy negatywnych, a nie zaawansowanych technik. Na start sprawdzajcie:

• czy użytkownik widzi tylko swoje dane, także po podmianie ID w adresie i w żądaniu API
• czy rola bez uprawnień administratora nie wejdzie do panelu ani nie wywoła jego endpointu
• czy frontend nie jest jedyną warstwą, która ukrywa przyciski i dane
• czy po wylogowaniu stary token przestaje działać
• czy API nie zwraca pól, których ekran nie pokazuje

Jeśli w organizacji nie ma checklisty ról i uprawnień, warto ją spisać w dokumentacji testowej, żeby testy nie zależały od pamięci jednej osoby. Część tych kontroli da się potem włączyć do regresji przez automatyzację testów API.

Krok 4. Narzędzia, ale dopiero teraz

Zasada jest jedna: ćwiczycie tylko na legalnych środowiskach. Testowanie cudzej aplikacji bez zgody właściciela to nie nauka, tylko ryzyko prawne. Skan pasywny ZAP w pipeline opisujemy przy szkoleniu Automatyczne testy bezpieczeństwa z OWASP ZAP.

Krok 5. Raportujcie podatność jak ryzyko

Zgłaszać błędy już umiecie, to Wasza przewaga. W security raport musi dodatkowo pokazać wpływ i rekomendację. Zwykły raport mówi: „użytkownik widzi cudzy dokument”. Raport podatności mówi, jak to odtworzyć, kogo dotyczy, jak poważne jest ryzyko i co naprawić. Pełny przykład takiego raportu znajdziecie na końcu kolejnej sekcji.

Jak wygląda test IDOR w Postmanie krok po kroku?

Test IDOR w Postmanie polega na tym, że jako użytkownik A prosicie API o zasób użytkownika B i sprawdzacie, czy serwer odmówi. Poniższy przykład uruchomiliśmy 11 października 2026 na lokalnym serwerze testowym w dwóch wersjach, podatnej i poprawionej, w Postman CLI 1.73.0. Nie ćwiczcie go na systemie, do którego nie macie pisemnej zgody.

Krok 1. Przygotujcie dwa konta i dwa zasoby. Potrzebujecie dwóch użytkowników testowych, na przykład Anny i Bartka, oraz po jednym obiekcie każdego z nich. U nas to faktury 1001 (Anna) i 1002 (Bartek). Zapiszcie je w środowisku Postmana, żeby test był powtarzalny.

Środowisko „lokalne” (Environments, nowe środowisko)
baseUrl        http://localhost:3000
tokenAnna      token-anna
fakturaAnny    1001
fakturaBartka  1002
emailAnny      anna@example.test
emailBartka    bartek@example.test

Krok 2. Żądanie kontrolne: Anna pobiera swoją fakturę. Utwórzcie żądanie GET na adres {{baseUrl}}/api/invoices/{{fakturaAnny}}. W zakładce Authorization wybierzcie Bearer Token i wpiszcie {{tokenAnna}}. W zakładce Scripts, w sekcji Post-response, dodajcie testy:

pm.test("Własna faktura: 200", function () {
    pm.response.to.have.status(200);
});
pm.test("Faktura należy do Anny", function () {
    pm.expect(pm.response.json().email).to.eql(pm.environment.get("emailAnny"));
});

To żądanie musi przejść. Jeśli nie przechodzi, problem leży w danych testowych albo w tokenie, a nie w uprawnieniach, i nie ma sensu iść dalej.

Krok 3. Właściwy test IDOR: Anna podmienia ID. Zduplikujcie żądanie i zmieńcie tylko identyfikator na {{fakturaBartka}}. Token zostaje Anny. Testy sprawdzają dwie rzeczy: kod odmowy i brak cudzych danych w treści odpowiedzi.

pm.test("Cudza faktura: 403 albo 404", function () {
    pm.expect(pm.response.code).to.be.oneOf([403, 404]);
});
pm.test("Brak danych Bartka w odpowiedzi", function () {
    pm.expect(pm.response.text()).to.not.include(pm.environment.get("emailBartka"));
});

Dlaczego 403 albo 404? Oba kody są poprawną odmową. Wiele zespołów woli 404, bo nie zdradza, że obiekt o takim ID istnieje. Drugi test jest ważniejszy, niż wygląda: zdarzają się API, które zwracają 403, a w treści błędu i tak wysyłają cudzy obiekt.

Krok 4. Żądanie bez tokenu. Trzecie żądanie to faktura Anny bez nagłówka Authorization, z testem na 401. Odróżnia ono brak uwierzytelnienia (401) od braku uprawnień (403 albo 404).

pm.test("Bez logowania: 401", function () {
    pm.response.to.have.status(401);
});

Krok 5. Uruchomcie kolekcję i odczytajcie wynik. W aplikacji Postman użyjcie Run collection. W CI tę samą kolekcję, wyeksportowaną do pliku JSON razem ze środowiskiem, uruchamia Postman CLI. Instalacja na macOS i Linuxie albo przez npm:

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
npm install -g postman-cli

Logowanie kluczem API z Waszego konta Postman jest potrzebne, gdy chcecie uruchamiać kolekcje z chmury po ID albo wysyłać wyniki przebiegu do Postmana. Klucz w CI trzymajcie w sekretach, nigdy w repozytorium:

postman login --with-api-key "$POSTMAN_API_KEY"
postman collection run idor-faktury.postman_collection.json -e lokalne.postman_environment.json

Lokalny plik kolekcji Postman CLI uruchamia także bez logowania; wtedy na końcu raportu wypisuje tylko informację, że do publikacji wyników w chmurze potrzebne są dane logowania.

Źródło: uruchomienie własne Quality Island, lokalny serwer testowy, Postman CLI 1.73.0, 11.10.2026.

Poprawka po stronie serwera to jedna linia logiki: przed zwróceniem obiektu sprawdzić, czy jego właściciel to zalogowany użytkownik. OWASP przy API1:2023 dodaje, że losowe identyfikatory typu GUID utrudniają zgadywanie, ale nie zastępują tej kontroli. Ukrycie ID w UUID to jak schowanie klucza pod wycieraczką z napisem w innym kolorze: trudniej trafić, ale zamka nadal nie ma.

Jakie kompetencje testera najbardziej pomagają w cybersecurity?

Najbardziej pomagają Wam te, których nie zastąpi żadne narzędzie: analiza wymagań, projektowanie przypadków, eksploracja, raportowanie, komunikacja i myślenie procesowe.

Analiza wymagań

Sprawdzacie, czy wymagania opisują role, uprawnienia, ochronę danych i zachowanie przy nieuprawnionej akcji. Jeśli podatności biorą się z chaosu w wymaganiach, pomaga strategia jakości oprogramowania.

Projektowanie przypadków testowych

Projektujecie przypadki dla logowania, resetu hasła, kontroli dostępu, uploadu plików i scenariuszy nadużyć. Dobrze opisane, są powtarzalne, a nie zależne od intuicji jednej osoby.

Testy eksploracyjne

Obserwujecie aplikację, stawiacie hipotezy, manipulujecie danymi. W security to sposób na luki, których nie ma w żadnej checkliście.

Raportowanie i komunikacja

Znalezienie podatności to połowa pracy. Druga połowa to opis, który developer zrozumie technicznie, a manager biznesowo. Testerzy robią to na co dzień, tłumacząc priorytety błędów.

Myślenie procesowe

Pojedyncza podatność bywa objawem braku testów, code review albo kontroli w CI/CD. Gdy organizacja chce połączyć security z procesem wytwarzania, przydaje się budowa procesów CI/CD z bramkami jakości.

Jak wygląda ścieżka rozwoju testera w stronę security?

Ścieżka ma cztery etapy, od testera świadomego bezpieczeństwa do specjalisty testów bezpieczeństwa. Nie trzeba przechodzić ich szybko. Każdy etap daje wartość Waszemu zespołowi już w trakcie.

Czy trzeba umieć programować? Nie trzeba być programistą, ale podstawy bardzo pomagają. Python przyda się do automatyzacji drobnych zadań, JavaScript do rozumienia aplikacji webowych, Bash do pracy w Linuxie. Dobry start to Programowanie Java dla testerów albo kurs Pythona wymieniony wyżej.

Które certyfikaty cybersecurity wybrać i ile kosztują?

Certyfikat wybierajcie pod kierunek, nie pod modę. Testerowi aplikacji na start najwięcej daje praktyka i jeden certyfikat podstawowy, a ofensywne i menedżerskie warto zostawić na później. Ceny w tabeli to kwoty, które dało się odczytać na stronach wydawców 11 października 2026. Tam, gdzie wydawca nie podaje ceny publicznie, piszemy to wprost.

Źródło: strony certyfikatów CompTIA, EC-Council, OffSec, ISC2 i ISACA, odczyt 11.10.2026. Ceny w USD bez podatków lokalnych.

Pracodawcy coraz częściej pytają nie tylko o certyfikat, ale o portfolio i realne zrozumienie aplikacji. Certyfikat ma wspierać ścieżkę, a nie ją zastępować. Szerszy przegląd certyfikatów spoza ISTQB znajdziecie w artykule certyfikaty inne niż ISTQB.

Jak zbudować portfolio i zacząć security w codziennej pracy QA?

Wasze portfolio budujecie na aplikacjach treningowych i we własnym laboratorium, a pierwsze zadania security wykonujecie w obecnym projekcie, bez zmiany stanowiska. Do portfolio warto dodać:

• raporty podatności z ćwiczeń na Juice Shop albo WebGoat, w formacie z boxu wyżej
• kolekcję Postmana z testami uprawnień, taką jak w przykładzie IDOR
• checklistę testów bezpieczeństwa API i kontroli dostępu
• notatki z nauki Burp Suite albo ZAP i krótkie wpisy o sposobie myślenia

W pracy QA zacznijcie od czterech rzeczy: scenariuszy kontroli dostępu w regresji, sprawdzania nadmiarowych pól w API, testów po wylogowaniu i retestów po poprawkach bezpieczeństwa. Portfolio nie może zawierać danych z prawdziwych systemów bez zgody.

Jak firmy mogą rozwijać testerów w kierunku cybersecurity?

Firmy mogą zacząć od szkolenia całego zespołu QA, włączenia bezpieczeństwa do strategii testów i audytu obecnego procesu. W czerwcu 2026 szkoliliśmy w ten sposób zespół AgroApp: zamknięte szkolenie z testów bezpieczeństwa dla początkujących objęło 14 osób przez dwa dni. Z naszego doświadczenia wynika, że największy efekt daje szkolenie połączone z jednym konkretnym zadaniem po nim, na przykład testami uprawnień w API, które zespół od razu dopisuje do regresji.

• Szkolenie. OWASP, API, kontrola dostępu i raport ryzyka dla testerów i liderów QA.
• Strategia. Bezpieczeństwo jako element strategii jakości, a nie zadanie na koniec projektu.
• Audyt. Audyt QA pokazuje, gdzie organizacja traci kontrolę: brak kryteriów akceptacji, brak testów API, opóźnione testy security.

Firmom, które są dostawcami dla podmiotów objętych NIS2, przyda się też strona o testach bezpieczeństwa dostawców pod NIS2.

Jakie błędy popełniają testerzy wchodzący do cybersecurity?

Najczęściej zaczynają od narzędzi zamiast od podstaw i ćwiczą na interfejsie, pomijając API. Tabela zbiera sześć błędów i to, co robić zamiast nich.

Gdzie rozwijać się dalej?

Rozwijajcie się w społeczności, bo security zmienia się szybciej niż sylabusy. Wiedzę o QA i bezpieczeństwie publikujemy na Strefie QA, gdzie opisujemy dziury bezpieczeństwa, które QA widzi, a nikt nie słucha. Możliwości współpracy pokazuje QA Board.

Na żywo o testowaniu i bezpieczeństwie rozmawia się na Testing Ground Conference, która obejmuje także obszar bezpieczeństwa; edycja 2027 odbędzie się w maju w Warszawie. Pełny kalendarz wydarzeń znajdziecie w zestawieniu konferencje testerskie w Polsce. Jeśli jesteście na wcześniejszym etapie kariery, zacznijcie od artykułu jak zostać testerem oprogramowania.

Powiązane na blogu Quality Island

• Testowanie bezpieczeństwa: rola testowania manualnego i automatycznego
• Testy penetracyjne a testy bezpieczeństwa
• Testy API: kurs Postmana
• Certyfikaty inne niż ISTQB
• Cyber Resilience Act: nowy obowiązek testowania podatności

Pełna lista źródeł

• OWASP Foundation, OWASP Top 10:2025, A01 Broken Access Control, 2025: pierwsze miejsce, 100 procent przebadanych aplikacji, wskaźnik 3,74 procent, 40 CWE, IDOR w przykładach (odczyt 11.10.2026)
• OWASP Foundation, OWASP API Security Top 10, API1:2023 Broken Object Level Authorization, 2023 (odczyt 11.10.2026)
• OWASP Foundation, Web Security Testing Guide oraz projekty Juice Shop i WebGoat, 2026
• MITRE, CWE-639: Authorization Bypass Through User-Controlled Key, 2026
• NIST, The NIST Cybersecurity Framework (CSF) 2.0, 2024
• Postman, dokumentacja skryptów testowych i instalacja Postman CLI, 2026 (odczyt 11.10.2026)
• PortSwigger Web Security Academy, Insecure direct object references (IDOR), 2026
• CompTIA, Security+ V7, 2026: SY0-701, liczba pytań, czas, próg, zapowiedź V8 (odczyt 11.10.2026)
• EC-Council, Certified Ethical Hacker, 2026: opłata za wniosek o dopuszczenie (odczyt 11.10.2026)
• OffSec, PEN-200 i OSCP+, 2026: ceny 1 749, 1 699 i 2 749 USD, egzamin 24 h (odczyt 11.10.2026)
• ISC2, CISSP, 2026: wymagane 5 lat doświadczenia (odczyt 11.10.2026)
• ISACA, CISM, 2026: 575 i 760 USD, opłata za wniosek 50 USD (odczyt 11.10.2026)
• Dane własne Quality Island, 2026: szkolenie zamknięte z testów bezpieczeństwa dla AgroApp (14 osób, czerwiec 2026), uruchomienie testu IDOR w Postman CLI 1.73.0 (11.10.2026)