How to Write Secure PHP Code: Preventing SQL Injection, XSS, and CSRF

PHP powers over 75% of all websites with a known server-side language, including WordPress, Laravel, and Drupal. This ubiquity makes PHP applications a prime target for attackers. The OWASP Top 10—the industry-standard classification of critical web application vulnerabilities—consistently lists Injection (SQL Injection) and Cross-Site Scripting (XSS) among the most dangerous threats. Understanding these attack vectors and implementing robust defenses is not optional; it is a fundamental professional responsibility for every PHP developer shipping code to production.

SQL Injection (SQLi) occurs when user-supplied input is concatenated directly into an SQL query string. An attacker can input `admin' OR '1'='1` into a login form, transforming a legitimate `WHERE` clause into one that always evaluates to true, bypassing authentication entirely. The definitive prevention is Prepared Statements with Parameterized Queries using PDO: `$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email"); $stmt->execute(['email' => $userInput]);`. This ensures the database engine treats the input as a literal data value, never as executable SQL code, regardless of what the attacker types.

Cross-Site Scripting (XSS) allows attackers to inject malicious JavaScript into pages viewed by other users. Stored XSS persists the payload in the database (e.g., a malicious comment). Reflected XSS embeds the payload in a URL parameter. DOM-based XSS manipulates the client-side JavaScript directly. The primary defense is output encoding: always pass user-generated content through `htmlspecialchars($data, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')` before rendering it in HTML. For rendering user-supplied HTML (like a blog editor), use a dedicated sanitization library like HTMLPurifier to strip dangerous tags while preserving safe formatting.

CSRF attacks trick an authenticated user's browser into submitting a forged request (like changing their email address or transferring funds) to your application. Because the browser automatically attaches cookies, the server cannot distinguish the forged request from a legitimate one. The defense is a Synchronizer Token Pattern: on every form render, generate a unique, random token using `bin2hex(random_bytes(32))`, store it in `$_SESSION['csrf_token']`, and embed it as a hidden `` field. On form submission, compare the submitted token against the session token. If they don't match, reject the request immediately.

Never store passwords in plaintext or using weak hashing algorithms like MD5 or SHA-1. PHP provides the `password_hash()` function, which defaults to the bcrypt algorithm with automatic salting. Use `password_hash($password, PASSWORD_BCRYPT)` for hashing and `password_verify($userInput, $storedHash)` for verification. For maximum security, PHP 7.2+ supports Argon2id via `PASSWORD_ARGON2ID`, which is resistant to both GPU-based brute-force attacks and side-channel timing attacks, making it the recommended choice for new applications handling sensitive financial or healthcare data.

Sessions are the backbone of PHP authentication, and mismanaging them creates critical vulnerabilities. After a successful login, always call `session_regenerate_id(true)` to prevent Session Fixation attacks. Configure session cookies with the `HttpOnly` flag (preventing JavaScript access), the `Secure` flag (HTTPS only), and the `SameSite=Strict` attribute (preventing CSRF via cookies). Set aggressive session timeouts using `session.gc_maxlifetime`. For high-security applications, bind the session to the user's IP address and User-Agent string, invalidating the session if either changes unexpectedly.

Defense in depth requires validating all user input. Use PHP's `filter_var()` with specific filters like `FILTER_VALIDATE_EMAIL`, `FILTER_VALIDATE_URL`, and `FILTER_VALIDATE_INT` to reject malformed data at the application boundary. Beyond server-side defenses, implement a Content Security Policy (CSP) HTTP header. A strict CSP like `Content-Security-Policy: default-src 'self'; script-src 'self'` instructs the browser to only execute JavaScript loaded from your own domain, providing a powerful last line of defense against XSS even if your server-side sanitization has a gap.

No amount of careful coding replaces systematic testing. Integrate Static Application Security Testing (SAST) tools like PHPStan (with the `phpstan-strict-rules` extension) and SonarQube into your CI/CD pipeline to scan for vulnerabilities on every commit without executing code. For runtime testing, use Dynamic Application Security Testing (DAST) tools like OWASP ZAP or Burp Suite, which simulate real-world attacks against your running application. Schedule periodic third-party penetration tests using gray-box methodology for the most comprehensive security assessment.