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


4 Answers 4


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: https://stackoverflow.com/questions/627918/am-i-safe-against-sql-injection


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."
  • 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
    Commented Nov 21, 2010 at 12:10

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...

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

  • 1
    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
    Commented Jan 25, 2012 at 14:43

You must log in to answer this question.

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