I was able to find an article that mentions that SQL injection can be done to SQL code in the following scenarios where stored procedures are involved:

  • EXEC statements
  • Dynamic Cursors

Assuming SQLi isn't directly possible (we have prepared statements and input sanitation anywhere user input is taken) but an attacker can get information into the database and SQL code processes this information (say, via a query to a table containing the attacker input), are there any other types of SQL code we should worry about?

1 Answer 1


In this case, persistent (stored) XSS has nothing to do with the actual risk of SQL Injection (SQLi). Stored XSS is one attack vector but not required for SQLi. The two golden rules of protecting against SQLi are:

  • Sanitize all user-supplied input (including URIs)
  • Use parameterized queries instead of concatenating raw SQL

Always validate your site after any code updates to ensure the expectations (assumptions) are still holding true. If you are trying to determine impact consider the following source for additional info on SQLi.

EDIT Updated to reflect updated question

Assuming you're asking if malicious code, stored as data in the database, can be harmful to the retrieving query, process, etc. the answer is: it depends. Typically, the malicious code would not be SQL syntax but HTML/JS. For this reason, it is equally (and sometimes more) important to do output sanitization to reduce the risk to the consuming entity (db, webserver, user, etc.).

  • Thanks, however, I meant this in a scenario where the SQL stored procedures are shared between multiple apps and a SQLi isn't directly possible, so an attacker would have to get information into the database and after that, have it processed by the vulnerable SQL code. I'll update the question to try and express this more clearly.
    – Daniel V
    Mar 15, 2018 at 17:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .