PromocjaProfesjonalna księga znaku warta 1 999 zł netto za darmoSprawdź warunki
Kraje ▾
🇵🇱 Polska🇩🇪 Niemcy🇬🇧 Wielka Brytania🇫🇷 Francja🇪🇸 Hiszpania🇮🇹 Włochy🇨🇿 Czechy🇳🇱 Holandia🇦🇹 Austria🇺🇸 USAWszystkie kraje →
+48 601 162 666

Usługi

SEO 2026

Kanały i sprzedaż

Podaj branżę i zobacz, co zrobimy →

Efekty

Portfolio

Zobacz, jakie efekty osiągniesz →

O firmie

Jak działamy

Poznaj inne nasze firmy →

Baza wiedzy

Pomoc

Działania jakie wykonujemy →
Strona główna / Oferta / Audyty / Audyt bezpieczeństwa

Audyt bezpieczeństwa strony

Sprawdzamy stronę w 22 obszarach i 132 punktach kontrolnych: od domeny, certyfikatów i wtyczek po logowanie, API, płatności i kopie zapasowe. Łączymy skanowanie z ręczną weryfikacją, a każde ustalenie dostaje dowód i priorytet naprawy.

22obszary badania
132punkty kontrolne
P0–P3priorytety napraw
Dlaczego audyt

Po co audyt bezpieczeństwa

Włamanie oznacza utratę danych, spadek pozycji w Google, ryzyko kar i utratę zaufania klientów.

Zapobiegaj atakom

Wykrywamy luki, zanim zostaną wykorzystane.

Ochrona SEO

Zhakowana strona traci pozycje i bywa oznaczana jako niebezpieczna.

Zaufanie klientów

Bezpieczna strona i dane to fundament wiarygodności.

SSLcertyfikaty i HTTPS
CMSaktualizacje i wtyczki
Backupkopie i odzysk
OchronaWAF i monitoring
Zakres audytu

Co dokładnie sprawdzamy

Przeglądamy najważniejsze obszary bezpieczeństwa serwisu i serwera.

Certyfikaty i nagłówki

  • SSL/TLS i HTTPS
  • Nagłówki bezpieczeństwa
  • Mixed content

Aktualizacje i podatności

  • CMS, motyw, wtyczki
  • Znane podatności (CVE)
  • Konfiguracja

Kopie zapasowe

  • Polityka backupów
  • Test odzyskiwania
  • Lokalizacja kopii

Dostępy i uprawnienia

  • Konta i hasła
  • Uprawnienia użytkowników
  • Logowanie i 2FA

Ochrona przed atakami

  • WAF i firewall
  • Ochrona przed botami/DDoS
  • Zabezpieczenia formularzy

Monitoring i logi

  • Wykrywanie incydentów
  • Logi i alerty
  • Skanowanie malware
Katalog kontroli

22 obszary i 132 punkty kontrolne

Każdy obszar ma sześć kontroli, opis wymaganego dowodu i kryterium oceny. Nie każdy test jest wykonalny w każdym wariancie: część wymaga kodu, kont użytkowników albo dostępu do hostingu. Rozwiń kartę, żeby zobaczyć punkty kontrolne.

22obszary od domeny i hostingu po API, płatności i procesy
132punkty kontrolne z wymaganym dowodem i kryterium oceny
4tryby badania: zewnętrzny, z kontami, konfiguracja i kod, operacyjny
P0–P3priorytety napraw oddzielone od punktacji CVSS
Domena i środowisko
01

Domena, DNS i inwentaryzacja zasobów

Tryb Z / K / O

Ustalamy, co należy do serwisu i które publiczne zasoby wypadły spod nadzoru.

Kryterium: Każdy zasób ma właściciela i uzasadnienie istnienia.

Punkty kontrolne (6)
  1. 01.1Lista domen, subdomen, paneli, API i środowisk z przypisanymi właścicielami.
  2. 01.2Konta rejestratora i DNS: MFA, osoby uprawnione i procedura odzyskania dostępu.
  3. 01.3Terminy odnowienia domen i odbiorcy powiadomień, także po zmianie wykonawcy.
  4. 01.4Rekordy wskazujące wycofane usługi i ryzyko przejęcia subdomeny.
  5. 01.5DNSSEC i CAA dopasowane do środowiska i odnawiania certyfikatów.
  6. 01.6Zapomniane wersje serwisu i środowiska testowe: dostęp, dane, aktualizacje.
02

Hosting, serwer i konfiguracja

Tryb Z / K / O

Sprawdzamy, czy infrastruktura nie udostępnia zbędnych usług, danych i uprawnień.

Kryterium: Dostępne pozostają tylko potrzebne usługi. Brak dostępu do serwera opisujemy jako ograniczenie audytu.

Punkty kontrolne (6)
  1. 02.1Wersje i wsparcie systemu, serwera WWW i środowiska uruchomieniowego, na przykład PHP.
  2. 02.2Otwarte usługi i porty porównane z uzgodnioną listą, w granicach zasad hostingu.
  3. 02.3Dostęp do paneli, SSH i SFTP, bazy danych i magazynów plików.
  4. 02.4Uprawnienia katalogów, izolacja innych witryn i oddzielenie produkcji od testów.
  5. 02.5Publiczne pliki konfiguracyjne, archiwa, repozytoria i komunikaty debugowania.
  6. 02.6Zapora, dostęp do serwera źródłowego za CDN i podział obowiązków z hostingiem.
Szyfrowanie i komponenty
03

HTTPS, certyfikaty i szyfrowanie

Tryb Z / K / O

Weryfikujemy ochronę transmisji na wszystkich odcinkach, od przeglądarki po serwer źródłowy.

Kryterium: Certyfikat i transmisja działają w całym zakresie. Poprawny TLS sam nie świadczy o braku podatności aplikacji.

Punkty kontrolne (6)
  1. 03.1Ważność certyfikatu, nazwy domen i łańcuch zaufania na wszystkich publicznych hostach.
  2. 03.2Automatyczne odnowienie, alerty i dostęp do klucza prywatnego.
  3. 03.3Obsługiwane wersje TLS i zestawy szyfrów.
  4. 03.4Przekierowania na HTTPS, adresy formularzy i mieszana treść.
  5. 03.5HSTS i zakres subdomen, sprawdzony przed rozszerzeniem polityki.
  6. 03.6Szyfrowanie i weryfikacja certyfikatu między CDN lub proxy a serwerem.
04

CMS, wtyczki, motywy i zależności

Tryb Z / K / O

Oceniamy znane podatności, pochodzenie oprogramowania i realną możliwość jego aktualizacji.

Kryterium: Każdy problem ma decyzję: aktualizacja, wymiana, ograniczenie ekspozycji albo jawna akceptacja ryzyka.

Punkty kontrolne (6)
  1. 04.1Inwentarz CMS, aktywnych i nieaktywnych dodatków, motywów i bibliotek.
  2. 04.2Wersje potwierdzone w panelu lub w plikach, bez polegania na publicznym banerze.
  3. 04.3Porównanie ze znanymi podatnościami, komunikatami producentów i katalogiem CISA KEV.
  4. 04.4Wsparcie producenta, źródło instalacji, integralność i dodatki porzucone.
  5. 04.5WordPress: konta administratorów, uprawnienia plików i edycja plików z panelu.
  6. 04.6Procedura aktualizacji: kopia, test, regresja i możliwość wycofania zmiany.
Tożsamość i kontrola dostępu
05

Logowanie i odzyskiwanie dostępu

Tryb Z / U / K

Badamy potwierdzanie tożsamości i ścieżki, które mogą ominąć zabezpieczenia.

Kryterium: Ścieżka alternatywna nie osłabia podstawowego logowania.

Punkty kontrolne (6)
  1. 05.1Wszystkie kanały logowania: panel, konto klienta, API, SSO i aplikacje pomocnicze.
  2. 05.2MFA dla kont uprzywilejowanych i ochrona zmiany drugiego składnika.
  3. 05.3Polityka haseł i ochrona przed hasłami ujawnionymi w wyciekach.
  4. 05.4Limity prób i wykrywanie automatycznych nadużyć, bez masowego zgadywania haseł.
  5. 05.5Reset hasła: jednorazowy token, termin ważności i właściwy odbiorca.
  6. 05.6Ponowne potwierdzenie tożsamości przy zmianie hasła lub adresu e-mail.
06

Uprawnienia i izolacja danych

Tryb U / K

Potwierdzamy, że zalogowanie nie daje dostępu do cudzych danych ani funkcji spoza roli.

Kryterium: Każda operacja wymaga uprawnienia do konkretnego zasobu. Losowy identyfikator nie zastępuje kontroli dostępu.

Punkty kontrolne (6)
  1. 06.1Macierz ról: gość, klient, redaktor, obsługa i administrator.
  2. 06.2Izolacja zamówień, dokumentów i wiadomości między odrębnymi kontami testowymi.
  3. 06.3Funkcje administracyjne chronione po stronie serwera, niezależnie od ukrycia przycisku.
  4. 06.4Kontrola uprawnień przy odczycie, zapisie, usuwaniu, eksporcie i operacjach masowych.
  5. 06.5Konta techniczne, integracje i dostępy byłych wykonawców.
  6. 06.6Separacja organizacji w serwisach wielofirmowych, także w wyszukiwarce i plikach.
Sesje i bezpieczeństwo aplikacji
07

Sesje, tokeny i ochrona operacji

Tryb U / K

Śledzimy uprawnienia użytkownika od zalogowania do wygaśnięcia sesji.

Kryterium: Sesja trwa tyle, ile przewiduje polityka, a operacja wrażliwa wymaga właściwego kontekstu.

Punkty kontrolne (6)
  1. 07.1Nowy identyfikator sesji po zalogowaniu i zmianie uprawnień.
  2. 07.2Flagi Secure, HttpOnly i SameSite ciasteczek sesyjnych.
  3. 07.3Wygasanie sesji, wylogowanie i unieważnienie dostępu po zmianie hasła.
  4. 07.4Tokeny poza adresami URL, logami i narzędziami analitycznymi.
  5. 07.5JWT i podobne tokeny: podpis, ważność, odbiorca, wystawca i rotacja.
  6. 07.6Ochrona operacji zmieniających stan przed CSRF.
08

Formularze i podatności aplikacji

Tryb Z / U / K

Sprawdzamy, czy dane od użytkownika nie stają się instrukcjami dla aplikacji lub przeglądarki.

Kryterium: Każdy alert skanera weryfikujemy ręcznie przed wpisaniem do raportu.

Punkty kontrolne (6)
  1. 08.1Wejścia: formularze, parametry, nagłówki, wyszukiwarki, importy i dane z integracji.
  2. 08.2Odporność na SQL i NoSQL injection, najlepiej także w kodzie.
  3. 08.3XSS, w tym treści zapisane i generowane w przeglądarce.
  4. 08.4Wstrzyknięcie poleceń i szablonów, niebezpieczna deserializacja, przetwarzanie XML.
  5. 08.5SSRF przy pobieraniu adresów i plików z sieci.
  6. 08.6Walidacja po stronie serwera i komunikaty błędów bez szczegółów technicznych.
Pliki i ochrona przeglądarki
09

Przesyłanie i przetwarzanie plików

Tryb Z / U / K

Oceniamy cały cykl pliku: przyjęcie, przetworzenie, przechowanie i udostępnienie.

Kryterium: Plik jest dostępny tylko zgodnie z przeznaczeniem. Skan antywirusowy uzupełnia izolację i autoryzację.

Punkty kontrolne (6)
  1. 09.1Typy plików sprawdzane po zawartości, z limitem wielkości.
  2. 09.2Nazwy, ścieżki i archiwa bez możliwości zapisu w dowolnym miejscu serwera.
  3. 09.3Przesłana zawartość nie uruchamia się jako kod aplikacji.
  4. 09.4Uprawnienia do pobierania i usuwania oraz ważność tymczasowych odnośników.
  5. 09.5Parsery, generatory podglądu, konwertery i skanowanie plików.
  6. 09.6Eksporty, importy i retencja plików tymczasowych.
10

Nagłówki HTTP, przeglądarka i cache

Tryb Z / U / K

Sprawdzamy skuteczność ustawień przeglądarki i pośredników w realnych scenariuszach.

Kryterium: Brak pojedynczego nagłówka sam nie dowodzi podatności wysokiego ryzyka.

