PHP Security: Common Vulnerabilities and Prevention

Table Of Contents

• The Security Mindset: From Trusting to Paranoid (In a Good Way)
• 1. SQL Injection - The Vulnerability That Taught Me Everything
  • The Problem
  • The Solution
  • Advanced SQL Injection Prevention
• 2. Cross-Site Scripting (XSS) - The Vulnerability I Almost Missed
  • The Problem
  • The Solution
  • Content Security Policy (CSP)
• 3. Cross-Site Request Forgery (CSRF) - The Silent Attack
  • The Problem
  • The Solution
• 4. Authentication and Session Security
  • Secure Password Handling
  • Session Security
• 5. File Upload Security - The Feature That Nearly Became a Backdoor
  • Secure File Upload
• 6. Input Validation and Sanitization
• 7. API Security
• 8. Security Headers and HTTPS
• 9. Database Security
• 10. Logging and Monitoring
• Security Testing
• Security Checklist
• Conclusion: From Security Victim to Security Advocate

I learned about security the way no developer wants to learn - by watching my Laravel application get compromised in production. It was 3 AM, I was woken up by alerts, and our user database was being systematically extracted through a SQL injection vulnerability I never saw coming. The attacker was polite enough to leave a text file on our server: "Your security is terrible. Fix it."

That humbling experience changed everything about how I approach PHP development. Security went from an afterthought to the foundation of every application I build. The vulnerability that brought down our system? A dynamic search query that I thought was "safe enough" because it was behind authentication. Spoiler alert: it wasn't.

Since then, I've made it my mission to understand security deeply enough that I'll never experience that 3 AM panic again. Every line of code I write now passes through a security filter in my brain, and I've helped prevent countless vulnerabilities in the projects I've worked on. This experience shaped my approach to web application security best practices that I follow religiously today.

The Security Mindset: From Trusting to Paranoid (In a Good Way)

After that breach, I developed what my colleagues call "security paranoia" - but it's the good kind. I now assume that every input is crafted by someone trying to break my application. It sounds extreme, but this mindset has saved me from vulnerabilities countless times.

The shift was profound: instead of thinking "this input looks fine," I now think "how could someone abuse this input?" This paranoid approach has become second nature and has prevented more attacks than I can count.

1. SQL Injection - The Vulnerability That Taught Me Everything

SQL injection was the exact vulnerability that destroyed my confidence and rebuilt it stronger. The search feature I built seemed innocent enough - users could search products by various criteria. But I made the classic mistake of building dynamic queries with string concatenation.

Here's the simplified version of what brought down my application:

The Problem

// NEVER DO THIS - Vulnerable to SQL injection
$userId = $_GET['user_id'];
$query = "SELECT * FROM users WHERE id = " . $userId;
$result = mysqli_query($connection, $query);

// This allows an attacker to inject: ?user_id=1 OR 1=1
// Resulting query: SELECT * FROM users WHERE id = 1 OR 1=1
// This would return all users!

The Solution

// Always use prepared statements
$userId = $_GET['user_id'];
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$userId]);
$user = $stmt->fetch();

// Even better with Laravel Eloquent
$user = User::find($userId); // Automatically uses prepared statements

// For complex queries
$users = User::where('status', $status)
    ->where('created_at', '>', $date)
    ->get();

// Learn more about Laravel security in our API development guide:
// https://mycuriosity.blog/laravel-api-development-best-practices-and-security

Advanced SQL Injection Prevention

// Validate input types
function validateUserId($userId): int
{
    if (!is_numeric($userId) || $userId <= 0) {
        throw new InvalidArgumentException('Invalid user ID');
    }
    return (int) $userId;
}

// Use whitelisting for dynamic queries
function buildOrderClause($sortBy): string
{
    $allowedColumns = ['name', 'email', 'created_at'];
    
    if (!in_array($sortBy, $allowedColumns)) {
        throw new InvalidArgumentException('Invalid sort column');
    }
    
    return "ORDER BY " . $sortBy;
}

// Safe dynamic query building
public function getUsersWithFilters(array $filters): Collection
{
    $query = User::query();
    
    if (isset($filters['status'])) {
        $query->where('status', $filters['status']);
    }
    
    if (isset($filters['role'])) {
        $query->where('role', $filters['role']);
    }
    
    return $query->get();
}

2. Cross-Site Scripting (XSS) - The Vulnerability I Almost Missed

I thought I was safe from XSS because I was using Laravel's Blade templates, which escape output by default. But then I built a rich text editor for user comments and made the decision to use {!! !!} for "better formatting." That decision almost cost me my job when a security researcher demonstrated how they could steal admin sessions through crafted comments. This experience taught me the importance of proper validation techniques in Laravel applications.

XSS is particularly insidious because it exploits the trust users have in your site:

The Problem

// Vulnerable to XSS
$username = $_POST['username'];
echo "Welcome, " . $username; // If username contains <script>...</script>

// Also vulnerable
$comment = $_POST['comment'];
echo "<div>" . $comment . "</div>"; // Executes any JavaScript in comment

The Solution

// Always escape output
$username = $_POST['username'];
echo "Welcome, " . htmlspecialchars($username, ENT_QUOTES, 'UTF-8');

// Laravel's Blade templates automatically escape
// {{ $username }} - Automatically escaped
// {!! $username !!} - Raw output (use with caution)

// For rich text, use a library like HTML Purifier
use HTMLPurifier;
use HTMLPurifier_Config;

function sanitizeHtml($html): string
{
    $config = HTMLPurifier_Config::createDefault();
    $config->set('HTML.Allowed', 'p,b,i,em,strong,ul,ol,li,a[href]');
    $purifier = new HTMLPurifier($config);
    return $purifier->purify($html);
}

Content Security Policy (CSP)

// Implement CSP headers
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'");

// In Laravel middleware
class SecurityHeadersMiddleware
{
    public function handle($request, Closure $next)
    {
        $response = $next($request);
        
        $response->headers->set('Content-Security-Policy', "default-src 'self'; script-src 'self'");
        $response->headers->set('X-Content-Type-Options', 'nosniff');
        $response->headers->set('X-Frame-Options', 'DENY');
        $response->headers->set('X-XSS-Protection', '1; mode=block');
        
        return $response;
    }
}

3. Cross-Site Request Forgery (CSRF) - The Silent Attack

CSRF attacks trick users into performing unintended actions on applications where they're authenticated. This is particularly dangerous for actions like changing passwords or making purchases.

The Problem

<!-- Malicious site can trigger this -->
<form action="https://yoursite.com/transfer-money" method="POST">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="to_account" value="attacker_account">
    <input type="submit" value="Click here for free stuff!">
</form>

The Solution

// Laravel automatically includes CSRF protection
// In your forms, always include the CSRF token
<form method="POST" action="/transfer-money">
    @csrf
    <input type="number" name="amount" required>
    <input type="text" name="to_account" required>
    <button type="submit">Transfer</button>
</form>

// For AJAX requests
$.ajaxSetup({
    headers: {
        'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
    }
});

// Custom CSRF implementation
class CSRFProtection
{
    public static function generateToken(): string
    {
        $token = bin2hex(random_bytes(32));
        $_SESSION['csrf_token'] = $token;
        return $token;
    }
    
    public static function validateToken($token): bool
    {
        return isset($_SESSION['csrf_token']) && 
               hash_equals($_SESSION['csrf_token'], $token);
    }
}

4. Authentication and Session Security

Secure authentication is the foundation of application security. Weak authentication systems are often the first target of attackers.

Secure Password Handling

// NEVER store passwords in plain text
// NEVER use MD5 or SHA1 for passwords

// Correct password hashing
function hashPassword($password): string
{
    return password_hash($password, PASSWORD_ARGON2ID, [
        'memory_cost' => 65536,
        'time_cost' => 4,
        'threads' => 3,
    ]);
}

// Correct password verification
function verifyPassword($password, $hash): bool
{
    return password_verify($password, $hash);
}

// Password strength validation
function isPasswordStrong($password): bool
{
    return strlen($password) >= 8 &&
           preg_match('/[A-Z]/', $password) &&
           preg_match('/[a-z]/', $password) &&
           preg_match('/[0-9]/', $password) &&
           preg_match('/[^A-Za-z0-9]/', $password);
}

Session Security

// Secure session configuration
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);

// Regenerate session ID on login
session_regenerate_id(true);

// Laravel session security
// config/session.php
'lifetime' => 120,
'expire_on_close' => false,
'encrypt' => true,
'files' => storage_path('framework/sessions'),
'connection' => null,
'table' => 'sessions',
'store' => null,
'lottery' => [2, 100],
'cookie' => 'laravel_session',
'path' => '/',
'domain' => null,
'secure' => true,
'http_only' => true,
'same_site' => 'strict',

5. File Upload Security - The Feature That Nearly Became a Backdoor

File uploads taught me that convenience and security are often at odds. I built what I thought was a simple image upload feature for user avatars. Users could upload images, they'd be resized and stored, and everyone would be happy. What I didn't anticipate was someone uploading a PHP file disguised as an image and then accessing it directly to execute arbitrary code on my server.

This near-miss taught me that file uploads require military-grade paranoia:

Secure File Upload

class SecureFileUpload
{
    private $allowedMimeTypes = [
        'image/jpeg',
        'image/png',
        'image/gif',
        'application/pdf'
    ];
    
    private $maxFileSize = 5 * 1024 * 1024; // 5MB
    
    public function upload($file, $uploadDir): string
    {
        // Validate file
        $this->validateFile($file);
        
        // Generate secure filename
        $filename = $this->generateSecureFilename($file);
        
        // Move file outside web root
        $uploadPath = $uploadDir . '/' . $filename;
        
        if (!move_uploaded_file($file['tmp_name'], $uploadPath)) {
            throw new Exception('File upload failed');
        }
        
        return $filename;
    }
    
    private function validateFile($file): void
    {
        // Check for upload errors
        if ($file['error'] !== UPLOAD_ERR_OK) {
            throw new Exception('File upload error');
        }
        
        // Check file size
        if ($file['size'] > $this->maxFileSize) {
            throw new Exception('File too large');
        }
        
        // Validate MIME type
        $finfo = finfo_open(FILEINFO_MIME_TYPE);
        $mimeType = finfo_file($finfo, $file['tmp_name']);
        finfo_close($finfo);
        
        if (!in_array($mimeType, $this->allowedMimeTypes)) {
            throw new Exception('Invalid file type');
        }
    }
    
    private function generateSecureFilename($file): string
    {
        $extension = pathinfo($file['name'], PATHINFO_EXTENSION);
        return uniqid() . '.' . $extension;
    }
}

6. Input Validation and Sanitization

Never trust user input. Always validate and sanitize data before processing.

class InputValidator
{
    public static function validateEmail($email): string
    {
        $email = filter_var($email, FILTER_VALIDATE_EMAIL);
        if ($email === false) {
            throw new InvalidArgumentException('Invalid email address');
        }
        return $email;
    }
    
    public static function validateUrl($url): string
    {
        $url = filter_var($url, FILTER_VALIDATE_URL);
        if ($url === false) {
            throw new InvalidArgumentException('Invalid URL');
        }
        return $url;
    }
    
    public static function sanitizeString($string): string
    {
        return htmlspecialchars(trim($string), ENT_QUOTES, 'UTF-8');
    }
    
    public static function validateAge($age): int
    {
        $age = filter_var($age, FILTER_VALIDATE_INT, [
            'options' => [
                'min_range' => 1,
                'max_range' => 150
            ]
        ]);
        
        if ($age === false) {
            throw new InvalidArgumentException('Invalid age');
        }
        
        return $age;
    }
}

// Laravel validation rules
$request->validate([
    'email' => 'required|email|max:255',
    'password' => 'required|min:8|confirmed',
    'age' => 'required|integer|min:1|max:150',
    'website' => 'nullable|url',
    'avatar' => 'nullable|image|max:2048'
]);

7. API Security

APIs need special security considerations, especially for authentication and rate limiting. Building secure APIs requires a comprehensive understanding of authentication mechanisms and security patterns that go beyond basic implementation.

// API Rate Limiting
class RateLimiter
{
    private $redis;
    
    public function __construct($redis)
    {
        $this->redis = $redis;
    }
    
    public function checkLimit($key, $maxRequests, $timeWindow): bool
    {
        $current = $this->redis->incr($key);
        
        if ($current === 1) {
            $this->redis->expire($key, $timeWindow);
        }
        
        return $current <= $maxRequests;
    }
}

// API Authentication with JWT
use Firebase\JWT\JWT;
use Firebase\JWT\Key;

class JWTAuth
{
    private $secret;
    
    public function __construct($secret)
    {
        $this->secret = $secret;
    }
    
    public function generateToken($userId): string
    {
        $payload = [
            'user_id' => $userId,
            'exp' => time() + 3600, // 1 hour
            'iat' => time(),
            'jti' => uniqid()
        ];
        
        return JWT::encode($payload, $this->secret, 'HS256');
    }
    
    public function validateToken($token): ?array
    {
        try {
            $decoded = JWT::decode($token, new Key($this->secret, 'HS256'));
            return (array) $decoded;
        } catch (Exception $e) {
            return null;
        }
    }
}

8. Security Headers and HTTPS

Implement security headers to protect against various attacks.

// Security Headers Middleware
class SecurityHeadersMiddleware
{
    public function handle($request, Closure $next)
    {
        $response = $next($request);
        
        // Force HTTPS
        if (!$request->secure() && app()->environment('production')) {
            return redirect()->secure($request->getRequestUri());
        }
        
        // Security headers
        $response->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
        $response->headers->set('X-Content-Type-Options', 'nosniff');
        $response->headers->set('X-Frame-Options', 'DENY');
        $response->headers->set('X-XSS-Protection', '1; mode=block');
        $response->headers->set('Referrer-Policy', 'strict-origin-when-cross-origin');
        
        return $response;
    }
}

