19. Brak uwierzytelnienia przy krytycznych funkcjach systemu

Niektóre z operacji mogą być wykonane bez żadnego uwierzytelnienia - luka ta wynika stąd, że przy projekcie nikt nie myślał o tym, że intruz może próbować uruchomić dany moduł bez uwierzytelnienia. Tymczasem, zestaw wielu takich błędów może prowadzić nawet do przejęcia serwera. Należy wprowadzić podział oprogramowania pod kątem tego, kto może je uruchomić. Podobne sprawdzenia należy także robić na serwerze.

18. Błąd w obliczeniach długości bufora

W niektórych językach programowania (należy do nich C) programista musi zadbać o zarządzanie pamięcią. Jeśli popełni błąd w określeniu rozmiaru bufora, ten może się okazać zbyt mały - a to może prowadzić do klasycznego błędu przepełnienia bufora, nawet przy poprawnej walidacji wprowadzanych danych. Należy zatem poprawnie obliczać długość buforów - przykładowo, w podprogramie konwersji do HTML zamiana znaku & w ciąg & wymaga pięciokrotnie dłuższego bufora wyjściowego.

17. Przepełnienie wartości liczby całkowitej - przekręcenie przez zero

Przy obliczeniach dziesiętnych 255+1=256, ale dla programu komputerowego czasami 255+1=0 a 0-1=65535, zależnie od wykorzystanego typu zmiennej. Stąd pojawiają się błędy w obliczeniach, załamania programów, nieskończone pętle czy nawet wykonanie obcego kodu. Należy zatem kontrolować przepełnienia, walidować wprowadzane wartości i stosować biblioteki takie jak IntegerLib lub SafeInt (C++).

16. Ujawnianie informacji w komunikatach błędów

Im więcej informacji podaje komunikat o błędzie, tym jest to korzystniejsze dla kogoś, kto chce przełamać zabezpieczenia. Wywołując błąd można poznać ścieżki do oprogramowania, jego dokładną wersję, adresację IP, a nawet szczegóły instalacji - a to są bardzo cenne informacje dla włamywacza. Informacje o serwerze czy błędzie programu powinny być możliwie lakoniczne, jedynym miejscem, gdzie mogą pojawić się szczegóły, są logi. Należy także zadbać o to, by komunikaty logowane do pliku również nie stanowiły dodatkowych wskazówek.

15. Zła obsługa nadzwyczajnych lub warunkowych zdarzeń/wartości

Doświadczenie uczy, że prawie w każdym oprogramowaniu mogą pojawić się zdarzenia lub wartości, które nie powinny być wprowadzane (na przykład długość równa zero przy działaniu, które wymaga niezerowej wartości). Jeśli nie przewidzi się obsługi takich zdarzeń, można doprowadzić do załamania programu, odmowy obsługi, utraty danych lub obejścia zabezpieczeń. Przy konstrukcji programu należy sprawdzać także wartości, które wynikają z obliczeń, zanim przekaże się je dalej.

14. Zła walidacja wskaźnika

Brak sprawdzania danych przy obliczaniu wskaźnika daje napastnikowi szansę na podanie wartości spoza dopuszczalnego zakresu (przykładowo, po alokacji macierzy na 100 obiektów lub struktur, hacker może podać wskaźnik -23 lub 978). Wykorzystanie takiego błędu może prowadzić do załamania programu, utraty danych, odmowy obsługi lub wykonania obcego kodu. Należy weryfikować wprowadzane wartości za pomocą Struts lub OWASP ESAPI, przy czym sprawdzenia należy wykonywać także na serwerze.

13. Brak kontroli nazwy pliku dla polecenia Include/Require w języku PHP

Przy programowaniu w PHP często łączy się kod z kilku plików za pomocą poleceń include lub require. Brak kontroli nad nazwami plików daje możliwość wykonania dowolnego kodu przez napastnika. Należy utworzyć mapowanie między nazwą plików a wartością ID (np. za pomocą ESAPI AccessReferenceMap) i sprawdzać poprawność danych (na przykład, usuwając więcej niż jedną kropkę w ścieżce pliku). Ponadto, należy tworzyć i uruchamiać programy w najnowszej wersji PHP, co najmniej PHP 6.