Punkty kontrolne (6)
  1. 10.1Content-Security-Policy dopasowana do rzeczywistych źródeł skryptów.
  2. 10.2Ochrona przed osadzaniem strony w nieuprawnionych ramkach.
  3. 10.3X-Content-Type-Options, Referrer-Policy i Permissions-Policy dobrane do serwisu.
  4. 10.4CORS dla danych publicznych i uwierzytelnionych.
  5. 10.5Cache konta klienta, koszyka i dokumentów, także na CDN i po wylogowaniu.
  6. 10.6Test procesów po zmianie polityk, tak aby zabezpieczenia nie blokowały sprzedaży.
API i proces zakupowy
11

API, webhooki i integracje

Tryb Z / U / K

Badamy interfejsy, które udostępniają te same dane i operacje inną ścieżką niż strona.

Kryterium: Stary lub alternatywny interfejs nie omija zabezpieczeń.

Punkty kontrolne (6)
  1. 11.1Inwentarz endpointów, wersji, webhooków i interfejsów partnerów.
  2. 11.2Uwierzytelnianie, zakresy tokenów oraz autoryzacja obiektów, pól i funkcji.
  3. 11.3Nadmiarowe odpowiedzi i zmiana pól, których klient nie powinien kontrolować.
  4. 11.4Limity żądań, paginacji i kosztownych operacji, w tym złożoność GraphQL.
  5. 11.5Autentyczność webhooków i ochrona przed ponownym wykonaniem wiadomości.
  6. 11.6Bezpieczne błędy, limity czasu i wyłączenie nieużywanych wersji interfejsów.
12

Logika biznesowa i płatności

Tryb U / K

Sprawdzamy, czy proces zakupowy działa poprawnie przy nietypowej kolejności i powtórzeniach.

Kryterium: Wydanie towaru wynika z potwierdzonego stanu po stronie serwera. Audyt nie jest formalną oceną zgodności z PCI DSS.

Punkty kontrolne (6)
  1. 12.1Cena, rabat, waluta i podatek liczone lub potwierdzane po stronie serwera.
  2. 12.2Dopuszczalne przejścia stanów koszyka, zamówienia, zwrotu i płatnej zawartości.
  3. 12.3Weryfikacja płatności po stronie serwera: kwota, waluta i numer zamówienia.
  4. 12.4Sam powrót z bramki płatniczej nie oznacza opłacenia zamówienia.
  5. 12.5Jednokrotny skutek operacji i obsługa ponownych webhooków.
  6. 12.6Role obsługi sklepu, faktury, zmiana danych odbiorcy i zwroty.
Dane i tajemnice techniczne
13

Baza danych i ochrona informacji

Tryb U / K / O

Ustalamy, gdzie trafiają dane klienta i kto może je odczytać.

Kryterium: Techniczny audyt nie zastępuje analizy prawnej RODO, którą obejmuje audyt zgodności prawnej.

Punkty kontrolne (6)
  1. 13.1Mapa przepływu danych: formularz, baza, pliki, poczta, CRM i integracje.
  2. 13.2Dostęp sieciowy do bazy i minimalne uprawnienia kont technicznych.
  3. 13.3Szyfrowanie transmisji i danych przechowywanych oraz dostęp do kluczy.
  4. 13.4Wycieki danych przez błędy, logi, analitykę, adresy URL i cache.
  5. 13.5Retencja, usuwanie i anonimizacja; dane produkcyjne w testach.
  6. 13.6Zabezpieczenie zrzutów bazy, paneli bazodanowych i kopii danych.
14

Hasła techniczne, klucze i sekrety

Tryb Z / K / O

Ograniczamy ryzyko przejęcia strony przez ujawnione dane dostępowe.

Kryterium: Usunięcie hasła z pliku nie kończy sprawy. Ujawniony sekret wymaga wymiany i oceny skutków.

Punkty kontrolne (6)
  1. 14.1Hasła, klucze API, tokeny i klucze prywatne w kodzie i historii repozytorium.
  2. 14.2Sekrety w publicznych zasobach, mapach kodu, plikach środowiska i logach.
  3. 14.3Sposób przechowywania i przekazywania sekretów.
  4. 14.4Oddzielne sekrety produkcji i testów oraz ważność tokenów integracyjnych.
  5. 14.5Rotacja i odwołanie sekretu bez niekontrolowanego przestoju.
  6. 14.6Reakcja na ujawnienie: wymiana danych dostępowych i sprawdzenie śladów użycia.
Integracje i kopie zapasowe
15

Skrypty zewnętrzne i integracje marketingowe

Tryb Z / K / O

Oceniamy wpływ narzędzi analitycznych, reklamowych, czatów i widżetów działających w przeglądarce klienta.

Kryterium: Każdy skrypt ma uzasadniony dostęp do danych. Baner cookies nie potwierdza bezpieczeństwa integracji.

Punkty kontrolne (6)
  1. 15.1Rejestr skryptów, pikseli, czatów i menedżerów tagów z właścicielem.
  2. 15.2Dane odczytywane przez integracje na formularzach, w koncie i w koszyku.
  3. 15.3Uprawnienia do publikacji tagów, MFA i historia zmian.
  4. 15.4Ograniczenie dodatków na stronach wrażliwych.
  5. 15.5CSP i kontrola integralności SRI tam, gdzie są technicznie odpowiednie.
  6. 15.6Usuwanie nieużywanych integracji i dostępów.
16

Kopie zapasowe i test przywracania

Tryb K / O

Potwierdzamy, że kompletny serwis da się odzyskać po utracie produkcji.

Kryterium: Odtwarzalność potwierdza protokół rzeczywistego przywrócenia z datą i wynikiem.

Punkty kontrolne (6)
  1. 16.1Zakres kopii: baza, pliki, konfiguracja i zależności potrzebne do uruchomienia.
  2. 16.2Częstotliwość i retencja wobec RPO, czyli dopuszczalnej utraty danych.
  3. 16.3Oddzielenie kopii od produkcji, ochrona przed usunięciem, wariant offline.
  4. 16.4Szyfrowanie kopii, dostęp do repozytorium i dostępność kluczy do odzyskania.
  5. 16.5Przywrócenie uzgodnionej kopii w odizolowanym środowisku.
  6. 16.6Czas odtworzenia wobec RTO i alarmy błędów kopii.
