Securing PHP Applications: Stopping SQL Injection with Prepared Statements

Understand SQL injection in PHP and secure your app with prepared statements for robust database protection.

One line of careless PHP is all it takes. A login form that drops a username straight into a query string, and suddenly someone who never had a password is browsing your users table. SQL injection has topped the vulnerability charts for years, and it keeps showing up because the mistake behind it is so easy to make.

The fix is well understood and it’s not hard. This is a practical walk through how SQL injection happens in PHP, what it costs you, and how prepared statements shut it down. If you take one thing away, let it be this: never build a query by gluing user input into a string.

Table of Contents

• What is SQL Injection?
• Consequences of SQL Injection
• How SQL Injection Occurs in PHP
• Securing Queries with Prepared Statements
• Best Practices for Preventing SQL Injection
• Conclusion

What is SQL Injection?

SQL injection happens when an attacker slips their own SQL into a query your application runs. The root cause is always the same: user input gets mixed into the query as code instead of being kept separate as data. The database can’t tell the difference, so it runs whatever it’s handed.

The classic example is a login form. Feed it the right characters and you can make the WHERE clause always evaluate true, walking straight past authentication. Anywhere you store something worth stealing (credentials, personal details, payment data) an injectable query is a direct line to it.

Consequences of SQL Injection

What an attacker can do depends on what the query touches and what the database account is allowed to do. The usual outcomes:

• Unauthorized data access: reading out credentials, personal data, and financial records that were never meant to leave the database.
• Data manipulation: changing or deleting rows, which quietly corrupts your data and erodes user trust.
• Deeper compromise: depending on database privileges and configuration, injection can be a stepping stone to escalating access or reaching the wider system.
• Financial and reputational loss: a breach means cleanup costs, possible legal exposure, and customers who don’t come back.

None of that is worth the few characters you save by concatenating a string. Prevention is cheap; the aftermath isn’t.

How SQL Injection Occurs in PHP

It shows up when input goes into a query untouched. Here’s the query that keeps causing trouble:

Example of the code

<?php
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($connection, $query);

Put ' OR '1'='1 in the password field and the query becomes:

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1'

That’s always true, so the attacker is in without knowing a real password. (Worth flagging: this example also checks a plaintext password, which you should never do. Store a hash with password_hash() and verify with password_verify(). That’s a separate problem from injection, but the two habits tend to travel together.)

Securing Queries with Prepared Statements

Prepared statements are the primary defense against SQL injection, and they work by design rather than by cleverness. You send the query structure and the values to the database in two separate steps. The values arrive already marked as data, so nothing a user types can turn into executable SQL.

Here’s the login query rewritten with the MySQLi extension:

Example of the code

<?php
// Prepare the SQL statement
$stmt = $connection->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
// Bind parameters
$stmt->bind_param("ss", $username, $password);
// Execute the statement
$stmt->execute();
$result = $stmt->get_result();

The ? placeholders stand in for the values, which you attach with bind_param(). The database treats $username and $password as pure data. The ' OR '1'='1 trick from earlier just becomes a username nobody has.

PDO (PHP Data Objects) does the same thing and works across different database systems, which is why a lot of modern code reaches for it. Same query, PDO style:

Example of the code

<?php
// Create a PDO instance
$pdo = new PDO('mysql:host=localhost;dbname=database', $db_username, $db_password);
// Prepare the SQL statement
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND password = :password");
// Bind parameters
$stmt->bindParam(':username', $username);
$stmt->bindParam(':password', $password);
// Execute the statement
$stmt->execute();
$result = $stmt->fetch(PDO::FETCH_ASSOC);

PDO uses named placeholders like :username and :password, which are easier to read once a query has more than a couple of values. Pick MySQLi or PDO based on your project; both give you the same protection. The important part is that you bind values instead of concatenating them.

Best Practices for Preventing SQL Injection

Prepared statements do the heavy lifting. These habits back them up:

• Bind every value, no exceptions: if a piece of the query comes from a user, it goes through a placeholder. One concatenated query is enough to undo the rest.
• Allowlist the parts you can’t bind: placeholders only work for values, not for table names, column names, or keywords like ASC/DESC. When those come from user input (say, a sort column), check them against a fixed list of allowed names rather than dropping the raw string into the query.
• Validate input on its own terms: confirm an email looks like an email and an ID is an integer with filter_var(). That’s about data quality and defense in depth, not injection protection. And htmlspecialchars() is for escaping output when you print to HTML, not for making a query safe.
• Give the database account only what it needs: don’t connect as root. A least-privilege account limits how much damage any single query can do, injected or not.
• Use stored procedures carefully: they can help by keeping logic in the database, but they’re only safe if they don’t build dynamic SQL from their inputs. A stored procedure that concatenates strings is just as injectable.
• Handle errors quietly: log the details, show the user a generic message. Raw database errors hand an attacker a map of your schema.

Conclusion

SQL injection stays dangerous only because the mistake behind it is easy to repeat. Once you understand that the fix is separating the query from its data, prepared statements become the default and the whole class of bug mostly disappears.

Layer in the rest (least-privilege accounts, allowlisting the parts you can’t bind, real input validation, and quiet error handling) and you’ve closed the door on the most common way applications get breached. Bind your values with MySQLi or PDO, and this stops being something you have to worry about.