12. Dostęp do bufora z niewłaściwą długością

Próba dostępu do bufora w pamięci przy nieprawidłowej jego długości może powodować przekroczenie granicy bufora i powstanie poważnych błędów, do uruchomienia obcego kodu włącznie. W odróżnieniu od klasycznego przepełnienia bufora (miejsce trzecie na liście), tutaj istotą nie jest nadpisanie przy kopiowaniu do zbyt małego bufora, ale dostęp poza jego granicą. Należy używać narzędzi, które automatycznie przeciwdziałają przekroczeniu granicy bufora lub eliminują jego przepełnienie - na przykład SafeStr lub Strsafe.h - lub korzystać ze środowisk, w których ryzyko przepełnienia jest niewielkie (Java, Perl, Ada, C#). Bezpieczeństwo można poprawić wykorzystując technologie takie jak randomizacja ASLR i zabezpieczenie przed wykonaniem danych (NX).

11. Osadzenie uwierzytelnienia w oprogramowaniu

Umieszczenie na stałe hasła lub klucza w kodzie programu jest złym pomysłem, gdyż reverse engineering umożliwi odtworzenie go. W przypadku popularnych programów jest to tylko kwestią czasu, ponadto narażone na atak będą wszystkie kopie. Hasła i klucze należy przechowywać w zabezpieczonej strukturze (na przykład, w zaszyfrowanym pliku lub chronionych zasobach systemowych), która może być chroniona przez napastnikami. Do kontroli haseł należy używać dobrych skrótów kryptograficznych.

10. Brak szyfrowania wrażliwych danych

Błąd ten jest oczywisty, dotyczy w szczególności przesyłania danych siecią, a także składowania w ogólnodostępnych plikach lub bazach (także w katalogach tymczasowych). Skutkiem może być utrata danych lub nawet przejęcie serwera. Należy wdrożyć szyfrowanie z użyciem uznanych standardów.

9. Brak kontroli parametrów przekazywanych do systemu operacyjnego

Oprogramowanie dość często komunikuje się z wnętrzem systemu operacyjnego. Przy wywoływaniu innego programu lub wykonywaniu odwołania systemowego nie można pozwolić na przekazanie podawanych z zewnątrz parametrów bez ich sprawdzania. Błąd taki może prowadzić do wykonania obcego kodu, z przejęciem systemu operacyjnego włącznie. Zamiast uruchamiania programów lepiej korzystać z odwołań systemowych, a wszystkie parametry muszą być sprawdzane. Dobrym pomysłem jest oddzielenie parametrów od informacji z zewnątrz i kodu aplikacji, a także unikanie przekazywania ich w całości.

8. Brak ograniczeń typów plików, które można umieścić na serwerze

Zezwolenie na upload dowolnego pliku na serwer może skutkować wprowadzeniem tam specjalnie przygotowanego pliku .php albo .asp (lub innego, którego typ wskazuje na plik wykonywalny), który będzie zinterpretowany przez serwer jako program i wykonany. Należy zmieniać nazwę pliku, by wewnątrz serwera operować własnymi nazwami, ignorując podawane przez użytkownika, dodatkowo wprowadzając listę dopuszczalnych rozszerzeń nazw. Dobrym pomysłem jest składowanie plików poza drzewem katalogów aplikacji i opracowanie mechanizmów ich dynamicznego dostarczania.

7. Brak ograniczeń ścieżki do konkretnego katalogu (path traversal)

Przy aplikacjach, które polegają na składowaniu danych w plikach, napastnik może wprowadzić nazwę, która zawiera opis względnej ścieżki z użyciem wyrażenia "../" lub podobnego. Brak ograniczeń umożliwia wyjście poza dozwolony katalog i pozyskanie dowolnego pliku, do którego ma dostęp użytkownik, na którego uprawnieniach pracuje serwer. Skutkiem może być utrata danych, wykonanie dowolnego kodu lub odmowa obsługi. Należy kontrolować podawane nazwy plików, usuwając z nich znaki takie jak ".." lub ";" i wprowadzać restrykcje odnośnie do danych pobieranych z zewnątrz.

6. Poleganie na niezaufanych informacjach przy uwierzytelnieniu

Nie można polegać na prostych mechanizmach, takich jak plik lub nieszyfrowane cookie po stronie klienta, gdyż skopiowanie stanu umożliwi przejęcie sesji. Należy wdrożyć mechanizm po stronie serwera, który zajmie się kontrolą i utrzymywaniem sesji (np. OWASP ESAPI Session Management lub ASP.NET View State), wykorzystywać HMAC, by móc wykryć manipulacje. Unikać rejestrowania zmiennych globalnych w PHP, jeśli to jest tylko możliwe.