Ryzyko ataku za pomocą wstrzyknięcia kodu można zmniejszyć poprawnie korzystając z narzędzi takich jak Hibernate lub Enterprise Java Beans, przy czym najlepsze efekty przynosi separacja pomiędzy danymi a kodem (niezależnie od używanych narzędzi). Zapytania SQL powinny być realizowane za pomocą parametryzacji lub procedur składowanych, należy unikać składania treści zapytania w locie i późniejszego wykonywania za pomocą exec. Należy także zapewnić ochronę przez oznaczanie (escape), filtrowanie lub zamianę niektórych znaków pobieranych z zewnątrz. Można w tym celu wykorzystać pakiet Oracle DBMS_ASSERT lub funkcję mysql_real_escape_string() API motoru MySQL dostępną zarówno w C, jak i w PHP. Poleganie na czarnej liście znaków też nie jest dobrym pomysłem, lepiej przyjąć strategię ścisłego sprawdzania wartości, odrzucając wszystkie parametry, które nie pasują do dokładnie określonego wzorca.

1. Brak zachowania struktury serwisu webowego (Cross-site Scripting)

Błąd Cross-site Scripting (XSS) jest jednym z najważniejszych zagrożeń dla serwisów webowych, gdyż wykorzystywany jest bezstanowy protokół HTTP i przetwarza się mieszaninę danych oraz skryptów w HTML, także pomiędzy stronami, przy różnych schematach kodowania. Idea ataku polega na umieszczeniu na witrynie WWW fragmentu kodu (na przykład, Javascript lub innej aktywnej treści), który staje się elementem strony i zostaje wykonany razem z jej kodem, z uprawnieniami użytkownika danej strony, przy czym ma dostęp do zasobów, jakie serwis oferuje. Skutkiem takiego ataku jest wykonanie obcego kodu pobieranego ze strony często oznaczonej jako zaufana. W ten sposób można przejąć bardzo dużo informacji od wielu użytkowników, przekierować ich na fałszywą stronę lub umieścić złośliwe oprogramowanie bez znaczącej modyfikacji serwisu. Największe ryzyko niesie błąd, w którym do treści strony da się wstawić taki kod na stałe (persistent XSS) - na przykład na forach internetowych lub stronach Web 2.0 - gdyż może on posłużyć do naruszenia bezpieczeństwa bardzo wielu użytkowników. Połączenie błędów persistent XSS oraz CSRF jest bardzo poważnym zagrożeniem dla webowych serwisów, takich jak bankowość elektroniczna lub serwisy społecznościowe.

Aby chronić serwis przed atakiem XSS, należy używać języków, bibliotek lub frameworków, które w łatwiejszy sposób dostarczą poprawnie enkodowaną treść - np. Apache Wicket, OWASP ESAPI Encoding lub Microsoft Anti-XSS i zadbać o wymuszenie właściwego enkodowania (UTF-8, ISO-8859-2). Dobrym pomysłem jest też filtrowanie znaku "<", ustawienie cookie jako HttpOnly, by zawartość tego cookie nie była dostępna dla skryptów po stronie klienta, które używają document.cookie. Niestety, metody te posiadają także swoje ograniczenia.

Jedną z metod obrony przed atakami XSS jest odpowiednie filtrowanie ruchu na zaporach aplikacyjnych. Być może nie wychwycą wszystkich ataków i będą wymagały odpowiedniego dostrojenia, ale mogą ochronić także te aplikacje webowe, których zmodyfikować nie można (na przykład dlatego, że nie ma dla nich dostępnego kodu źródłowego lub licencja zabrania takich zmian). Dodatkowo, mogą ochronić przed atakami do czasu usunięcia danej podatności. Po stronie klienta nieco pomaga dodatek NoScript, który posiada opcję ochrony przed niektórymi z ataków XSS.