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.

Why PHP Security Best Practices Are Not Optional

PHP security best practices are a set of defensive coding patterns that prevent attackers from exploiting common vulnerabilities like SQL injection, XSS, and remote code execution. The core mechanic is simple: never trust user input. Every piece of data from $_GET, $_POST, $_COOKIE, or $_FILES must be validated, sanitized, or escaped before use. This isn't a feature toggle — it's a discipline enforced at every data boundary.

In practice, this means using parameterized queries (prepared statements) for all database interactions, applying htmlspecialchars() for output escaping, and validating input against strict whitelists. Prepared statements separate SQL logic from data, making injection impossible regardless of input content. Output escaping prevents script execution in the browser. Input validation rejects malformed data early, reducing attack surface.

You apply these practices from day one — retrofitting security is expensive and error-prone. In real systems, a single unescaped query parameter can leak millions of records. The 2017 Equifax breach (SQL injection via unvalidated input) exposed 147M people. PHP's addslashes() is not a substitute for prepared statements — it's a false sense of security that has caused real billion-record leaks.

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);
}
?>

File Inclusion: Lock the Back Door

You think remote file inclusion died in 2007? Think again. In 2024, I patched a legacy app that still used include($_GET['page']); — one careless parameter away from a RCE. The rule is simple: never use user input to build file paths. If you must allow dynamic includes, maintain a whitelist of allowed files. PHP 8.x gives you match() for strict comparisons. But the real fix is architecting your app to route through a front controller — no direct file access. That dying pattern of defining a constant like 'isdoc' in every include? It's a bandage on a bullet wound. It stops casual snooping but does nothing against a crafted request. Production apps need proper autoloading and a single entry point. Your include files should be namespaced classes, not script snippets. If you're still using require_once statements scattered across views, you're one misconfiguration away from a breach. Lock down your includes before someone locks you out of your own server.

// io.thecodeforge
// Safe dynamic include using strict match() in PHP 8.x
declare(strict_types=1);

class PageRouter {
    private const ALLOWED_PAGES = [
        'dashboard' => '/var/www/views/dashboard.php',
        'profile'   => '/var/www/views/profile.php',
        'settings'  => '/var/www/views/settings.php',
    ];

    public function loadPage(string $page): void {
        $path = match($page) {
            'dashboard' => self::ALLOWED_PAGES['dashboard'],
            'profile'   => self::ALLOWED_PAGES['profile'],
            'settings'  => self::ALLOWED_PAGES['settings'],
            default     => throw new \InvalidArgumentException('Invalid page request'),
        };
        require $path;
    }
}

Error Handling: Your Debug Mode Is a Public Menu

I once found a production server dumping full stack traces to end users. Every PHP error, every database query, every table name — served like a menu to attackers. In PHP 8.x, display_errors should be Off in production. Period. But that's not enough. Log errors to a secure location outside web root. Use set_error_handler() to catch and sanitize exceptions before they escape. Sensitive data — passwords, tokens, PII — should never appear in logs. Implement a structured logging system like Monolog with different channels for errors, security events, and application flow. On dev, use error_reporting(E_ALL) for full visibility. On prod, log only what you need to debug without exposing internals. The old habit of hiding PHP version with expose_php = Off is cosmetic — real security comes from controlling error output. One uncaught exception in production can reveal your database schema, file paths, and even your internal architecture. Treat errors like classified documents: classify them, restrict access, and destroy them when no longer needed.

// io.thecodeforge
// Production-safe error handler for PHP 8.x
declare(strict_types=1);

class SecureErrorHandler {
    public function __construct(
        private readonly string $logPath = '/var/log/app/errors.log'
    ) {
        set_error_handler([$this, 'handle']);
        set_exception_handler([$this, 'handleException']);
    }

    public function handle(int $level, string $message, string $file, int $line): bool {
        // Log sanitized error (strip file paths, sensitive data)
        $sanitized = preg_replace('/\/var\/www\/[^ ]+/', 'REDACTED_PATH', $message);
        error_log("[ERROR] Level $level: $sanitized in $file:$line", 3, $this->logPath);
        
        // Return 500 to user — no details
        http_response_code(500);
        echo json_encode(['error' => 'Internal server error']);
        return true; // Prevent PHP's default handler
    }

    public function handleException(\Throwable $e): void {
        $this->handle(E_ERROR, $e->getMessage(), $e->getFile(), $e->getLine());
    }
}

// Bootstrap
new SecureErrorHandler();