Sprawdzać dane wejściowe

Najpoważniejszym błędem jest niedostateczna kontrola danych wprowadzanych do aplikacji. Podatność ta może wynikać z wielu dróg wprowadzania danych, z których nie wszystkie są odpowiednio opracowane i monitorowane. Luk w bezpieczeństwie, związanych z niedostateczną analizą wprowadzanych danych, należy się wystrzegać podczas programowania kodu. Niemal wszystkie języki programowania wykorzystywane do pisania aplikacji webowych posiadają gotowe narzędzia do takiej kontroli, należy ich używać. Sprawdzać należy nie tylko dane wprowadzane od strony użytkownika, ale także od strony systemu, a nawet stałe, przekazywane z plików konfiguracyjnych do aplikacji. Oprócz kontroli, należy także ograniczać ich rozmiar, by uniknąć przepełnień bufora.

Błąd nie powinien być wskazówką

Dla napastnika próbującego odnaleźć luki w bezpieczeństwie aplikacji, błędy wyświetlane podczas kolejnych prób mogą być bardzo cenną wskazówką. Należy zatem przygotować aplikację w ten sposób, by nie wyświetlała żadnych szczegółów, poza lakoniczną informacją o błędzie. Wbrew pozorom, komunikaty błędów mogą być bardzo cenne dla włamywacza, gdyż w ten sposób mogą ujawniać: typ i wersję serwera, uruchomione rozszerzenia, opcje i detale konfiguracji, położenie ścieżek systemowych oraz szczegóły systemu operacyjnego, ustawione zmienne, adresację IP, a nawet komplet informacji diagnostycznych. Takie informacje powinny się znaleźć, ale wyłącznie w logu, napastnik nie może ich zobaczyć przy próbie włamania.

Nie ufać danym z bazy

Dane pobierane przez aplikację z bazy muszą być traktowane jako niezaufane. Chociaż jest to podejście nieco paranoiczne, jest racjonalne. Mało znaczący błąd SQL Injection w jednym z modułów, który sam w sobie nie powoduje natychmiastowego naruszenia bezpieczeństwa (na przykład umożliwiając dopisanie do tymczasowej tabeli danych, które i tak będą wyczyszczone po zakończeniu sesji), może zostać wykorzystany do znacznie poważniejszego ataku, przez eksploitowanie podatności aplikacji na dane dostarczane z bazy. Jeśli aplikacja w jakikolwiek sposób parsuje dane pobierane z plików dostarczanych z zasobów dyskowych, należy zastosować szczególne środki bezpieczeństwa i chronić przed wykonaniem kodu tą drogą.

Dobrze organizować pracę

Obszernych aplikacji nigdy nie pisze jedna osoba, dlatego należy wdrożyć jasny system prowadzenia kodu, jego komentowania oraz klarownej notacji. W ten sposób można uniknąć bardzo poważnych błędów wynikających z niezrozumienia pomiędzy działami. Należy dokumentować sposób użycia procedur i zadbać o jak najpowszechniejsze ponowne wykorzystywanie kodu. Dzięki temu unika się ponownego wyprogramowywania tych samych zadań, a proces usuwania błędów trwa o wiele krócej. Jest także znacznie sprawniejszy.

Dobrze przetestować

Testowanie jest integralną częścią prac związanych z produkcją aplikacji. Testować program powinny osoby, które nie były związane z jego produkcją, gdyż nie będą wiedziały, jakie ma on właściwości i ograniczenia. Będą mogły sprawdzić czasami nieprawdopodobne warunki, takie jak zerowa ilość sprzedanego towaru lub ujemna kwota zapłaconego rachunku. Testowanie powinno się odbywać w separowanym środowisku, będącym odzwierciedleniem środowiska produkcyjnego, to środowisko powinno działać na realnych danych (być może zmodyfikowanych dla zachowania poufności, ale maksymalnie zbliżonych do danych produkcyjnych). Na etapie testowania należy unikać poważnych błędów, takich jak próby w środowisku produkcyjnym, pozostawienie w aplikacji nieużywanego kodu czy udostępnienie opcji debugowania lub ujawnienia innych informacji testowych. Te błędy mogą później skutkować podatnością aplikacji na naruszenie bezpieczeństwa.