Wykrywanie i dostępność
17

Logi, monitoring i wykrywanie zdarzeń

Tryb K / O

Ustalamy, czy istotne zdarzenie zostanie zauważone i trafi do osoby odpowiedzialnej.

Kryterium: Każdy alarm ma odbiorcę i ustalony następny krok.

Punkty kontrolne (6)
  1. 17.1Logowanie uwierzytelniania, zmian uprawnień i działań administratorów.
  2. 17.2Znacznik czasu, identyfikacja osoby i kontekst operacji.
  3. 17.3Retencja, integralność i dostęp do logów, także po przejęciu serwera.
  4. 17.4Brak haseł, pełnych tokenów i zbędnych danych osobowych w logach.
  5. 17.5Nieszkodliwe zdarzenie testowe i potwierdzenie dostarczenia alarmu.
  6. 17.6Eskalacja i obsługa alarmów poza godzinami pracy.
18

Dostępność, boty i nadużycia

Tryb Z / K / O

Oceniamy ochronę przed nadmiernym zużyciem zasobów, bez symulowania ataku DDoS.

Kryterium: Limity mają uzasadnienie biznesowe. WAF jest warstwą ochrony, a przyczynę podatności trzeba naprawić.

Punkty kontrolne (6)
  1. 18.1Funkcje kosztowne: wyszukiwanie, eksporty, generowanie plików i płatne API.
  2. 18.2Limity liczby, wielkości i czasu żądań.
  3. 18.3Ochrona formularzy przed spamem z zachowaniem dostępności dla ludzi.
  4. 18.4WAF i CDN, wyjątki i bezpośrednia ekspozycja serwera źródłowego.
  5. 18.5Monitorowanie zasobów i progi kosztów usług zewnętrznych.
  6. 18.6Kontakt z hostingiem; test obciążeniowy wyłącznie jako osobny zakres.
Integralność, SEO i e-mail
19

Integralność serwisu, infekcje i sygnały SEO

Tryb Z / K / O

Szukamy oznak nieautoryzowanych zmian i ich skutków dla użytkowników.

Kryterium: Wniosek opisuje faktycznie sprawdzone elementy. Brak alarmu nie wyklucza włamania.

Punkty kontrolne (6)
  1. 19.1Porównanie plików z wersją bazową; nieznane pliki i zadania cykliczne.
  2. 19.2Nieznane konta administratorów, skrypty, linki i przekierowania zależne od odwiedzającego.
  3. 19.3Raport problemów bezpieczeństwa i lista właścicieli w Google Search Console.
  4. 19.4Spam, nieznane podstrony i zmiany mapy witryny.
  5. 19.5Prywatne treści chronione autoryzacją; robots.txt i noindex nie ograniczają dostępu.
  6. 19.6Przy oznakach włamania zabezpieczenie dowodów przed usuwaniem plików.
20

E-mail domeny i wiadomości ze strony

Tryb Z / K / O

Sprawdzamy kanał, którym płyną potwierdzenia, reset hasła i powiadomienia.

Kryterium: SPF, DKIM i DMARC uwierzytelniają wysyłkę. Domen łudząco podobnych do Twojej nie blokują.

Punkty kontrolne (6)
  1. 20.1Lista systemów wysyłających pocztę w domenie.
  2. 20.2SPF zgodny z rzeczywistymi ścieżkami wysyłki.
  3. 20.3Podpisy DKIM na prawdziwych wiadomościach testowych.
  4. 20.4DMARC i raporty; zaostrzenie polityki po analizie legalnej wysyłki.
  5. 20.5Ochrona danych SMTP i API oraz formularza przed nadużyciem.
  6. 20.6Treść wiadomości resetu hasła i potwierdzeń bez zbędnych danych.
Wdrożenia i gotowość operacyjna
21

Kod, wdrożenia i zarządzanie zmianą

Tryb K / O

Sprawdzamy, czy proces wprowadzania zmian nie pozwala obejść zabezpieczeń.

Kryterium: Wiadomo, kto zatwierdził i wdrożył zmianę.

Punkty kontrolne (6)
  1. 21.1Dostęp do repozytorium, MFA i zatwierdzanie zmian w kodzie i konfiguracji.
  2. 21.2Konta CI/CD i dostęp do produkcji podczas budowania.
  3. 21.3Pochodzenie artefaktów i kontrola zależności.
  4. 21.4Przegląd zmian w funkcjach krytycznych i testy bezpieczeństwa.
  5. 21.5Oddzielenie środowisk i kontrola ręcznych zmian na produkcji.
  6. 21.6Wdrożenie awaryjne, wycofanie zmiany i testy regresji.
22

Reakcja na incydent i odpowiedzialność

Tryb O / K

Potwierdzamy, że po wykryciu problemu wiadomo, kto decyduje i jak bezpiecznie wznowić działanie.

Kryterium: Proces ma właściciela i sprawdzoną ścieżkę działania.

Punkty kontrolne (6)
  1. 22.1Właściciel serwisu, osoba techniczna, kontakty do dostawców i zastępstwa.
  2. 22.2Przyjęcie zgłoszenia, ocena wpływu, eskalacja i decyzja o wyłączeniu strony.
  3. 22.3Zabezpieczenie dowodów i logów.
  4. 22.4Ćwiczenie scenariusza przejęcia konta lub utraty hostingu, bez ingerencji w produkcję.
  5. 22.5Plan odtworzenia, wymiana sekretów i bezpieczne wznowienie integracji.
  6. 22.6Zatwierdzanie komunikatów i ocena obowiązków prawnych po incydencie.
Podstawa metodyczna. Katalog odwołuje się do OWASP WSTG 4.2 i ASVS 5.0.0, a kategorie ryzyka porządkują OWASP Top 10:2025 i API Security Top 10:2023. Dotkliwość opisujemy w CVSS 4.0, a pilność uzupełniamy o katalog CISA KEV. Odwołanie do OWASP nie jest certyfikacją.
Zasady testowania

Tryby badania i bezpieczne wykonanie

Przed pracami uzgadniamy domeny, subdomeny, środowiska, role użytkowników, okno testowe, limity ruchu i kryteria zatrzymania. Tryb badania decyduje o tym, co da się rzetelnie ocenić.

