Take the 2-minute tour ×

Is it true that Stored procedure will prevent databases to be injected? I did a little research and I found out that SQL-Server, Oracle and MySQL are not safe against SQL injection if we only use stored procedure. However, this problem does not exist in postgreSQL. Does stored procedure implementation in postgreSQL core prevent it from SQL injection or are there any other reasons/differences? or I can use SQL injection in postgreSQL if we use only stored procedure.

share|improve this question
add comment

4 Answers

In short - no, stored procedures does not prevent from SQL Injection. It depends on how you do handle dynamic SQL inside stored procedure.

For more complete answer, check what is posted here: http://stackoverflow.com/questions/627918/am-i-safe-against-sql-injection

share|improve this answer
add comment

Check these links and the picture will get clearer:



"...Measures to avoid SQL injection

  1. Validate all input coming from the user on the server.
  2. Avoid the use of dynamic SQL queries if there an alternate method is available.
  3. Use parameterized stored procedure with embedded parameters.
  4. Execute stored procedures using a safe interface such as Callable statements in JDBC or CommandObject in ADO.
  5. Use a low privileged account to run the database.
  6. Give proper roles and privileges to the stored procedure being used in the applications."
share|improve this answer
Just to be a bit OCD, 5&6 (least privilege) will not prevent SQLi, it can only mitigate the damage if one exists. 'course thats not to say its not a great recommendation... –  AviD Nov 21 '10 at 12:10
add comment

IF you use SP correctly, then you are pretty much safe from SQL Injection (assuming you still do proper input validation anyway, of course). IF.

Ah, but what does it mean, to use SP correctly?

Two of the most common mis-uses of SP that I see often, and can each lead to SQL Injection even with Stored Procedures, are:

  • Dynamic SQL inside the SP.
  • Calling the SP from code as you would execute a concatenated string. I.e. just sending to the database "exec spname (param1)", instead of using command/parameter objects (or parameterizing the query, depending on language). SQLi can still be injected into the SP call...
share|improve this answer
add comment

You need variable binding along with named parameters, regardless if the query is a stored procedure or not. Also need to worry about certain SQL statements like LIKE

share|improve this answer
It's a very picky point to pick up on, but the parameters don't need to be named; Bound positional-parameters are also safe from SQLi. –  Cheekysoft Jan 25 '12 at 14:43
add comment

Your Answer


