PHP Security Best Practices in 2026: A Practical Checklist

PHP security best practices in 2026 look different from the advice that circulated a decade ago, not because the threats changed dramatically, but because the language and its ecosystem finally made the secure path the easy path. Prepared statements are the default in every maintained framework, password hashing is a two-function affair, and Composer will warn you about vulnerable dependencies before an attacker exploits them. Yet the same vulnerability categories keep appearing in breach reports year after year, because secure defaults only help when teams consistently use them. This post is a practical checklist of what actually matters now: injection, cross-site scripting, session handling, password storage and supply-chain hygiene.

SQL injection: solved in theory, alive in practice

SQL injection has had a complete, boring solution for twenty years: parameterised queries. Every serious PHP database layer supports them, and ORMs such as Eloquent and Doctrine use them by default. Injection survives in 2026 almost entirely through string concatenation in legacy code, raw query escape hatches, and dynamically built fragments like sort columns. The baseline looks like this:

$pdo = new PDO($dsn, $user, $password, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false,
]);

$stmt = $pdo->prepare(
    'SELECT id, total FROM orders WHERE customer_id = ? AND status = ?'
);
$stmt->execute([$customerId, $status]);

Disabling emulated prepares makes PDO send real server-side prepared statements, so values never travel inside the SQL text. The subtle trap is that placeholders only work for values, not identifiers. You cannot parameterise a column name in an ORDER BY clause, so dynamic sorting must go through an allowlist:

$allowed = ['created_at', 'total', 'status'];
$column = in_array($request['sort'], $allowed, true)
    ? $request['sort']
    : 'created_at';

$stmt = $pdo->query("SELECT * FROM orders ORDER BY {$column}");

If you find yourself escaping a value manually to build a query string, treat it as a design smell and reach for a placeholder or the query builder instead.

Cross-site scripting: escape at output, by context

Cross-site scripting remains the most common web vulnerability because it hides in the smallest gaps: an unescaped error message, a value dropped into a JavaScript block, a URL built from user input. The rule that prevents it is simple to state: escape at the point of output, for the context you are outputting into. For HTML body content, that means htmlspecialchars() with the right flags:

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

ENT_QUOTES covers attribute contexts by escaping both quote styles, and ENT_SUBSTITUTE prevents invalid UTF-8 from silently truncating output. In practice, most teams should let a template engine do this work: Twig and Blade both auto-escape by default, and their raw-output syntax (|raw, {!! !!}) makes every dangerous exception visible in code review.

Two contexts deserve special care. Never build inline JavaScript by concatenating user data; pass values through json_encode() with the hex flags or, better, via data- attributes read by your scripts. And validate user-supplied URLs before echoing them into href attributes, because javascript: URLs sail straight through HTML escaping. Finally, add a Content-Security-Policy header. CSP does not replace escaping, but it turns many exploitable mistakes into browser console warnings.

Sessions: small settings, big consequences

PHP session handling is secure when configured deliberately and leaky when left on defaults from an old tutorial. The settings that matter fit in a few lines of php.ini or a bootstrap call:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"
session.use_strict_mode = 1
session.use_only_cookies = 1

cookie_secure keeps the session cookie off plain HTTP, cookie_httponly hides it from JavaScript, and SameSite blunts cross-site request forgery by refusing to send the cookie on most cross-origin requests. use_strict_mode rejects uninitialised session IDs, closing off session fixation. The behavioural rule to pair with these settings: call session_regenerate_id(true) on every privilege change, most importantly at login, so a pre-authentication session ID never becomes an authenticated one. For state-changing forms, SameSite cookies are strong but not sufficient on their own; keep per-session CSRF tokens, which every major framework generates for you.

Password storage: two functions, zero cleverness

Password hashing is the one area where the correct answer is genuinely short. Use password_hash() to store, password_verify() to check, and password_needs_rehash() to upgrade old hashes transparently as algorithms and cost factors improve:

$hash = password_hash($password, PASSWORD_DEFAULT);

if (password_verify($password, $storedHash)) {
    if (password_needs_rehash($storedHash, PASSWORD_DEFAULT)) {
        $user->updatePasswordHash(password_hash($password, PASSWORD_DEFAULT));
    }
    // authenticated
}

PASSWORD_DEFAULT currently means bcrypt with a salt generated for you; if your PHP build includes libsodium support you can opt into PASSWORD_ARGON2ID, which is memory-hard and the modern recommendation. What you must never do is roll your own scheme: no md5(), no sha1(), no fast SHA-256 with a homemade salt. Those functions are designed to be fast, and fast is precisely the property an attacker with a GPU wants. Round out the story with rate limiting on login endpoints and constant-time comparison (hash_equals()) anywhere you compare secrets like API tokens or reset codes.

Dependencies: your attack surface is mostly other people's code

A typical PHP application ships a few thousand lines of first-party code and hundreds of thousands from Composer packages, which means supply-chain hygiene is not optional. The tooling is mature; the discipline is the hard part:

• Run composer audit in CI. It checks your lock file against known advisories and fails the build on vulnerable versions, catching problems before deployment rather than after disclosure.
• Commit and deploy from composer.lock. Reproducible installs mean the code you audited is the code in production.
• Automate updates. Renovate or Dependabot turn patch upgrades into small, reviewable pull requests instead of terrifying quarterly migrations.
• Prefer fewer, better-maintained packages. Every dependency is a maintainer you trust; check release cadence and issue responsiveness before adopting.
• Stay on supported PHP. Running an end-of-life PHP version means known engine vulnerabilities with no patches coming, which undermines everything else on this list.

The habits that hold it together

Beyond the big five categories, a handful of habits close most remaining gaps. Turn off display_errors in production and log instead, so stack traces never leak paths and credentials. Give the application database user only the privileges it needs; a read-only reporting endpoint has no business holding DROP TABLE rights. Validate uploaded files by content, store them outside the web root, and serve them through a controlled handler. Send the standard hardening headers: X-Content-Type-Options: nosniff, X-Frame-Options or CSP frame-ancestors, and a strict Referrer-Policy.

The takeaway

None of this is exotic. PHP security in 2026 is a checklist discipline: parameterise every query, escape every output for its context, configure sessions once and correctly, let password_hash() do its job, and treat your dependency tree as production code. Attackers overwhelmingly exploit the basics done inconsistently, not zero-days. Make the basics automatic, through framework defaults, CI checks and code review norms, and your PHP application becomes a genuinely hard target.