Web Security Basics: XSS, CSRF und SQL Injection einfach erklärt

Web Security ist kein Thema nur für große Unternehmen. Auch kleine Websites und persönliche Projekte können angegriffen werden – oft automatisiert durch Bots, die gezielt nach Sicherheitslücken suchen.

Wenn du Formulare, Login-Systeme oder APIs entwickelst, solltest du die drei häufigsten Sicherheitslücken kennen:

• Cross-Site Scripting (XSS)
• Cross-Site Request Forgery (CSRF)
• SQL Injection

In diesem Beitrag erkläre ich diese drei Schwachstellen verständlich und mit einfachen Beispielen aus der Praxis.

1. Cross-Site Scripting (XSS)

Was ist XSS?

Cross-Site Scripting (kurz XSS) entsteht, wenn ein Angreifer eigenen JavaScript-Code in deine Website einschleusen kann. Dieser Code wird dann im Browser anderer Nutzer ausgeführt.

Das passiert häufig bei:

• Kommentar-Systemen
• Suchfeldern
• Benutzerprofilen
• Formularen
• Chat-Systemen

Immer dann, wenn Benutzereingaben ohne Prüfung wieder angezeigt werden, besteht ein Risiko.

Beispiel für eine XSS-Lücke

Angenommen, du zeigst den Namen eines Benutzers direkt aus einer URL an:

<p>Hallo, <?php echo $_GET["name"]; ?></p>

Wenn ein Benutzer nun folgenden Wert eingibt:

<script>alert("Hacked")</script>

Dann wird dieses Skript im Browser ausgeführt. In einem echten Angriff könnte der Code deutlich gefährlicher sein als ein simples Popup.

Was kann bei XSS passieren?

Ein erfolgreicher XSS-Angriff kann dazu führen, dass:

• Cookies gestohlen werden
• Benutzer-Sessions übernommen werden
• Inhalte auf der Seite verändert werden
• Benutzer auf andere Seiten umgeleitet werden
• Schadcode im Namen deiner Website ausgeführt wird

Gerade bei Login-Systemen kann das sehr gefährlich werden.

Wie verhindert man XSS?

Die wichtigste Regel lautet:

Benutzereingaben niemals ungefiltert anzeigen.

Stattdessen sollten Eingaben immer escaped werden.

Sicheres Beispiel:

<p>
  Hallo, 
  <?php echo htmlspecialchars($_GET["name"]); ?>
</p>

Zusätzliche Schutzmaßnahmen:

• Eingaben validieren (z. B. nur erlaubte Zeichen zulassen)
• Content Security Policy (CSP) verwenden
• HTML-Ausgabe immer escapen
• Framework-eigene Sicherheitsfunktionen nutzen

2. Cross-Site Request Forgery (CSRF)

Was ist CSRF?

Cross-Site Request Forgery (CSRF) zwingt Benutzer dazu, Aktionen auszuführen, ohne dass sie es merken.

Das funktioniert, weil ein Benutzer bereits in einer Website eingeloggt ist und sein Browser automatisch Cookies mitsendet.

Ein Angreifer nutzt genau dieses Verhalten aus.

Beispiel für einen Angriff

Stell dir vor, deine Website hat eine URL, die einen Account löscht:

https://example.com/delete-account

Ein Angreifer könnte eine Seite mit folgendem Inhalt erstellen:

<img src="https://example.com/delete-account">

Wenn ein eingeloggter Benutzer diese Seite besucht, wird die Anfrage automatisch gesendet – ohne dass der Benutzer etwas bemerkt.

Wie verhindert man CSRF?

Die wichtigste Maßnahme ist die Verwendung von CSRF-Tokens.

Ein CSRF-Token ist ein zufälliger Wert, der bei jeder Anfrage überprüft wird.

Beispiel:

<input type="hidden" 
       name="csrf_token" 
       value="RANDOM_TOKEN">

Beim Absenden des Formulars wird geprüft:

if ($_POST["csrf_token"] !== $_SESSION["csrf_token"]) {
    die("Invalid CSRF Token");
}

Weitere Schutzmaßnahmen:

• SameSite-Cookies verwenden
• Wichtige Aktionen nur über POST erlauben
• Benutzeraktionen bestätigen lassen (z. B. Passwort erneut eingeben)

3. SQL Injection

Was ist SQL Injection?

SQL Injection entsteht, wenn Benutzereingaben direkt in SQL-Abfragen eingebaut werden.

Ein Angreifer kann so eigenen SQL-Code einschleusen und die Datenbank manipulieren.

Das ist eine der ältesten und gleichzeitig gefährlichsten Sicherheitslücken.

Unsicheres Beispiel

$query = "SELECT * FROM users 
          WHERE email = '$email' 
          AND password = '$password'";

Wenn ein Angreifer als Passwort eingibt:

' OR 1=1 --

Dann wird die Abfrage zu:

SELECT * FROM users 
WHERE email = '' 
AND password = '' OR 1=1 --

Das Ergebnis: Zugriff ohne korrektes Passwort.

Sicheres Beispiel mit Prepared Statements

Die beste Lösung sind Prepared Statements.

$stmt = $pdo->prepare(
  "SELECT * FROM users 
   WHERE email = ? 
   AND password = ?"
);

$stmt->execute([$email, $password]);

Warum das sicher ist:

• Eingaben werden nicht als Code interpretiert
• SQL-Struktur bleibt unverändert
• Angriffe werden effektiv verhindert

Prepared Statements sollten immer verwendet werden, wenn mit Datenbanken gearbeitet wird.

Allgemeine Security Best Practices

Neben XSS, CSRF und SQL Injection gibt es weitere wichtige Sicherheitsmaßnahmen, die in jedem Projekt berücksichtigt werden sollten.

HTTPS verwenden

Alle modernen Websites sollten HTTPS nutzen. Dadurch werden Daten verschlüsselt übertragen und können nicht einfach abgefangen werden.

Passwörter sicher speichern

Passwörter sollten niemals im Klartext gespeichert werden.

Stattdessen sollten sichere Hash-Funktionen wie bcrypt verwendet werden.

Beispiel:

$passwordHash = password_hash($password, PASSWORD_DEFAULT);

Beim Login:

password_verify($password, $passwordHash);

Eingaben immer validieren

Egal ob Formulare, URLs oder API-Daten – alle Eingaben sollten überprüft werden.

Beispiele:

• E-Mail-Adressen validieren
• Zahlenbereiche prüfen
• Zeichenlängen begrenzen

Security Headers verwenden

HTTP-Header können zusätzliche Sicherheit bieten.

Wichtige Beispiele:

• Content-Security-Policy
• X-Frame-Options
• X-Content-Type-Options
• Strict-Transport-Security

Dependencies aktuell halten

Viele Sicherheitslücken entstehen durch veraltete Libraries.

Darum:

• Regelmäßig Updates installieren
• Sicherheitsmeldungen verfolgen
• Nicht benötigte Pakete entfernen

Fazit

Web Security sollte von Anfang an Teil jedes Projekts sein und nicht erst dann, wenn etwas schiefgeht.

Die drei wichtigsten Schwachstellen, die jeder Entwickler kennen sollte, sind:

• Cross-Site Scripting (XSS)
• Cross-Site Request Forgery (CSRF)
• SQL Injection

Wer diese drei Angriffe versteht und die passenden Schutzmaßnahmen umsetzt, hat bereits einen großen Schritt in Richtung sicherer Webanwendungen gemacht.

Auch kleine Projekte profitieren von guten Sicherheitspraktiken – und oft sind es nur wenige zusätzliche Zeilen Code, die große Probleme verhindern können.