PHP SQL Injection: addslashes() Caused Billion-Record Leak

PHP powers roughly 77% of all server-side websites, which makes it the single biggest attack surface on the web. That popularity is a double-edged sword: there's a massive ecosystem of tooling and community knowledge, but there's also an enormous catalogue of known exploits, automated scanners, and script kiddies running them 24/7 against every public-facing PHP endpoint on the planet. A single unparameterised query or an unescaped echo can hand an attacker your entire database or hijack every active user session on your platform.

The problem isn't that PHP is inherently insecure — modern PHP 8.x is genuinely well-engineered. The problem is that PHP's permissive heritage (it was designed to get things on-screen fast) means it's trivially easy to write vulnerable code that looks completely fine to an untrained eye. A junior developer can ship a working feature that also ships a critical vulnerability, and neither automated linters nor code review will catch it unless the reviewer knows exactly what to look for.

By the end of this article you'll be able to identify and remediate the OWASP Top 10 vulnerabilities as they apply specifically to PHP, harden sessions against fixation and hijacking attacks, implement Content Security Policy headers programmatically, hash passwords correctly (and understand why every other approach is wrong), and lock down file upload endpoints so they can't be weaponised. This isn't theory — every pattern here is battle-tested in production systems handling millions of requests per day.

PHP Security: The Attack Surface and Defence Layers

PHP security isn't a single technique — it's a stack of layers you build into every request. Input validation, prepared statements, output escaping, secure sessions, CSRF tokens, CSP headers, and proper hashing. Each layer costs a little more code, but each one buys a defence that might save your entire system.

Here's the thing: attackers don't break your crypto. They exploit the gaps between layers. A missing htmlspecialchars() after a prepared statement still gives them XSS. A missing CSRF token on an API endpoint still lets them forge requests. You don't get to pick one and call it done.

The mental model is an onion. If someone peels through prepared statements (rare, but character-set bypasses exist), the CSP header stops script execution. If they get past CSP (unlikely), session regeneration limits damage. You build redundancy into security.

<?php
// io.thecodeforge.security.secure_entry
declare(strict_types=1);
session_start();

// Validate + sanitize
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if (!$id) {
    http_response_code(400);
    exit('Invalid input');
}

// Prepare statement
$pdo = new PDO('mysql:host=localhost;dbname=app', $user, $pass);
$stmt = $pdo->prepare('SELECT title, body FROM posts WHERE id = :id');
$stmt->execute(['id' => $id]);
$post = $stmt->fetch();

// Escape output
echo htmlspecialchars($post['title'], ENT_QUOTES, 'UTF-8');
?>

SQL Injection Prevention: Prepared Statements Are Non-Negotiable

SQL injection is the most exploited vulnerability in PHP applications, and the fix is trivial: never concatenate user input into SQL queries. Use PDO prepared statements with bound parameters. The database driver handles escaping and ensures that input is never interpreted as SQL code. Also validate input types — if you expect an integer, cast it with (int) or use filter_var(). Never rely on addslashes() or magic_quotes — those are bandaids, not fixes.

<?php
// io.thecodeforge.security.safe_query
$pdo = new PDO('mysql:host=localhost;dbname=app', $user, $pass);
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute(['email' => $_POST['email']]);
$user = $stmt->fetch();
?>
// Using positional placeholders
$stmt = $pdo->prepare('SELECT * FROM orders WHERE id = ? AND status = ?');
$stmt->execute([$orderId, 'active']);

XSS Prevention: Trust No Output

Cross-Site Scripting (XSS) happens when an attacker injects JavaScript into your pages. The core defence is context-aware escaping: htmlspecialchars($data, ENT_QUOTES, 'UTF-8') for HTML body contexts, and use JavaScript-safe escaping for embedded data. But the real power move is Content Security Policy (CSP). Set a strict CSP header that blocks all inline scripts by default, then allow only specific hashes or nonces. That way, even if an injection slips through, the browser refuses to execute it.

<?php
// io.thecodeforge.security.xss_prevention
// Output escaping
echo htmlspecialchars($userComment, ENT_QUOTES, 'UTF-8');

// CSP header
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . bin2hex(random_bytes(16)) . "'");
?>
// In template (e.g., Twig):
// {{ userComment|e('html') }}

CSRF Protection: Token Every State Change

Cross-Site Request Forgery (CSRF) tricks an authenticated user into performing actions they didn't intend — like changing their email or transferring money. The standard defence is a synchronizer token: generate a random token, store it in the session, embed it in every form, and validate it on submission. In modern PHP, also set SameSite=Strict or Lax on session cookies — this blocks most CSRF attacks without any extra code. For APIs, consider using custom request headers (e.g., X-CSRF-Token) that are checked server-side.

<?php
// io.thecodeforge.security.csrf
session_start();
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}
?>
<form method="POST" action="/update_profile">
    <input type="hidden" name="csrf_token" value="<?= $_SESSION['csrf_token'] ?>">
    <!-- other fields -->
</form>

<?php
// Validation
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    die('CSRF validation failed');
}
?>
// Also set cookie attribute
session_set_cookie_params([
    'samesite' => 'Strict',
    'httponly' => true,
    'secure' => true
]);

Password Hashing: Never Roll Your Own

PHP provides password_hash() and password_verify() which use bcrypt or Argon2 under the hood. These algorithms are deliberately slow to resist brute force. Never use MD5, SHA1, or even SHA256 for passwords — they are fast and can be cracked at billions of hashes per second. Use PASSWORD_BCRYPT (cost factor 12+) or PASSWORD_ARGON2ID (PHP 8.1+). Also, always use a random salt — the functions handle that automatically.

<?php
// io.thecodeforge.security.password_hashing
// Registration
$hash = password_hash($_POST['password'], PASSWORD_ARGON2ID, ['memory_cost' => 1024, 'time_cost' => 3, 'threads' => 2]);
// Save $hash to database

// Login
if (password_verify($inputPassword, $storedHash)) {
    // success
} else {
    // failure
}

// Rehash if algorithm updated
if (password_needs_rehash($storedHash, PASSWORD_ARGON2ID)) {
    $newHash = password_hash($inputPassword, PASSWORD_ARGON2ID);
    // update database
}
?>

Session Hardening: Cookies That Fight Back

Session hijacking and fixation attacks are common when session cookies lack security flags. Always use session_set_cookie_params() with HttpOnly (prevents JavaScript access), Secure (HTTPS only), SameSite (Strict/Lax), and a reasonable lifetime. Also regenerate session ID after login (session_regenerate_id(true)) to prevent session fixation. Store session data securely — use files in a non-public directory or better, use Redis with encryption for high-traffic apps.

<?php
// io.thecodeforge.security.session_hardening
// Before session_start()
ini_set('session.cookie_httponly', 1);
ini_set('session.cookie_secure', 1);
ini_set('session.cookie_samesite', 'Strict');
ini_set('session.use_strict_mode', 1);
ini_set('session.gc_maxlifetime', 7200);

session_start();
// Regenerate on privilege change
if ($user->authenticated && !$user->justLoggedIn) {
    session_regenerate_id(true);
}
?>