Bezpieczeństwo aplikacji webowych w 2026

Bezpieczeństwo aplikacji webowych w 2026 to nie firewall i SSL. Większość poważnych incydentów w polskich firmach ostatniego roku to nie zaawansowane ataki — to nudne podatności: IDOR, brak rate limiting, ujawnione tokeny w repozytorium GitHub. Dobra wiadomość: 80% ryzyka eliminuje się standardowymi praktykami, które kosztują kilka–kilkanaście tysięcy złotych. Pozostałe 20% wymaga audytu i czasem inwestycji 50–100 tys. Oto, gdzie postawić te pieniądze. OWASP Top 10 w 2026 — co się zmieniło OWASP Top 10 to lista najczęstszych podatności w aplikacjach webowych, aktualizowana co 3–4 lata. Wersja 2025 (publikowana początek 2026) różni się od wersji 2021 w kilku miejscach. Stałe pozycje, które wciąż dominują A01:2025 — Broken Access Control. Najczęstsza kategoria od lat. Typowy przykład: użytkownik A może podmienić ID w URL-u i zobaczyć dane użytkownika B. To IDOR (Insecure Direct Object Reference). Statystycznie znajduje się w 70%+ aplikacji w pierwszym audycie. A02:2025 — Cryptographic Failures. Hasła w plain text w bazie, JWT bez podpisu, klucze API w repozytorium. Wciąż widzimy to w 2026. A03:2025 — Injection. SQL injection, NoSQL injection, command injection. Mniej powszechne niż 10 lat temu dzięki ORM-om, ale wciąż w 30% audytów. Nowości i awanse A04:2025 — Insecure Design. Architektura niezgodna z bezpieczeństwem — np. flow „zapomniane hasło" przesyłające nowe hasło mailem zamiast linku resetującego. Awansowała, bo coraz częściej znajdowana w audytach. A06:2025 — Vulnerable Components. Korzystanie z bibliotek ze znanymi CVE. Aplikacja Next.js z 200 zależnościami, gdzie 15 ma krytyczne CVE — to standard, którego nikt nie monitoruje. A10:2025 — Server-Side Request Forgery (SSRF). Coraz częstsze przy aplikacjach integrujących wiele API. Atakujący zmusza Twój serwer do wykonania requestu do wewnętrznej infrastruktury. Top 5 podatności, które naprawdę spotykamy w PL Z audytów wykonanych dla klientów w ostatnich 18 miesiącach, oto co znajdujemy w 80% projektów : 1. Brak rate limiting na endpointach krytycznych Logowanie, reset hasła, rejestracja, formularz kontaktowy — wszystkie bez limitu prób. Brute-force loginu możliwy bezpośrednio z internetu. Naprawa — 1–2 dni pracy, gotowe biblioteki (express-rate-limit, Upstash Rate Limit) wbudują się w godzinę. 2. IDOR — autoryzacja na poziomie endpointu, nie zasobu API ma sprawdzenie „czy zalogowany?" ale nie sprawdza „czy ten zalogowany ma dostęp do tego konkretnego zasobu?". Klasyczny przykład: GET /api/orders/12345 zwraca zamówienie z ID 12345 bez sprawdzenia, czy należy do zalogowanego użytkownika. 3. Wyciek danych w odpowiedziach API Endpoint /api/users/me zwraca pełny obiekt użytkownika włącznie z passwordHash , internalNotes , apiKeys . Frontend nie wyświetla tych pól, ale są w response — widoczne w DevTools. 4. Brak security headers Strona bez Content-Security-Policy , X-Frame-Options , Strict-Transport-Security . Skutek — podatność na XSS, clickjacking, downgrade attacks. Naprawa — kilka linii konfiguracji Next.js/Nginx. 5. Stare biblioteki z CVE npm audit pokazuje 30 podatności, w tym 5 high/critical. Nikt tego nie sprawdza po wdrożeniu na produkcję. Aktualizacja bibliotek — pół dnia raz na kwartał. Security headers — minimum, które trzeba mieć Pięć nagłówków, których brak jest dziś trudny do uzasadnienia. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}' X-Frame-Options: DENY X-Content-Type-Options: nosniff Referrer-Policy: strict-origin-when-cross-origin Permissions-Policy: camera=(), microphone=(), geolocation=() Sprawdź swoją aplikację na securityheaders.com — narzędzie daje notę A+ do F. Większość polskich aplikacji startuje od D lub F. Doprowadzenie do B–A to dzień pracy. RODO i AI Act — co realnie musisz zrobić RODO — minimum w aplikacji Większość firm myli RODO z polityką prywatności na stronie. To dwie różne rzeczy. Praktyczne wymagania techniczne: Logowanie dostępu do danych osobowych — kto, kiedy, jakie dane pobrał Mechanizm usuwania danych — automatyczny, nie „odezwij się na mail i my coś z tym zrobimy" Eksport danych — RODO art. 20 wymaga możliwości pobrania swoich danych w formacie JSON/CSV Pseudonimizacja w logach — emaile, IP, numery PESEL nie mogą leżeć w logach aplikacji w jawnej formie Szyfrowanie danych wrażliwych w spoczynku — dla danych zdrowotnych, finansowych, biometrycznych AI Act — od sierpnia 2026 AI Act wszedł w pełnię obowiązków w sierpniu 2026. Co to oznacza dla aplikacji webowych: Chatbot obsługi klienta — musi jasno informować, że rozmawiasz z AI (jedna informacja w pierwszej wiadomości starcza) AI podejmujące decyzje o ludziach (rekrutacja, scoring kredytowy, biometria) — kategoria „high-risk", wymaga oceny ryzyka, logowania decyzji, możliwości odwołania do człowieka Generowanie treści — AI-generated content musi być oznaczony, gdy może wprowadzać w błąd (deepfake, fałszywe recenzje) Dla większości firm B2B/e-commerce wymagania ograniczają się do informacji o użyciu AI. Dla branż regulowanych — pełna dokumentacja i procedury. Audyt penetracyjny — co, kiedy, ile Audyt bezpieczeństwa to nie luksus, tylko obowiązek wynikający z DORA, NIS2 i sektorowych regulacji. Ale nawet poza obowiązkiem — kosztuje 10x mniej niż wyciek danych. Poziomy audytu Audyt automatyczny (3 000 – 8 000 zł). Skanery jak OWASP ZAP, Burp Suite, Nessus uruchomione na aplikacji. Wykrywają znane CVE, brak headers, oczywiste konfiguracje. Wystarczy dla startupów MVP i wewnętrznych narzędzi. Audyt manualny z testem penetracyjnym (15 000 – 50 000 zł). Pentester ręcznie próbuje obejść autoryzację, znaleźć IDOR, wykorzystać logikę biznesową. Standard dla aplikacji produkcyjnych obsługujących płatności lub dane osobowe. Pełen audyt OWASP ASVS Level 2 (30 000 – 100 000 zł). Kompleksowy audyt z dokumentacją zgodności. Wymagany w sektorze publicznym, bankowości, ubezpieczeniach. Audyt warto powtarzać co 12–18 miesięcy oraz po każdej dużej zmianie funkcjonalnej — nowa integracja, zmiana modelu autoryzacji, dodanie płatności. Koszty wdrożenia bezpieczeństwa per skala Liczby z projektów ostatnich 18 miesięcy. Skala aplikacji Audyt + naprawa Procesy bezpieczeństwa rocznie MVP / wewnętrzne narzędzie 10 000 – 20 000 zł 5 000 – 10 000 zł Aplikacja B2B (do 1 000 użytkowników) 25 000 – 50 000 zł 15 000 – 30 000 zł SaaS produkcyjny 50 000 – 100 000 zł 30 000 – 80 000 zł Sektor regulowany (medycyna, finanse) 80 000 – 200 000 zł 60 000 – 200 000 zł Do procesów rocznych liczymy: pentest, monitoring podatności bibliotek, aktualizacje, szkolenia zespołu, response na incydenty. Najczęstsze błędy 1. Bezpieczeństwo „na koniec projektu" Dodawanie bezpieczeństwa po wdrożeniu kosztuje 5–10x więcej niż zaplanowanie go od dnia pierwszego. Migracja architektury autoryzacji w produkcyjnej aplikacji to projekt na 3–6 miesięcy. 2. Bezpieczeństwo bez monitoringu Logi błędów aplikacji bez alertingu na podejrzane wzorce (1000 prób logowania z jednego IP, masowe 401, dziwne user agents) — nic nie wykryjesz po fakcie. 3. Skupienie na perimeter, ignorowanie wewnętrznych zagrożeń Firewall i WAF nie chronią przed insider threat ani złym kodem we własnej aplikacji. 60% incydentów ma źródło wewnętrzne. 4. Hasła zamiast 2FA dla admin paneli Jeśli admin panel logowany jest hasłem bez 2FA, jeden phishing wystarczy do przejęcia całej aplikacji. 2FA (TOTP, WebAuthn) to kilka godzin pracy. Następne kroki Najtaniej zacząć od 3 rzeczy: skan npm audit / pip-audit (15 minut), sprawdzenie security headers (15 minut), test IDOR na endpointach API (1 dzień). To pokryje 60% typowych podatności bez audytu zewnętrznego. W Neticat budujemy aplikacje webowe z bezpieczeństwem zaprojektowanym od dnia pierwszego — autoryzacja zasobowa, security headers, monitoring, zgodność z RODO i AI Act. Dla aplikacji SaaS prowadzimy też audyty bezpieczeństwa i naprawy. Porozmawiajmy , jeśli chcesz wiedzieć, gdzie Twoja aplikacja ma realne luki.

Najczęstsze pytania

Ile kosztuje audyt bezpieczeństwa aplikacji?

Podstawowy audyt automatyczny (skanery) — 3 000 do 8 000 zł. Audyt manualny z testem penetracyjnym — 15 000 do 50 000 zł. Pełen audyt bezpieczeństwa zgodny z OWASP ASVS Level 2 — 30 000 do 100 000 zł.

Jakie są najczęstsze podatności w polskich aplikacjach?

Brak rate limiting na endpointach logowania, nieprawidłowa autoryzacja (IDOR), wyciek danych w odpowiedziach API, brak security headers, stare biblioteki z znanymi CVE. To 80% findingów w audytach.

Czy AI Act wymaga zmian w mojej aplikacji?

Jeśli używasz AI do podejmowania decyzji o ludziach (rekrutacja, scoring, biometria) — tak, od sierpnia 2026 obowiązkowe są oceny ryzyka, logowanie decyzji i transparentność. Dla chatbotów obsługi klienta wystarczy informacja, że rozmawiasz z AI.