9. Database Security

Beyond SQL injection, there are other database security considerations.

// Database connection security
$options = [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
    PDO::ATTR_EMULATE_PREPARES => false,
    PDO::MYSQL_ATTR_SSL_CA => '/path/to/ca.pem',
    PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT => false,
];

// Database user with minimal privileges
// CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'strong_password';
// GRANT SELECT, INSERT, UPDATE, DELETE ON app_database.* TO 'app_user'@'localhost';
// FLUSH PRIVILEGES;

10. Logging and Monitoring

Security without monitoring is incomplete. Always log security events.

class SecurityLogger
{
    public static function logFailedLogin($email, $ip)
    {
        Log::warning('Failed login attempt', [
            'email' => $email,
            'ip' => $ip,
            'user_agent' => request()->userAgent(),
            'timestamp' => now()
        ]);
    }
    
    public static function logSuspiciousActivity($userId, $activity)
    {
        Log::alert('Suspicious activity detected', [
            'user_id' => $userId,
            'activity' => $activity,
            'ip' => request()->ip(),
            'timestamp' => now()
        ]);
    }
    
    public static function logSecurityEvent($event, $data)
    {
        Log::info('Security event', [
            'event' => $event,
            'data' => $data,
            'timestamp' => now()
        ]);
    }
}

Security Testing

Always test your security implementations:

// Security test examples
class SecurityTest extends TestCase
{
    public function test_sql_injection_prevention()
    {
        $maliciousInput = "1' OR '1'='1";
        $user = User::find($maliciousInput);
        
        $this->assertNull($user);
    }
    
    public function test_xss_prevention()
    {
        $maliciousScript = '<script>alert("XSS")</script>';
        $sanitized = htmlspecialchars($maliciousScript, ENT_QUOTES, 'UTF-8');
        
        $this->assertStringNotContainsString('<script>', $sanitized);
    }
    
    public function test_csrf_protection()
    {
        $response = $this->post('/sensitive-action', [
            'data' => 'test'
        ]);
        
        $response->assertStatus(419); // CSRF token mismatch
    }
}

Security Checklist

Based on my experience securing applications in production:

1. Input Validation - Validate all user input
2. Output Encoding - Escape all output
3. Authentication - Use strong password policies and MFA (avoid building custom auth systems)
4. Authorization - Implement proper access controls
5. Session Management - Secure session configuration
6. HTTPS - Always use HTTPS in production
7. Security Headers - Implement comprehensive security headers
8. Error Handling - Don't expose sensitive information in errors
9. File Uploads - Validate and sanitize uploaded files
10. Database Security - Use prepared statements and principle of least privilege
11. API Security - Implement rate limiting and proper authentication
12. Logging - Log all security events
13. Updates - Keep all dependencies updated
14. Code Reviews - Review code for security issues (follow clean code principles for better security audits)
15. Penetration Testing - Regular security testing

Conclusion: From Security Victim to Security Advocate

That 3 AM wake-up call transformed me from a developer who "hoped" his code was secure to one who knows it is. Security isn't just about preventing attacks anymore - it's about building applications that users can trust with their most sensitive data.

The journey from that devastating breach to becoming someone my team relies on for security guidance taught me several crucial lessons:

Security is a Mindset: It's not a checklist you complete, it's a way of thinking about every line of code you write. When I review code now, I automatically ask "how could this be exploited?"

Start with the Basics: The most sophisticated security measures are worthless if you have basic vulnerabilities. SQL injection, XSS, and CSRF prevention will stop 95% of attacks.

Learn from Others' Mistakes: I study security breaches not to feel superior, but to learn. Every breach report teaches me something new about attack vectors I hadn't considered.

Test Your Assumptions: That search feature I thought was secure because it required authentication? It wasn't. Always verify your security assumptions through testing and code review.

Security is Everyone's Job: In my current role, I make sure every developer on the team understands security basics. A chain is only as strong as its weakest link.

The most rewarding part of this journey has been helping other developers avoid the mistakes I made. When a junior developer shows me their code and asks "is this secure?", I remember my own journey and make sure they understand not just what to fix, but why it matters. Following PHP coding standards and best practices makes security reviews much more effective.

Security vulnerabilities will always exist, but with the right mindset and practices, you can build applications that are incredibly difficult to compromise. The goal isn't perfection - it's making your application so well-defended that attackers move on to easier targets. Understanding PHP memory management and performance optimization also contributes to more secure applications by reducing attack surfaces and improving stability.

Every line of secure code you write is a small victory against the chaos of the internet. Make sure your victories outnumber your vulnerabilities.