10 najczęstszych podatności w kodzie, których warto szukać w 2026

Większość włamań wciąż zaczyna się od garstki dobrze znanych klas błędów. Frameworki stały się bezpieczniejsze, ale błędy się przeniosły: do handlerów API, zadań w tle, kodu infrastruktury i warstwy łączącej usługi. Oto lista, którą sprawdzamy w pierwszej kolejności podczas każdego audytu, wraz z identyfikatorem CWE, który zobaczysz w raporcie CodeAuditAgent.

1. Błędna kontrola dostępu (CWE-639, CWE-862)

Zdecydowanie najczęstsze poważne znalezisko: endpoint wczytuje rekord po ID, nie sprawdzając, czy należy on do wywołującego. Uwierzytelnianie mówi, kim ktoś jest; autoryzacja musi odbywać się przy każdym pojedynczym zapytaniu.

// Scope every lookup to the owner
const invoice = await db.invoice.findFirst({
  where: { id, userId: session.user.id },
});

2. Wstrzykiwanie kodu (CWE-89, CWE-78)

SQL sklejany ze stringów, polecenia powłoki i wyrażenia w szablonach wciąż są wszędzie, zwykle w tym jednym zapytaniu, które ktoś napisał ręcznie dla wydajności. Parametryzuj zapytania albo przekazuj argumenty jako tablicę; nigdy nie konkatenuj danych wejściowych.

3. Zahardkodowane sekrety (CWE-798)

Klucze API zacommitowane do repozytorium, testowe tokeny, które okazały się produkcyjne, klucze prywatne w plikach konfiguracyjnych. Przenieś je do zmiennych środowiskowych lub menedżera sekretów i zrotuj wszystko, co kiedykolwiek trafiło do commita: usunięcie linijki nie usuwa historii.

4. Server-side request forgery (CWE-918)

Każdą funkcję, która pobiera URL podany przez użytkownika, np. webhooki, podglądy linków czy importy, można skierować na Twoją sieć wewnętrzną albo endpoint metadanych chmury. Stosuj allowlistę hostów, rozwiązuj i weryfikuj adres IP oraz blokuj zakresy prywatne.

5. Cross-site scripting (CWE-79)

Nowoczesne frameworki domyślnie escapują dane, więc XSS ukrywa się teraz w furtkach obejściowych: propsach z surowym HTML, rendererach markdownu i URL-ach wstawianych do atrybutów href. Sanityzuj HTML sprawdzoną biblioteką i odrzucaj URL-e javascript:.

6. Niebezpieczna deserializacja i eval (CWE-502, CWE-95)

Pickle, YAML load, strumienie obiektów Javy i dynamiczny eval zamieniają dane w kod. Zamiast tego używaj bezpiecznych loaderów i JSON-a walidowanego schematem.

7. Słaba kryptografia (CWE-327, CWE-330)

MD5 lub SHA-1 do haseł, statyczne IV, Math.random() do tokenów. Używaj funkcji haszującej zaprojektowanej do haseł (Argon2id, bcrypt, scrypt) i kryptograficznie bezpiecznego źródła losowości.

8. Otwarte przekierowania (CWE-601)

Parametr next lub returnTo, który akceptuje dowolny URL, zamienia Twoją domenę w zaufaną wyrzutnię dla phishingu. Akceptuj wyłącznie ścieżki względne w obrębie tego samego originu.

9. Brak rate limitingu (CWE-307, CWE-770)

Logowanie, reset hasła, OTP i każdy endpoint, który generuje koszty (e-mail, SMS, wywołania AI), potrzebują limitów na użytkownika i na IP. Bez nich ataki brute force i ataki nabijające rachunki są banalnie proste.

10. Błędna konfiguracja bezpieczeństwa (CWE-16)

CORS z wildcardem i credentials, tryb debugowania na produkcji, rozbudowane stack trace'y, zbyt liberalne polityki bucketów. Podczas code review rzadko wyglądają na błędy, bo siedzą w konfiguracji, i właśnie dlatego trzeba je przeglądać jak kod.

Jak korzystać z tej listy

• Sprawdzaj klasy od 1 do 3 w każdym pull requeście; mają największy wpływ i najłatwiej je przeoczyć.
• Traktuj konfigurację infrastruktury i CI jak kod podlegający review.
• Zapisuj CWE przy każdym znalezisku, aby śledzić poprawki i mierzyć trendy.