Ciò implica che a un certo punto si stanno costruendo istruzioni SQL mediante concatenazione di stringhe che coinvolgono stringhe non attendibili. Non farlo! Usa invece istruzioni preparate (o qualche altra forma di parametrizzazione della query), poiché sono praticamente intrinsecamente immuni a SQLi.
Suppongo che intendi che il tuo frontend blocca con successo tutti gli SQLi che hai provato. Questo non significa che bloccherà tutto SQLi, ovviamente; questo dipende da quanto è accurato il test.
Tuttavia, una volta che la query raggiunge il tuo back-end (supponendo che sia il tuo DBMS), non c'è davvero alcun modo per dire quale SQL proviene da SQLi e quale SQL è legittimo. Devi davvero credere che ciò che sta arrivando sulla connessione al database sia affidabile.
Naturalmente, è saggio limitare l'impatto di tali attacchi il più possibile. Molto semplicemente, e comunemente, è possibile limitare le autorizzazioni dell'account di servizio dell'applicazione sul database solo alle azioni effettivamente eseguite. Ciò non impedisce SQLi di per sé, ma ridurrà l'impatto se ne esiste uno.
Un altro approccio possibile è quello di astrarre parte dell'SQL in un livello di accesso ai dati a cui parla il frontend, ed evitare di passare qualsiasi stringa al DBMS che non proviene dall'applicazione stessa (e alcune colonne attendibili in certe tabelle) . È molto più semplice usare solo istruzioni preparate.