Większość ataków na aplikacje webowe wykorzystuje te same, znane od lat podatności. Mimo to wciąż je znajdujemy – nawet w projektach, które przeszły “code review”. Oto pięć błędów, które widzimy najczęściej.
1. Brak walidacji danych po stronie serwera
Walidacja w JavaScript to za mało. Atakujący może ominąć przeglądarkę i wysłać dowolne dane bezpośrednio do API. Każde pole formularza, każdy parametr URL, każdy nagłówek HTTP musi być walidowany po stronie serwera.
Jak się bronić:
- • Używaj bibliotek do walidacji (Zod, Yup, Joi)
- • Definiuj schematy dla wszystkich endpointów
- • Traktuj dane od użytkownika jako zawsze niezaufane
2. SQL Injection przez ORM
Używanie ORM-a nie chroni automatycznie przed SQL Injection. Surowe zapytania, interpolacja stringów w WHERE, dynamiczne nazwy kolumn – wszystko to otwiera drzwi atakującym.
Jak się bronić:
- • Używaj parametryzowanych zapytań – zawsze
- • Unikaj raw queries, a jeśli musisz – używaj placeholderów
- • Waliduj nazwy kolumn przez whitelist
3. Broken Access Control (IDOR)
Zmiana ID w URL-u daje dostęp do cudzych danych? To Insecure Direct Object Reference (IDOR) – jeden z najczęstszych i najgroźniejszych błędów. Sprawdzenie, czy użytkownik jest zalogowany, to za mało. Trzeba sprawdzić, czy ma dostęp do konkretnego zasobu.
Jak się bronić:
- • Weryfikuj uprawnienia przy każdym żądaniu
- • Używaj UUID zamiast sekwencyjnych ID
- • Implementuj middleware do kontroli dostępu
4. Sekrety w kodzie i repozytoriach
Klucze API, hasła do baz danych, tokeny – regularnie znajdujemy je zahardkodowane w kodzie lub w historii Git. Nawet usunięcie pliku nie usuwa go z historii repozytorium.
Jak się bronić:
- • Używaj zmiennych środowiskowych
- • Dodaj .env do .gitignore od pierwszego commita
- • Skanuj repozytorium narzędziami typu git-secrets lub truffleHog
- • Rotuj klucze, jeśli wyciekły
5. Brak rate limitingu
Endpoint do logowania bez limitu prób? Formularz kontaktowy bez captchy? API bez throttlingu? To zaproszenie do brute-force'owania haseł, spamu i ataków DoS.
Jak się bronić:
- • Implementuj rate limiting na poziomie aplikacji i/lub reverse proxy
- • Dodaj opóźnienia po nieudanych próbach logowania
- • Rozważ captchę dla formularzy publicznych
- • Monitoruj anomalie w ruchu
Podsumowanie
Te pięć błędów to nie skomplikowane ataki zero-day – to podstawy, które powinny być weryfikowane w każdym projekcie. Wiele z nich można wykryć automatycznie narzędziami do statycznej analizy kodu, ale nic nie zastąpi ręcznego przeglądu z myślą o bezpieczeństwie.
Chcesz sprawdzić swoją aplikację? Robimy przeglądy kodu pod kątem bezpieczeństwa. Napisz do nas, porozmawiamy o Twoim projekcie.