Z

Zewnętrzny

Publicznie dostępne elementy i zachowanie aplikacji bez logowania.

Nie potwierdza wewnętrznej konfiguracji ani jakości kopii.

U

Z kontami użytkowników

Funkcje po zalogowaniu, sesje i uprawnienia na odrębnych kontach testowych.

Wymaga kont z odpowiednimi rolami.

K

Konfiguracja i kod

Ustawienia CMS, serwera, chmury, repozytorium, bazy i procesu wdrożeń.

W granicach udostępnionego dostępu.

O

Operacyjny

Dokumentacja, kopie, odtwarzanie, alarmowanie i ćwiczenia procedur.

Część wniosków wymaga próby, sama deklaracja nie wystarcza.

Zasady wykonania

  • Upoważnienie od podmiotu uprawnionego do zlecenia testów, z listą domen, środowisk i wyłączeń.
  • Konta testowe i dane syntetyczne zamiast danych klientów.
  • Test odtworzenia kopii w odizolowanym środowisku, bez wysyłki do klientów i realnych płatności.
  • Oznaki aktywnego włamania uruchamiają uzgodnioną ścieżkę incydentową przed jakimkolwiek usuwaniem plików.
  • Raport nie zawiera pełnych haseł, tokenów ani instrukcji wykorzystania problemów.

Poza domyślnym zakresem

  • Testy obciążeniowe i symulacja DDoS.
  • Socjotechnika i masowe zgadywanie haseł.
  • Destrukcyjne modyfikacje i obciążające fuzzowanie.
  • Infrastruktura operatora płatności, hostingu i innych klientów dostawcy.
  • Naprawy produkcyjne i pełne usuwanie skutków włamania.
Zgoda właściciela strony ma granice. Nie obejmuje automatycznie infrastruktury operatora płatności, hostingu ani innych klientów dostawcy. Każde działanie o podwyższonym wpływie wymaga osobnego uzgodnienia.
Kiedy warto

Sygnały, że potrzebujesz audytu bezpieczeństwa

Jeśli rozpoznajesz choć jeden z tych sygnałów, audyt prawdopodobnie szybko się zwróci.

Po włamaniu

Strona była zhakowana lub podejrzewasz incydent.

Stary CMS i wtyczki

Brak aktualizacji od dawna.

Sklep / dane klientów

Przetwarzasz płatności i dane osobowe.

Spadki bez przyczyny

Możliwe ukryte złośliwe treści.

Brak kopii zapasowych

Nie masz pewności co do backupów.

Wymogi zgodności

Potrzebujesz udokumentowanej oceny zabezpieczeń.

Jak działamy

Jak przebiega audyt

Uzgodnienie

Cel biznesowy, zasoby, konta, okno testowe, limity ruchu, osoba kontaktowa i zasady ochrony dowodów.

Rozpoznanie i plan

Inwentaryzacja funkcji i przepływów danych oraz dobór kontroli do technologii i ryzyka.

Weryfikacja

Skanowanie automatyczne, ręczne potwierdzanie ustaleń, testy uprawnień i przegląd dostępnej konfiguracji.

Raport i omówienie

Kontekst biznesowy, dowody, priorytety, rekomendacje i właściciele działań.

Naprawy i retest

Zmiany wdraża Twój zespół albo icomSEO. Retest obejmuje pierwotny problem i jego istotne warianty.

Efekt audytu

Co otrzymujesz

1

Streszczenie zarządcze

Obraz ryzyka dla sprzedaży, danych i dostępności strony oraz decyzje, które wymagają akceptacji.

2

Zakres i ograniczenia

Co zbadano, w jakim trybie i czego nie dało się ocenić z powodu braku dostępu.

3

Rejestr 132 kontroli

Status każdej kontroli: bez problemów, problem, częściowo, nie badano albo nie dotyczy.

4

Karty ustaleń

Lokalizacja, warunki odtworzenia, dowód z zamaskowanymi danymi, dotkliwość i priorytet.

5

Plan napraw

Kolejność działań, zabezpieczenia tymczasowe, właściciele zadań i terminy do uzgodnienia.

6

Kryteria retestu i omówienie

Sposób sprawdzenia każdej poprawki i spotkanie z zespołem technicznym.

Ocena ryzyka

Dotkliwość techniczna i priorytet działania

CVSS opisuje cechy i dotkliwość podatności. O kolejności napraw decydują dodatkowo ekspozycja w internecie, wymagane uprawnienia, dostęp do danych, wpływ na sprzedaż, istniejące zabezpieczenia, wykonalność naprawy i pewność ustalenia.

Dotkliwość techniczna CVSS 4.0Zakres wyniku
Krytyczna9,0–10,0
Wysoka7,0–8,9
Średnia4,0–6,9
Niska0,1–3,9
Brak dotkliwości w skali CVSS0,0

Przy wyniku CVSS podajemy pełny wektor i użyte grupy metryk. Obserwacje organizacyjne i zalecenia wzmacniające nie muszą mieć wyniku CVSS, a 0,0 nie oznacza „nie zbadano”.

Priorytety P0–P3

P0 · incydent

Oznaki aktywnego włamania, ujawnione działające sekrety lub krytyczna ekspozycja.

Reakcja od razu, bez czekania na raport końcowy.

P1 · naprawa priorytetowa

Potwierdzona możliwość istotnego naruszenia danych, kont albo procesu biznesowego.

Właściciel, termin i działania tymczasowe.

P2 · zaplanowana redukcja

Problem o ograniczonym wpływie albo wymagający dodatkowych warunków.

Pozycja w planie zmian z ponownym sprawdzeniem.

P3 · usprawnienie

Zalecenie wzmacniające zabezpieczenia albo porządkujące proces.

Opisane jako rekomendacja, bez nadawania rangi incydentu.

Trzy problemy, trzy priorytety. Brak wybranego nagłówka, dostęp do cudzej faktury i brak możliwości odtworzenia kopii dostają osobne oceny, nawet gdy narzędzie oznaczy je podobnym kolorem. Terminy napraw uzgadniamy z właścicielem systemu.
Wzór

Co zawiera karta ustalenia

