Bezpieczeństwo aplikacji webowej: 10 pytań, które warto zadać wykonawcy

Zamawiasz aplikację i nie jesteś programistą. Jak sprawdzić, czy wykonawca potraktuje bezpieczeństwo aplikacji webowej poważnie i czy RODO w aplikacji nie skończy się dla Ciebie problemem? Dobra wiadomość: nie musisz znać się na kodzie. Wystarczy, że przed podpisaniem umowy zadasz 10 konkretnych pytań i uważnie posłuchasz odpowiedzi. Przy każdym pytaniu znajdziesz przykład dobrej i złej odpowiedzi wykonawcy.

Po co pytać o bezpieczeństwo przed podpisaniem umowy?

Bo po wdrożeniu jest za późno i za drogo. Poprawianie fundamentów w działającej aplikacji kosztuje wielokrotnie więcej niż zrobienie ich dobrze od początku. Te same pytania zadasz software house'owi i freelancerowi - jeśli dopiero wybierasz, pomoże Ci wpis software house czy freelancer. Podstawy bezpieczeństwa nie są też dopłatą do pakietu premium - należą do standardu, czy projekt kosztuje 10 000 zł, czy 100 000 zł. Nie robisz wykonawcy egzaminu z technologii - obserwujesz, jak reaguje. Konkret i procedury to dobry znak. Ogólniki i zniecierpliwienie to zły.

Bezpieczeństwo aplikacji webowej: dane, kopie i dostępy (pytania 1-4)

1. Jak robicie kopie zapasowe i kiedy ostatnio testowaliście odtwarzanie?

Dobra odpowiedź: automatyczny backup co noc, przechowywany poza serwerem aplikacji, odtwarzanie testowane regularnie. Zła: „hosting coś tam robi". Kopia, której nikt nigdy nie odtworzył, to nadzieja, a nie zabezpieczenie.

2. Czy całość działa po HTTPS i jak szyfrujecie dane?

Dobra: HTTPS wszędzie od pierwszego dnia, hasła zapisywane wyłącznie jako skróty, dane wrażliwe szyfrowane w bazie. Zła: „certyfikat dołożymy przed startem". To sygnał, że bezpieczeństwo jest dodatkiem, a nie fundamentem.

3. Kto po Waszej stronie widzi nasze dane i jak dzielicie uprawnienia?

Dobra: imienna lista osób, każda loguje się na własne konto, uprawnienia według ról. Zła: jedno wspólne hasło administratora, „bo tak wygodniej". Wtedy nigdy nie ustalisz, kto co zrobił.

4. Jak aktualizujecie biblioteki, na których stoi aplikacja?

Aplikacja webowa stoi na dziesiątkach gotowych komponentów, a luki w nich wykrywa się regularnie. Dobra: aktualizacje są częścią utrzymania po wdrożeniu, z jasnym planem. Zła: „po oddaniu projektu to już Państwa temat".

RODO w aplikacji: dane osobowe i koniec współpracy (pytania 5-6)

5. Jak zadbacie o RODO i czy podpiszecie umowę powierzenia danych?

Jeśli aplikacja przetwarza dane klientów albo pracowników, RODO dotyczy jej wprost. Dobra: umowa powierzenia to standard, dane testowe są anonimizowane, serwery stoją w UE. Zła: „RODO to temat dla prawnika, nie dla nas".

6. Co dzieje się z Waszymi dostępami po zakończeniu współpracy?

Dobra: opisana procedura: przekazanie dostępów, wyłączenie kont, zmiana haseł, potwierdzenie na piśmie. Zła: zdziwienie, że pytasz. Byli podwykonawcy z aktywnym dostępem to jedna z najczęstszych dziur w małych firmach.

Kod, logi, testy i plan na awarię (pytania 7-10)

7. Czyj jest kod i na jakich zasadach go otrzymuję?

To zależy od umowy i oba modele bywają uczciwe: przeniesienie praw autorskich albo licencja na korzystanie z kodu - różnią się zakresem, ceną i tym, co możesz później samodzielnie zmieniać. Dobra: wykonawca wprost mówi, który model proponuje i co dokładnie obejmuje, a warunki oraz moment przekazania kodu lub dostępu do repozytorium są zapisane w umowie. Zła: „kod jest u nas, proszę się nie martwić" - bez żadnego zapisu. Nie chodzi o dostęp od pierwszego dnia, tylko o to, żebyś wiedział, co, kiedy i na jakich zasadach dostaniesz - i nie został zakładnikiem jednego dostawcy.

8. Jakie zdarzenia loguje aplikacja?

Dobra: zapisywane są logowania, zmiany danych i błędy, z określonym czasem przechowywania logów. Zła: brak logów. Bez nich po incydencie nie ustalisz, co się stało, ani czy trzeba zgłosić naruszenie danych.

9. Jak testujecie aplikację przed wdrożeniem?

Dobra: osobne środowisko testowe, testy automatyczne kluczowych funkcji i przegląd kodu przez drugiego inżyniera - także kodu pisanego z pomocą AI. Zła: „klikamy po aplikacji i jak działa, to wdrażamy".

10. Co się stanie, gdy aplikacja padnie w piątek o 22:00?

Dobra: monitoring, który sam podnosi alarm, czas reakcji zapisany w umowie i jasna ścieżka kontaktu. Zła: „jeszcze nigdy nic nam nie padło". Kiedyś padnie - pytanie, czy ktoś będzie wiedział, co robić.

Podsumowanie: jak czytać odpowiedzi wykonawcy

Nie musisz rozumieć każdego szczegółu technicznego. Wystarczy, że w odpowiedziach wyłapiesz trzy sygnały:

• Konkret zamiast ogólników - „backup co noc, poza serwerem" zamiast „mamy to ogarnięte".
• Procedury zamiast improwizacji - na awarię i koniec współpracy istnieje opisany proces, nie obietnica.
• Gotowość do zapisania tego w umowie - dobra odpowiedź ustna, której nikt nie chce wpisać do umowy, jest warta niewiele.

Chcesz, żeby ktoś przejrzał ofertę wykonawcy albo istniejącą aplikację okiem inżyniera? Umów konsultację techniczną. A jeśli dopiero planujesz projekt, wypełnij naszą wycenę: kalkulator pokaże wstępny przedział cen od ręki, pierwszą odpowiedź od człowieka dostaniesz w ciągu 24h, a wiążącą wycenę przygotujemy po krótkiej rozmowie - razem z odpowiedziami na wszystkie 10 pytań.