PHP Security: How to Protect Your Site from SQL Injections and XSS

Your PHP Code in the Crosshairs: Why Silence Isn't Golden

Imagine: you launched a website, everything runs like clockwork, clients are happy. Meanwhile, somewhere in a dark corner of the internet, a script kiddie enters the magic string ' OR 1=1 -- into your search form. And the database, like an obedient servant, hands over all user passwords. Sound familiar? Unfortunately, for many beginner developers, it does.

Security in PHP isn't boring bureaucracy; it's real protection for your time, money, and reputation. Today we'll break down the two main enemies of web applications: SQL injections and cross-site scripting (XSS). You'll learn how to recognize them, neutralize them, and never let them into your code again.

SQL Injections: When the User Becomes a Hacker

An SQL injection is an attack where an attacker "injects" malicious SQL code through input fields. If you simply insert user data into a query, consider that you've opened the door for a burglar yourself.

What Vulnerable Code Looks Like

Here's a classic example that still appears in old textbooks and on live websites:

<?php\n// DANGEROUS! Never do this\n$username = $_POST['username'];\n$password = $_POST['password'];\n\n$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";\n$result = mysqli_query($conn, $query);\n?>

What happens if you enter admin' -- in the username field? The query becomes:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

The double hyphen -- comments out the rest of the query. Voilà — the attacker logs in as admin without a password. And if you enter '; DROP TABLE users; --? Goodbye, users.

Lifesaver: Prepared Statements

The best way to protect against SQL injections is to use prepared statements via PDO or MySQLi. They separate the query logic from the data, so malicious code never gets executed.

Here's what secure code with PDO looks like:

<?php\n// SAFE! Using prepared statements\n$username = $_POST['username'];\n$password = $_POST['password'];\n\n$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND password = :password");\n$stmt->execute(['username' => $username, 'password' => $password]);\n$user = $stmt->fetch();\n?>

Now even if an attacker passes admin' OR 1=1 --, PDO will treat it as a regular string, not as part of an SQL command. The database will say: "Looking for a user with that strange name." And it won't find one.

Why PDO Instead of mysql_*?

\n
• Security by default: PDO automatically escapes data.
\n
• Flexibility: supports different DBMS (MySQL, PostgreSQL, SQLite).
\n
• Named placeholders: code becomes readable and maintainable.
\n
• Object-oriented approach: modern programming style.
\n

The mysql_* functions were removed in PHP 7.0, and that's for the best. If you're still using mysqli_real_escape_string — it's better than nothing, but PDO is still more reliable.

XSS Attacks: When Code Hides in Comments

Cross-site scripting (XSS) is the injection of JavaScript code into a page through user input. Imagine: a user leaves a comment, but instead of text, they write:

<script>alert('Your site has been hacked!');</script>

If you output this without processing, every visitor will see a pop-up window. And what if instead of alert, there's code that steals cookies or redirects to a phishing site?

Types of XSS Attacks

\n
• Reflected: Malicious co