Identyfikacja
Numer, nazwa, data, środowisko, wersja aplikacji i powiązana kontrola, na przykład 06.2.
Zasób i warunki
Miejsce występowania, rola konta, wymagane uprawnienia i warunki odtworzenia.
Stan i pewność
Potwierdzone, wymaga dodatkowej weryfikacji albo obserwacja; granice potwierdzonego wpływu.
Dowód
Minimalny materiał z zamaskowanymi danymi, bez pełnych haseł i tokenów.
Znaczenie
Skutek techniczny i biznesowy, bez dopisywania nieudowodnionych konsekwencji.
Klasyfikacja
Dotkliwość, priorytet P0–P3 i uzasadnienie; CVSS z wektorem, gdy jest właściwy.
Naprawa
Przyczyna, zalecenie docelowe, dopuszczalne zabezpieczenie tymczasowe.
Odbiór
Właściciel, termin, sposób sprawdzenia, wynik retestu i ryzyko resztkowe.
Przykład hipotetyczny

Dostęp do cudzego dokumentu

Kontrola
06.2, izolacja danych między kontami.
Fakt
W środowisku testowym konto klienta A otrzymuje dokument testowego klienta B mimo braku uprawnienia.
Zakres
Potwierdzenie dotyczy wskazanego typu dokumentu, nie całej bazy.
Zalecenie
Kontrola uprawnień do dokumentu po stronie serwera.
Odbiór
Uprawniony użytkownik zachowuje dostęp, a nieuprawniony go nie uzyskuje, także przez alternatywną ścieżkę pobrania.
Priorytet
Ustalany po ocenie ekspozycji i rodzaju danych.
Bezpieczeństwo i widoczność

Bezpieczeństwo, SEO i zaufanie klientów

Nieautoryzowane treści, złośliwe przekierowania lub szkodliwe pliki mogą prowadzić do ostrzeżeń w wyszukiwarce i przeglądarce. Ochrona witryny wpływa więc na to, jak klienci do niej trafiają.

Raport w Search Console

Google Search Console ma osobny raport problemów bezpieczeństwa. Po uzyskaniu dostępu przeglądamy go razem z listą uprawnionych właścicieli usługi.

Ukryte zmiany

Szukamy nieznanych podstron, spamu, zmian mapy witryny i przekierowań, które pokazują się tylko części odwiedzających, na przykład robotom wyszukiwarki.

Uczciwa obietnica

Audyt nie gwarantuje wzrostu pozycji w Google. HTTPS i dobre doświadczenie użytkownika mają znaczenie, ale o widoczności decyduje także jakość treści i całego serwisu.

Przygotowanie

Głębokość badania i przygotowanie

O wartości audytu decydują pokrycie, głębokość weryfikacji i jakość dowodów. Zakres każdego audytu potwierdzamy przed rozpoczęciem prac, niezależnie od wybranego pakietu.

1

Przegląd zewnętrzny

Publiczna ekspozycja, TLS, wybrane konfiguracje i zachowanie strony bez logowania.

Bez potwierdzenia kopii, pełnego stanu aktualizacji i uprawnień wewnętrznych.

2

Audyt aplikacji z kontami

Scenariusze po zalogowaniu, role, sesje, formularze, pliki i uzgodniona logika biznesowa.

Wymaga kont testowych i opisu funkcji serwisu.

3

Audyt techniczno-operacyjny

Dodatkowo konfiguracja CMS, hostingu, dostępów, kopii, logów i procedur.

Głębokość zależy od uprawnień i współpracy dostawców.

4

Zakres pogłębiony

Uzgodniony test penetracyjny, przegląd kodu, API, procesu zakupowego lub odtwarzania.

Każdy element pogłębienia wskazujemy w zamówieniu.

Co przygotować

  • Serwis i biznes: adresy w zakresie, technologia, funkcje, środowiska, rodzaje danych i dopuszczalny przestój.
  • Dostępy: konta testowe z potrzebnymi rolami, a przy rozszerzeniu czasowe dostępy do paneli, konfiguracji, repozytorium i logów, najlepiej tylko do odczytu.
  • Kopie i procedury: opis kopii, data ostatniej próby odtworzenia, lista integracji, dokumentacja aktualizacji i incydentów.
  • Warunki pracy: upoważnienie, kontakt operacyjny, okno testowe, ograniczenia hostingu, zasady płatności testowych i termin usunięcia dostępów.

Co wpływa na wycenę

  • Liczba odrębnych funkcji i ról użytkowników.
  • API, integracje, środowiska i technologie.
  • Dostępność kodu i dokumentacji.
  • Zakres testów ręcznych i głębokość dowodów.
  • Rodzaj raportu oraz liczba i zakres retestów.

Sam adres URL nie wystarcza do rzetelnej wyceny rozbudowanej aplikacji.

Po audycie

Od raportu do potwierdzonej poprawy

Zamówienie kończy się omówieniem zakresu, ograniczeń, najważniejszych ryzyk i kolejnych działań. Plan wdrożenia rekomendacji ma sześć kroków.

1

Ograniczenie pilnych zagrożeń

Problemy wymagające eskalacji trafiają od razu do uzgodnionych osób. Zabezpieczenie tymczasowe ma właściciela i datę przeglądu.

2

Przygotowanie zmian

Dla każdego zadania ustalamy zakres, odpowiedzialność, zależności, sposób wdrożenia i wycofania.

3

Test i wdrożenie

Poprawkę sprawdzamy w odpowiednim środowisku razem z funkcjami biznesowymi, na które wpływa.

4

Ponowna weryfikacja

Retest obejmuje pierwotny problem i istotne warianty. Zniknięcie alertu skanera nie wystarcza jako dowód naprawy.

5

Zamknięcie albo akceptacja

Ustalenie zamykamy na podstawie dowodu. Nienaprawiony problem wymaga jawnej decyzji właściciela ryzyka i daty przeglądu.

6

Utrwalenie

Aktualizujemy dokumentację, kontrole wdrożeniowe, alarmy i testy regresji, a po zakończeniu prac wycofujemy zbędne dostępy audytora.

Mierniki do dalszego nadzoru

