How to Sanitize User Input in PHP for SQL Injection and XSS

By the end of this page, you will understand why there is no single PHP function that safely handles all kinds of user input. You will learn the difference between validation, sanitization, SQL injection prevention, and XSS prevention, and how to correctly combine tools such as prepared statements, output escaping, and HTML allow-list filtering.

There is no single catch-all function in PHP that can safely solve SQL injection, XSS, and allowed HTML filtering at the same time.

These are different problems, and each requires a different solution.

The three separate concerns

1. SQL injection prevention

SQL injection happens when user input is mixed directly into an SQL query string.

The correct solution is:

• Use prepared statements
• Bind parameters
• Do not manually escape SQL unless absolutely necessary

In modern PHP, this usually means using PDO or MySQLi prepared statements.

2. XSS prevention

XSS happens when unsafe content is displayed in HTML and the browser interprets it as code.

The correct solution is:

• Escape output when rendering HTML
• In PHP, this usually means htmlspecialchars()

Important: XSS prevention is generally an output problem, not an input problem.

3. Allowing some HTML tags

Sometimes you want to allow formatting tags such as <b>, <i>, or <p>.

This is more complex than simply stripping tags. If you allow HTML, you must make sure:

• only approved tags are allowed
• dangerous attributes like onclick are removed
• dangerous URLs such as javascript: are blocked

Think of user input like a package arriving at a building.

• Validation checks whether the package is the right type: is this really an email, age, or comment?
• Prepared statements are like a secure loading dock for the database: the package contents cannot secretly rewrite the delivery instructions.
• Output escaping is like wrapping dangerous items before bringing them into a room: the browser sees text, not executable code.
• HTML sanitizing is like a security checkpoint that allows only approved items through, such as <b> and <p>, while removing dangerous ones.

The important lesson is that one security guard cannot do every job. Each step protects a different part of the system.

1. Prevent SQL injection with prepared statements

<?php
$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');

$name = $_POST['name'] ?? '';

$stmt = $pdo->prepare('SELECT * FROM users WHERE name = :name');
$stmt->execute(['name' => $name]);
$users = $stmt->fetchAll(PDO::FETCH_ASSOC);

Here, :name is a placeholder. The input is sent separately from the SQL command, so it cannot change the query structure.

2. Prevent XSS with output escaping

<?php
$comment = $_POST['comment'] ?? '';

echo htmlspecialchars($comment, ENT_QUOTES, 'UTF-8');

If the user submits:

Consider this example:

<?php
$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');

$comment = $_POST['comment'] ?? '';

$stmt = $pdo->prepare('INSERT INTO comments (body) VALUES (:body)');
$stmt->execute(['body' => $comment]);

echo htmlspecialchars($comment, ENT_QUOTES, 'UTF-8');

What happens step by step

1. Read input

$comment = $_POST['comment'] ?? '';

• If the form sent comment, its value is used.
• Otherwise, an empty string is used.

Example input:

Hello <>

Comment systems

Users submit comments that may contain text, punctuation, quotes, and sometimes limited formatting. A typical approach is:

• validate comment length
• store using prepared statements
• escape output for plain text comments
• or sanitize with an HTML allow-list for rich text comments

Blog or CMS editors

An admin or trusted user may be allowed to use tags like <p>, <h2>, and <a>. In this case:

• use a dedicated HTML sanitizer
• restrict tags and attributes
• reject dangerous protocols and event handlers

Search forms

A search term should not be inserted directly into SQL. Instead:

• pass the search text as a bound parameter
• escape the search text when redisplaying it in the page

Profile fields

Fields such as username, bio, and location all need different handling:

• username: validate allowed characters
• bio: maybe allow limited formatting
• location: often plain text only

APIs and admin panels

Even internal tools need safe handling. Admin users can accidentally paste unsafe HTML or malformed data. Security rules should still apply.

In real PHP projects, developers usually do not create one giant sanitize() function for everything. Instead, they use a few clear patterns.

1. Validate early

Developers check input as soon as it enters the application.

<?php
$title = trim($_POST['title'] ?? '');

if ($title === '') {
    throw new InvalidArgumentException('Title is required.');
}

This is often called validation at the boundary.

2. Use guard clauses

Guard clauses stop bad input early.

<?php
$age = $_POST['age'] ?? null;

if (!filter_var($age, FILTER_VALIDATE_INT)) {
    die('Age must be a valid integer.');
}

3. Store data safely, then escape on output

A common pattern is:

• validate input shape
• store with prepared statements

Mistake 1: Using one function for every security problem

Broken idea:

<?php
$input = addslashes($_POST['input']);

Why it is wrong:

• addslashes() is not a complete SQL injection defense
• it does not solve XSS
• it depends on database context and is easy to misuse

Use instead:

• prepared statements for SQL
• htmlspecialchars() for HTML output

Mistake 2: Escaping input before storing it

Broken code:

<?php
$comment = htmlspecialchars($_POST['comment'], ENT_QUOTES, 'UTF-8');
// store $comment in database

Why it is a problem:

• you mix storage with presentation
• the data is now HTML-specific
• output in another context becomes awkward or wrong

Better approach:

• store raw or validated/sanitized data
• escape when rendering

Mistake 3: Relying on strip_tags() for safe HTML

htmlspecialchars() vs

Core rules

• There is no single catch-all sanitize function for all security problems.
• Use prepared statements to prevent SQL injection.
• Use htmlspecialchars() to prevent XSS in HTML output.
• Use validation to make sure input matches expected formats.
• If you want to allow some HTML, use an allow-list HTML sanitizer such as HTML Purifier.

Safe patterns

SQL query

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute(['email' => $email]);

HTML output

echo htmlspecialchars($text, ENT_QUOTES, 'UTF-8');

Email validation

filter_var($email, FILTER_VALIDATE_EMAIL)

Plain text only

$plain = ();

Is there a single PHP function to prevent both SQL injection and XSS?

No. SQL injection and XSS are different problems. Use prepared statements for SQL and output escaping for HTML.

Should I sanitize input before saving it to the database?

Usually, validate it before saving, but do not HTML-escape everything before storage. Escape when outputting the data.

Is htmlspecialchars() enough to stop XSS?

It is the standard solution for plain text in HTML output. If you want to allow HTML, use a proper HTML sanitizer instead.

Is strip_tags() safe for allowing a few tags?

Not by itself. It can remove tags, but it does not fully protect against dangerous attributes or complex HTML payloads.

What should I use in PHP for SQL injection prevention?

Use PDO or MySQLi prepared statements with bound parameters.

When should I use filter_var()?

Use it for validation, such as checking emails, integers, and URLs. It does not replace SQL protection or XSS protection.

Can I trust admin or logged-in users more?

You can trust them more for permissions, but their input should still be handled safely. Mistakes and unsafe pasted content can still happen.

• Prepared statements — the main defense against SQL injection in database queries.
• Output escaping — protects HTML pages from XSS by encoding unsafe characters.
• Input validation — ensures data matches the format your application expects.
• HTML sanitization — safely allows approved HTML while removing dangerous content.
• PDO in PHP — a common PHP database API that supports prepared statements.
• Cross-site scripting (XSS) — the browser-side attack that output escaping helps prevent.
• SQL injection — the database attack prevented by separating SQL commands from input.
• htmlspecialchars() — the standard PHP function for escaping text in HTML output.
• filter_var() — useful for validating common input types such as emails and integers.