This implies that at some point you are constructing SQL statements by string concatenation involving untrusted strings. Don't do that! Use prepared statements instead (or some other form of query parameterization), as they are pretty much intrinsically immune to SQLi.
I'm assuming you mean your frontend successfully blocks all the SQLi you tried. This doesn't mean it will block all SQLi, of course; that depends on how thorough your testing is.
However, once the query reaches your backend (assuming that's your DBMS), there really isn't any way to tell what SQL comes from SQLi and what SQL is legitimate. You really have to trust that what's coming in on the database connection is trustworthy.
Of course, it is wise to limit the impact of such attacks as much as possible. Most simply, and commonly, you can limit the permissions of the application's service account on the database to only those actions it actually performs. This doesn't prevent SQLi per se, but it will lessen the impact if any exists.
Another possible approach is to abstract some of the SQL away in a data access layer the frontend talks to, and avoid passing any strings to the DBMS that didn't come from the application itself (and certain trusted columns in certain tables). It's much easier to just use prepared statements.