MiernikJak go czytać
Otwarte ustalenia P0 i P1Liczba razem z wiekiem i właścicielem każdego ustalenia.
Skuteczność retestuOdsetek potwierdzonych napraw wśród zmian przekazanych do odbioru.
Pokrycie audytuWykonane kontrole wobec kontroli w zatwierdzonym zakresie; obszary zablokowane osobno.
Gotowość do odtworzeniaData i wynik ostatniej próby oraz odchylenie od przyjętych RPO i RTO.
Sprawność alarmowaniaCzy zdarzenie kontrolne dotarło do właściwej osoby i uruchomiło reakcję.
Kiedy powtórzyć badanie? Po uruchomieniu serwisu, istotnej zmianie logowania lub płatności, migracji hostingu, nowej integracji, incydencie i przejęciu utrzymania od innego wykonawcy. Częstotliwość przeglądów okresowych dobieramy do tempa zmian.
Kto odpowiada za audyt

Ekspert prowadzący

Audyty bezpieczeństwa i audyty zgodności prawnej stron prowadzi w icomSEO jedna osoba odpowiedzialna za zakres, metodykę i jakość raportu.

Arkadiusz Urbaś, Chief Technology Officer icomSEO

Arkadiusz Urbaś

Chief Technology Officer icomSEO

Arkadiusz Urbaś odpowiada w icomSEO za audyty bezpieczeństwa i audyty zgodności prawnej. Odpowiada za cały przebieg audytu: od ustalenia zakresu, trybu badania i dostępów po omówienie raportu i planu napraw.

Od ponad 14 lat tworzy i rozwija strony internetowe. Specjalizuje się w WordPressie, architekturze serwisów, hostingu i SEO technicznym. Jest współautorem poradnika „Domeny internetowe”, w którym opisuje między innymi DNS i zarządzanie domenami.

WordPress i WooCommerceHosting i domenyDNS i pocztaKopie zapasoweSEO techniczne
Zamów audyt z ArkadiuszemProfil autora i artykuły
Pakiety

Warianty audytu

Dobierz zakres do potrzeb. Koszt audytu odliczamy przy podjęciu współpracy.

Audyt Express

Podstawowe ryzyka
Cena od 990 zł netto
  • SSL, nagłówki, aktualizacje
  • Skan podatności
  • Lista zagrożeń
Zamawiam audyt
Najczęściej wybierany

Audyt Pełny

Analiza wszystkich obszarów
Cena od 1 900 zł netto
  • Pełny przegląd bezpieczeństwa
  • Backupy i dostępy
  • Plan zabezpieczeń
  • Konsultacja
Zamawiam audyt

Audyt + wdrożenie

Audyt i zabezpieczenie
Cena wycena indyw.
  • Pełny audyt
  • Wdrożenie zabezpieczeń
  • Monitoring i opieka
Zamawiam audyt

Ceny orientacyjne (netto). Zobacz pełny cennik →

Bez ryzyka

Co gwarantujemy

Niezależność

Oceniamy obiektywnie, także działania innych agencji.

Konkretne rekomendacje

Nie ogólniki. Wskazujemy dokładnie, co i jak poprawić.

Poufność

Dane i dostępy traktujemy poufnie; na życzenie podpiszemy NDA.

Audyt zwracany

Koszt audytu odliczamy, jeśli zdecydujesz się na współpracę.

Powiązane

Zobacz też

Hosting i domeny

Bezpieczny hosting i zaplecze.

Zobacz →

Strony i sklepy

Bezpieczne wdrożenia.

Zobacz →

Wszystkie audyty

Pełna oferta audytów.

Zobacz →
Narzędzia

Narzędzia, których używamy

Pracujemy na sprawdzonych narzędziach, a wyniki analizują i interpretują nasi specjaliści.

Wordfence / SucuriSSL Labssecurityheaders.comSkanery podatnościUpdraftPlusMonitoring uptime
Pełna oferta

Inne audyty, które wykonujemy

Sprawdź pozostałe audyty lub zamów audyt 360° obejmujący wiele obszarów naraz.

Audyt SEOAudyt marketinguAudyt Google AdsAudyt zgodności prawnejAudyt wydajności i konwersjiAudyt UX i dostępnościAudyt analitykiAudyt widoczności w AIAudyt e-commerceAudyt treściAudyt lokalny
Zakres sprawdzenia

Co sprawdzamy w audycie bezpieczeństwa strony

Audyt zaczynamy od inwentaryzacji: wersja CMS, wtyczki, motyw, wersja PHP i konta administratorów. Porównujemy je z bazami znanych podatności, bo przestarzała wtyczka to częsta droga włamania.

Konta i dostęp

Sprawdzamy, kto ma uprawnienia administratora, czy konta byłych współpracowników zostały usunięte i czy logowanie chroni weryfikacja dwuetapowa. Przeglądamy też dostęp do serwera, FTP i bazy danych.

Serwer i nagłówki

Weryfikujemy certyfikat SSL, przekierowanie na HTTPS, nagłówki bezpieczeństwa i ustawienia, które ujawniają informacje o serwerze, na przykład listowanie katalogów.

Kopie zapasowe

Sprawdzamy, czy kopie wykonują się automatycznie, gdzie są przechowywane i czy da się z nich odtworzyć stronę. Kopia trzymana tylko na tym samym serwerze nie pomoże po awarii albo włamaniu.

Eksperci

Eksperci od stron internetowych i WordPressa

Osoby z zespołu icomSEO, które specjalizują się w tym obszarze. Na profilach sprawdzisz ich doświadczenie i artykuły.

FAQ

Pytania o audyt bezpieczeństwa

Co sprawdza audyt bezpieczeństwa?

Katalog obejmuje 22 obszary i 132 punkty kontrolne. Zaczynamy od domeny, DNS, hostingu, certyfikatów oraz CMS i wtyczek. Dalej badamy logowanie, uprawnienia, sesje, formularze, pliki, nagłówki, API i płatności. Ostatnia część dotyczy bazy danych, sekretów, skryptów zewnętrznych, kopii zapasowych, monitoringu, nadużyć, integralności serwisu, poczty domeny, wdrożeń i reakcji na incydent. Zakres dobieramy do technologii i dostępów.

Kto odpowiada za audyt?

Za audyty bezpieczeństwa w icomSEO odpowiada Arkadiusz Urbaś, Chief Technology Officer, który od ponad 14 lat tworzy i rozwija strony internetowe, głównie na WordPressie. Odpowiada za cały przebieg audytu: od ustalenia zakresu po omówienie raportu i planu napraw.

