Does calling a stored procedure from PHP code prevent SQL injection?

I am very confused about stored procedures, and how to use them to prevent SQL injection. Everything I am reading online seems contradictory and each place gives one example which doesn't seem to work.

Is this, or is this not, secure from SQL injection?

PROCEDURE user_get_by_id (IN user_id INT)
BEGIN
    SELECT id, email, name, password_hash FROM users WHERE id=user_id;
END

Some tests I have run...
It works with ids that are ints...
It works with ids that are ints as strings...
It says something about fields if I use a string - but I just want it to recognize it is not an int? I tried using a string that is a field, and got the same error.
I used a string with a simple insertion injection (I will do work to test others)
E.G.

CALL user_get_by_id(4);
CALL user_get_by_id('4');
CALL user_get_by_id('4; INSERT INTO users () VALUE ();'); (I tested the second statement, and ensured it worked as a regular query, but it did not insert when used this way)

I will keep testing from my end, but maybe somebody on here knows if I am 99% there or not. thank you for your help!

I should mention that there is a PHP script which will call the procedure and will use user input.

It will be something similar to...

$query = "CALL user_get_by_id(".mysql_escape_string($+POST[id]).")";

Reason this question is different than the proposed similar question:

1. the offered response is different ways of crafting PHP code that is SQL injection safe, but this question is about another method using stored procedures and that is NOT provided in that question. Additionally, the answers in that question were not to my liking. Otherwise I would have used that thread when i came upon it the first, second, or third time.
2. this question is not a general how to question - this question is targetted, and specifically asks for advice. I think it is unreasonable to close a specific question by marking it the same as a general question (E.G. If someone is confused about why their math equation isn't working, it makes sense for the respondent to point out why, not mark the question as closed and direct them to a free online math course)

This is in fact secure from SQL injection:

PROCEDURE user_get_by_id (IN user_id INT)
BEGIN
    SELECT id, email, name, password_hash FROM users WHERE id=user_id;
END

By declaring the input argument as type INT, any string you try to pass as the argument will be coerced to a numeric value.

In MySQL, the numeric value of a string like '123abc' is 123, and it ignores any following non-numeric characters. A string that has no leading digits, for example 'abc123', has a numeric value of 0.

So it's safe even if you do this:

CALL user_get_by_id('4; INSERT INTO users () VALUE ();'); 

The value input to the procedure is simply the INT value 4. All the other characters in the argument are eliminated as the argument is cast as an INT.

So using the procedure is at least effective at protecting against SQL injection.

However, it isn't the recommended solution, because there are easier methods that don't require a stored procedure.

In PHP, you could cast the POST parameter to an integer value very easily, and either pass this as the value to a procedure:

$query = "CALL user_get_by_id({intval($_POST['id'])})"; 

Or even use it directly in a query string:

$query = "SELECT id, email, name, password_hash FROM users WHERE id={intval($_POST['id'])}";

This is an effective protection from SQL injection for integers, but it does NOT work for string or date inputs.

The following is unsafe, because there is no type casting, so there's still a risk that special characters could be copied into the SQL query and cause unintended logic:

$query = "SELECT id, email, name, password_hash FROM users WHERE name='{$_POST['id'])}'";

You could try to escape the special characters, but that gets confusing.

The solution that is recommended because it is always reliable, simpler, and safer is to use query parameters. Query parameters are not simply interpolation into a query string. They keep the dynamic value separate from the query until after it has been parsed, so there is no way the input value can corrupt the intended logic of the query.

$query = "SELECT id, email, name, password_hash FROM users WHERE id=?";
$stmt = $pdo->prepare($query);
$stmt->execute( [ $_POST['id'] ] );

Query parameters work equally well for both numeric inputs and string inputs.

It's even easier to write the code, read the code, and debug the code when you use query parameters!

To have an SQL injection you need 2 programming languages (or a single one that evaluates itself, e.g. with eval). The stored procedure you showed is pure SQL, so there is no way to inject anything.

However, if you call this procedure from PHP then it is possible to have SQL injection. Code like this is vulnerable:

$pdo->query('CALL sp('.$_POST['data'].')');

When you execute any SQL from PHP, you must use prepared statements. If you remember to never put any PHP variable within SQL then you should be safe from SQL injection.

In PHP, both extensions, mysqli and PDO, offer prepared statements. Make sure you call it like this:

$stmt = $pdo->prepare('CALL sp(?)');
$stmt->execute([$_POST['data']]);
// or
$mysqli->execute_query('CALL sp(?)', [$_POST['data']]);

This is now safe from SQL injection because the SQL string is constant.

Unrelated, but I highly discourage using stored procedures in PHP code. They are very difficult to use and obnoxious. Especially for a simple SQL as you have shown, stored procedure is unsuitable. Don't use stored procedures unless you absolutely must.