Only when they are written carefully. A stored procedure that passes parameters straight into fixed statements is as safe as a parameterized query. One that builds a SQL string from its arguments is just as injectable as application code, and the permissions it needs can raise the damage if the application is compromised.
What OWASP says
The SQL injection cheat sheet lists properly constructed stored procedures as one of its primary defences, alongside prepared statements. The key words are "properly constructed". The cheat sheet says they can be as safe as parameterized queries if they do not create unsafe dynamic SQL inside.
The query parameterization cheat sheet makes the same point from another angle. Parameterizing the SQL in your application does not cover SQL assembled inside a stored procedure.
Safe and unsafe, side by side
Safe: the procedure takes a customer ID and runs one fixed query. The parameter binds to its position automatically.
Unsafe: the procedure takes a table name or a filter string and concatenates it into a statement that it then executes.
If you must build dynamic SQL inside the database, use bind variables there too. The cheat sheet names the mechanisms: EXECUTE IMMEDIATE ... USING in Oracle PL/SQL, and sp_executesql with a typed parameter list in SQL Server Transact-SQL.
The permission problem
OWASP raises a less known drawback. Stored procedures need EXECUTE rights, which are not granted by default. In organizations where a centralized setup limits the application to default roles, teams may end up running the web app as db_owner. If that application is then compromised, the attacker gets far more database access than a read only account would give.
So a procedure based design can quietly work against least privilege if you do not manage grants deliberately.
A review checklist
- List every procedure the application calls.
- Flag any that use string concatenation,
EXECwith a built string, or dynamic table and column names. - Replace concatenation with bind variables, or with a fixed allowlist mapping for identifiers.
- Check which account the application uses and what it can do beyond EXECUTE.
- Confirm that errors from procedures do not return raw SQL or schema detail to users.
Which should you pick
For most new code, application side parameterized queries or an ORM are simpler to review, because the query lives next to the calling code. Stored procedures are reasonable when your organization already standardizes on them, as long as the review above is part of the process. OWASP recommends parameterized queries, stored procedures or an ORM for new and high risk applications, and does not rank one as always better.
Quick check
If my app only calls stored procedures, can I skip input validation?
No. OWASP says validation should still be a secondary defence, and validated data should still not be concatenated into SQL.
Sources
Last reviewed: 19 October 2026.