Czy audyt zakłóci działanie strony?

Testy planujemy tak, żeby nie obciążać serwisu. Używamy kont testowych i danych syntetycznych, a testy obciążeniowe, DDoS, socjotechnika i masowe zgadywanie haseł nie należą do domyślnego zakresu. Działania o podwyższonym wpływie uzgadniamy osobno i wykonujemy w ustalonym oknie.

Co, jeśli wykryjecie włamanie?

Oznaki aktywnego włamania uruchamiają uzgodnioną ścieżkę incydentową: zabezpieczamy niezbędne dowody i od razu informujemy wskazane osoby, bez czekania na raport końcowy. Czyszczenie i zabezpieczenie strony możemy wykonać jako osobne zlecenie.

Czy po audycie strona będzie w pełni bezpieczna?

Wynik „nie wykryto problemu w badanym zakresie” dotyczy określonej daty, wersji serwisu, dostępów i scenariuszy. Audyt daje diagnozę i plan ograniczania ryzyka. Pełnej odporności na każdy atak nie obiecujemy, bo żaden audyt jej nie zapewnia.

Czym audyt różni się od testu penetracyjnego?

Audyt obejmuje szeroki zakres: konfigurację, aktualizacje, dostępy, kopie zapasowe, monitoring i procesy. Test penetracyjny to pogłębiona próba wykorzystania podatności. Zamawiasz go jako zakres pogłębiony, z osobnym upoważnieniem i zasadami testów.

Czy bezpieczeństwo wpływa na SEO?

Nieautoryzowane treści, złośliwe przekierowania i szkodliwe pliki mogą prowadzić do ostrzeżeń w wyszukiwarce i przeglądarce. Google Search Console ma osobny raport problemów bezpieczeństwa i sprawdzamy go, gdy otrzymamy dostęp. Audyt nie gwarantuje wzrostu pozycji w Google.

Czy obsługujecie WordPress?

Tak, w szczególności WordPress i WooCommerce: konta administratorów, uprawnienia plików, edycję plików z panelu, wtyczki i proces aktualizacji. Audytujemy też inne systemy.

Czy audyt wymaga dostępu do serwera?

Certyfikat, nagłówki i zachowanie strony bez logowania sprawdzamy z zewnątrz. Funkcje po zalogowaniu wymagają kont testowych z różnymi rolami. Konfigurację CMS, serwera, kopii i logów oceniamy tylko w zakresie udostępnionego dostępu, najlepiej z uprawnieniami do odczytu. Brak dostępu opisujemy w raporcie jako ograniczenie.

Czy sprawdzacie kopie zapasowe w praktyce?

Tak. W trybie operacyjnym przywracamy uzgodnioną kopię w odizolowanym środowisku, bez wysyłki do klientów i bez realnych płatności, i mierzymy czas odtworzenia. Bez takiej próby odtwarzalność oznaczamy jako niepotwierdzoną.

Jak często robić audyt bezpieczeństwa?

Po uruchomieniu serwisu, zmianie logowania lub płatności, migracji hostingu, nowej integracji, incydencie i przejęciu opieki od innego wykonawcy. Częstotliwość przeglądów okresowych dobieramy do tempa zmian i skutków ewentualnej awarii. Między audytami ważne są regularne aktualizacje oprogramowania.

Czy audyt potwierdza zgodność z PCI DSS albo RODO?

Audyt bezpieczeństwa nie jest formalną oceną zgodności z PCI DSS ani analizą prawną RODO. Prawne wymagania strony, formularzy i zgód sprawdza audyt zgodności prawnej. Oba audyty można połączyć.

Czy koszt audytu jest zwracany?

Tak, przy podjęciu współpracy, na przykład opieki nad stroną, odliczamy koszt audytu.

Opinie

Co mówią nasi klienci

4,7 / 5190 opinii w Google · Grupa icomSEO
DLDentaSpa Lublin2014
★★★★★Marketing internetowy · icomMedia

Bardzo dobry kontakt, profesjonalne doradztwo w zakresie reklamy internetowej. Polecam.

APAlicja Pawełczak2024
★★★★★Marketing internetowy · icomMedia

Zdecydowanie polecam tą Firmę. Szkolenie na temat widoczności firmy w Mapach Google, pierwsza klasa. Konkretnie, praktycznie i co już widzę z efektem.

ASAntoni Słowińskimarca 2026
★★★★★Marketing internetowy · icomSEO

Współpraca z diggio (icomSEO) to dla mnie przede wszystkim poczucie porządku i kontroli nad marketingiem. Zaczęliśmy od konkretnej rozmowy i audytu, potem dostałem jasny plan działań, bez bajek o „natychmiastowych cudach”, za to z realistycznymi celami. Na bie…

Czytaj całość

Współpraca z diggio (icomSEO) to dla mnie przede wszystkim poczucie porządku i kontroli nad marketingiem. Zaczęliśmy od konkretnej rozmowy i audytu, potem dostałem jasny plan działań, bez bajek o „natychmiastowych cudach”, za to z realistycznymi celami. Na bieżąco dostawałem informacje, co zostało zrobione i jaki to ma wpływ na wyniki. Po kilku tygodniach zaczęły pojawiać się konkretne efekty: większa widoczność, lepszy ruch na stronie i więcej zapytań od klientów. Doceniam też komunikację: szybko, rzeczowo i w normalnej, partnerskiej atmosferze. Zdecydowanie polecam, jeśli komuś zależy na mierzalnych wynikach, a nie pustych obietnicach.

Zobacz wszystkie opinie →

Wolisz porozmawiać?

Zostaw numer, oddzwonimy w godzinach pracy biura (pon.–pt. 8:00–16:00).

Administratorem danych jest icomSEO Sp. z o.o. z siedzibą w Lublinie. Dane przetwarzamy, aby odpowiedzieć na zgłoszenie. Więcej w Polityce prywatności.

Zadbaj o bezpieczeństwo, zanim incydent wymusi działanie

Podaj adres strony, jej główne funkcje i technologię. Na tej podstawie ustalimy zakres audytu i warunki rozpoczęcia prac.

Zapytaj o audyt →Wszystkie audyty

Współpraca, która napędza sukces

Zadzwoń