PHP Sicherheitslücken verhindern: 10 Praxis-Tipps

November 8, 2026

PHP treibt nach wie vor einen riesigen Teil des Internets an. Doch in Code-Reviews sehe ich immer wieder dieselben vermeidbaren Sicherheitsfehler: ungeschützte SQL-Queries, fehlendes Output-Escaping oder veraltete Passworthashes. Sicherheitslücken entstehen selten durch PHP selbst, sondern fast immer durch unsicheres Softwaredesign und fehlendes Bewusstsein für Angriffsvektoren.

In diesem Artikel zeige ich dir praxisnah, wie du deine PHP-Backends effektiv härtest und gängige Angriffsvektoren systematisch schließt.

SQL-Injection gehört weiterhin zu den kritischsten Schwachstellen. Sobald Benutzereingaben direkt in SQL-Statements konkateniert werden, kann ein Angreifer Datenbankbefehle einschleusen, Daten auslesen oder Tabellen löschen.

Die einzig verlässliche Lösung ist der Einsatz von Prepared Statements via PDO oder den Methoden moderner ORMs (wie Doctrine oder Eloquent).

// Sicherer Datenbankzugriff mit Prepared Statements
$stmt = $pdo->prepare('SELECT id, username, password_hash FROM users WHERE username = :username');
$stmt->execute(['username' => $username]);
$user = $stmt->fetch(PDO::FETCH_ASSOC);

Durch die Trennung von SQL-Befehl und Datenstrukturen kann der Datenbankserver den Input niemals als ausführbaren Code interpretieren.

Verlasse dich niemals auf Daten, die vom Client kommen – egal ob $_POST, $_GET, Cookies oder HTTP-Header. Jede Eingabe muss validiert (entspricht das Format den Erwartungen?) und gegebenenfalls bereinigt (Sanitization) werden.

PHP bietet hierfür die oft unterschätzte Funktion filter_var().

// E-Mail bereinigen und validieren
$rawEmail = $_POST['email'] ?? '';
$email = filter_var($rawEmail, FILTER_SANITIZE_EMAIL);

if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    // Ungültige E-Mail-Adresse: Anfrage abbrechen oder Fehler zurückgeben
    http_response_code(400);
    exit('Ungültige E-Mail-Adresse');
}

Formate wie MD5 oder SHA1 sind seit Jahren kryptografisch gebrochen und auf moderner Hardware in Sekundenbruchteilen per Rainbow Table oder Brute-Force geknackt. Verwende ausschließlich die nativen PHP-Funktionen password_hash() und password_verify().

$plainPassword = 'MeinSuperGeheimesPasswort';

// Generiert automatisch einen sicheren Hash (standardmäßig bcrypt oder Argon2id)
$hashedPassword = password_hash($plainPassword, PASSWORD_DEFAULT);

// Passwortüberprüfung beim Login
if (password_verify($plainPassword, $hashedPassword)) {
    // Passwort ist korrekt
} else {
    // Zugangsdaten ungültig
}

XSS entsteht, wenn unbereinigter Benutzercode im Browser anderer Anwender ausgeführt wird. Der Schlüssel zur Vermeidung liegt im kontextgerechten Escaping bei der Ausgabe.

// Sichere Ausgabe in HTML-Kontexten
echo htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');

Achte strikt darauf, dass deine Anwendung durchgehend UTF-8 verwendet (in der Datenbank, in HTML-Meta-Tags und in den HTTP-Headern). Falsch behandeltes Charset-Encoding kann dazu führen, dass Filter durch Techniken wie Double Encoding oder UTF-7-Tricks umgangen werden.

Bei CSRF-Angriffen wird ein authentifizierter Benutzer unwissentlich dazu gebracht, eine zustandsändernde Anfrage an deine Anwendung zu senden. Jedes Formular und jede API-Schnittstelle, die Sessions nutzt, muss durch CSRF-Tokens geschützt werden.

// 1. CSRF-Token in der Session generieren
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

// 2. Im HTML-Formular einbinden:
// <input type="hidden" name="csrf_token" value="<?php echo htmlspecialchars($_SESSION['csrf_token']); ?>">

// 3. Im Controller/Handler validieren
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $token = $_POST['csrf_token'] ?? '';
    if (!hash_equals($_SESSION['csrf_token'], $token)) {
        http_response_code(403);
        die('CSRF-Angriff erkannt!');
    }
}

Hinweis: Verwende hash_equals(), um Timing-Angriffe beim Token-Vergleich zu verhindern.

Standardmäßig sind viele PHP-Installationen zu nachsichtig konfiguriert. Sessions müssen gegen Hijacking und Fixation abgesichert werden.

Setze Session-Cookies zwingend mit den passenden Flags:

• session.cookie_httponly = 1 (Verhindert Zugriff auf Cookies via JavaScript)
• session.cookie_secure = 1 (Erzwingt Übertragung nur über HTTPS)
• session.cookie_samesite = "Lax" oder "Strict" (Mindert CSRF-Risiken)

Regeneriere die Session-ID bei jedem Authentifizierungswechsel:

session_regenerate_id(true);

Nutze HTTP-Header, um moderne Browser-Schutzmechanismen zu aktivieren:

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

Dateiuploads sind einer der gefährlichsten Vektoren. Lädt ein Angreifer eine .php-Datei hoch und führt diese aus, hat er Remote Code Execution (RCE) auf deinem Server.

1. Web-Root verlassen: Speichere hochgeladene Dateien außerhalb des öffentlich zugänglichen Web-Verzeichnisses (z.B. /var/uploads/ statt /var/www/html/uploads/).
2. Dateinamen überschreiben: Verwende niemals den vom Client gesendeten Dateinamen. Generiere eine UUID oder ein Zufallshash.
3. MIME-Type prüfen: Verlasse dich nicht auf die Dateiendung oder $_FILES['userfile']['type']. Nutze finfo_file() zur Bestimmung des tatsächlichen MIME-Types.

Ob Passwort-Reset oder E-Mail-Bestätigung: Tokens müssen krytografisch sicher generiert, zeitlich beschränkt und nach einmaliger Nutzung invalidiert werden.

• Generiere Tokens mit random_bytes().
• Speichere nur den Hash des Tokens in der Datenbank (so bleibt das Token geschützt, selbst wenn die Datenbank kompromittiert wird).
• Prüfe bei der Einlösung das Ablaufdatum (z.B. maximale Gültigkeit 15 Minuten).

Fehlermeldungen wie PDO-Exceptions verraten Tabellennamen, Spaltenstrukturen und Serverpfade. In der php.ini für Production gilt:

display_errors = Off
log_errors = On

• Datenbank: Der PHP-Datenbankbenutzer sollte nur die Rechte haben, die er wirklich benötigt (z.B. kein DROP TABLE oder GRANT im laufenden Betrieb).
• Dateisystem: Der Webserver-User (www-data) sollte nur in explizit dafür vorgesehenen Ordnern Schreibrechte besitzen.

Setze statische Code-Analyse (SAST) wie Psalm oder PHPStan ein, um potenziell unsicheren Code frühzeitig in der CI/CD-Pipeline zu erkennen. Nutze außerdem composer audit oder Tools wie Snyk, um Drittanbieter-Bibliotheken regelmäßig auf bekannte Vulnerabilities (CVEs) zu scannen.

PHP-Sicherheit ist kein Hexenwerk, erfordert jedoch Disziplin und systematisches Vorgehen. Wer Prepared Statements, sauberes Escaping, sichere Sessions und aktuelle Dependencies kombiniert, schützt seine Anwendungen wirksam vor den häufigsten Angriffsvektoren.

Du möchtest deine bestehende PHP-Architektur auf Sicherheitslücken überprüfen oder benötigst Unterstützung bei der Härtung deiner Backends? Lass uns deine APIs und Applikationen gemeinsam zukunftssicher aufstellen: Büngener Software.