Is it safe to truncate a table without using a prepared statement?

Question

I've used the following sort of code a few times in my current project to clear out some tables. Incase it's not obvious I'm using PDO.

 $clearResult = $db->query('TRUNCATE TABLE table_name');

I'm currently going through and updating a few of my earlier scripts to make sure they all make use of prepared statements and are written in a way to reduce (hopefully stop) sql injection.

Answer 1

No, there's no user input in the actual query so there's no risk of injection.

You do have to make sure that a user isn't able to trigger the truncate though, unless they're authorized.

Answer 2

It's not the SQL operation that determines whether or not a prepared statement should be used. To prevent SQL Injection, a prepared statement should be used when any variable is involved in the query where bound parameters are permitted. That is not limited to just user input either, any variable at all should be a bound paremeter, regardless of where it came from.

In your example there are no variables required for the query, and so there is no security benefit of using a prepared statement.

Even if your table_name was coming from user input or a variable, a prepared statement would not be a solution because it is not possible to bind the table name.

Answer 3

Prepared statements would have no effect on your truncate query.

PDO prepared statements are useful when running queries with user input as they allow you to use features such as bound parameters to sanitise user input.

They are also useful for optimising queries that will run multiple times.

You might want to read up a little on prepared statements in the PHP documentation - PHP documentation for prepared statements:

Many of the more mature databases support the concept of prepared statements. What are they? They can be thought of as a kind of compiled template for the SQL that an application wants to run, that can be customized using variable parameters. Prepared statements offer two major benefits:

The query only needs to be parsed (or prepared) once, but can be executed multiple times with the same or different parameters. When the query is prepared, the database will analyze, compile and optimize its plan for executing the query. For complex queries this process can take up enough time that it will noticeably slow down an application if there is a need to repeat the same query many times with different parameters. By using a prepared statement the application avoids repeating the analyze/compile/optimize cycle. This means that prepared statements use fewer resources and thus run faster.

The parameters to prepared statements don't need to be quoted; the driver automatically handles this. If an application exclusively uses prepared statements, the developer can be sure that no SQL injection will occur (however, if other portions of the query are being built up with unescaped input, SQL injection is still possible). Prepared statements are so useful that they are the only feature that PDO will emulate for drivers that don't support them. This ensures that an application will be able to use the same data access paradigm regardless of the capabilities of the database.