Frontend-Sicherheit verstehen: Häufige Angriffe und ihre Abwehr, erklärt mit Animationen

Viele Frontend-Entwickler halten Sicherheit für „Sache des Backends”. In der Praxis passieren die meisten Angriffe aber im Browser: Ein bösartiges Skript läuft im Tab des Nutzers, der Browser schickt Cookies von sich aus mit, oder ein API-Schlüssel landet im Bundle und wird an jeden Besucher ausgeliefert.

Das hier sind meine Lernnotizen zur Frontend-Sicherheit. Ich habe die häufigsten Probleme als interaktive Animationen umgesetzt, und alle folgen derselben Struktur:

1. Fünf Schritte: Schritt für Schritt sehen, wie der Angriff abläuft, mit einer „Hacker-Sicht” pro Schritt, die erklärt, was der Angreifer gerade denkt.
2. Grundursache: warum das überhaupt möglich ist.
3. Die richtige Lösung: Code, den man tatsächlich einsetzen kann.

Starte mit diesem kleinen Pixel-Abenteuer: „Abenteuer starten” spielt alle Stages von vorn bis hinten ab, oder du springst unten direkt zu einer Stage. Jede Stage verlinkt ihre ganze Animation. (Die ganzen Animationen sind auf traditionellem Chinesisch; dieser Beitrag behandelt dieselben Inhalte auf Deutsch.)

So liest du diesen Beitrag: Jedes Thema hat einen Angriffsablauf, der von selbst abspielt. Danach den Schalter „🛡 Abwehr an” umlegen und sehen, an welcher Stelle der Angriff gestoppt wird. Sieben Themen haben zusätzlich ein Labor zum Ausprobieren, am Ende warten eine interaktive Checkliste und ein Quiz.

Zuerst ein Denkmodell: vier Arten von Problemen

Diese Probleme wirken verstreut, lassen sich aber auf vier Grundursachen zurückführen. Wer diese vier kennt, kann auch neue Schwachstellen leichter einordnen.

In einem Satz: Vertraue nichts, was vom Client kommt, und gib dem Client keine Geheimnisse.

A. Injection und Ausführung

01 XSS (Cross-Site Scripting)

Ein Kommentarfeld filtert die Eingabe nicht, und bösartiger Code läuft in den Browsern anderer Nutzer.

Grundursache: Der Server gibt Nutzereingaben unverändert als HTML aus, und der Browser kann „Inhalt” nicht von „Code” unterscheiden.

Die Lösung

function escapeHtml(str) {
  return str.replace(/[&<>"']/g, (c) => ({
    '&': '&amp;', '<': '&lt;', '>': '&gt;', '"': '&quot;', "'": '&#39;',
  }[c]));
}
res.send('<div>' + escapeHtml(comment) + '</div>');

Ergänzungen:

• Es gibt drei Arten von XSS: Stored (in der Datenbank gespeichert), Reflected (in einem URL-Parameter versteckt) und DOM-based (das Frontend-JS schreibt Daten selbst in innerHTML).
• React und Vue escapen {value}-Bindings standardmäßig. Gefährlich sind dangerouslySetInnerHTML, v-html, innerHTML und <a href={userInput}> (URLs, die mit javascript: beginnen, werden trotzdem ausgeführt).
• Wenn wirklich nutzergeneriertes HTML angezeigt werden muss (z. B. aus einem Rich-Text-Editor), mit einer Bibliothek wie DOMPurify bereinigen. Keine eigenen Regex schreiben.

03 Token-Speicherung: localStorage vs. httpOnly-Cookie

Dasselbe bösartige Skript, völlig unterschiedliche Ergebnisse, je nachdem wo der Token liegt.

Die ganze Animation ist ein direkter Vergleich. Bei derselben XSS-Lücke wird ein Token in localStorage mit einem einzigen localStorage.getItem('token') ausgelesen. Ein Token in einem httpOnly-Cookie ist für JavaScript überhaupt nicht lesbar.

Grundursache: localStorage steht jedem Skript auf der Seite offen. Eine einzige XSS-Lücke, und der Token ist weg.

Die Lösung

res.cookie('token', jwt, {
  httpOnly: true,    // für JS nicht lesbar
  secure: true,      // nur über HTTPS
  sameSite: 'strict' // nicht bei Cross-Site-Requests mitsenden (hilft auch gegen CSRF)
});

Ergänzung: httpOnly begrenzt den Schaden, verhindert aber kein XSS. Das Skript kann den Token nicht stehlen, aber während es läuft, trotzdem Requests im Namen des Nutzers senden. Deshalb gehört es immer zusammen mit XSS-Schutz und CSP. Und wer auf Cookies umsteigt, muss an CSRF denken (siehe 02).

14 CSP (Content Security Policy)

CSP ist die wirksamste zweite Verteidigungslinie gegen XSS, und viele Projekte setzen sie gar nicht.

Selbst wenn irgendwo das Escaping fehlt und ein bösartiges Skript auf die Seite gelangt, sagt CSP dem Browser: „Führe nur die Skripte aus, die ich erlaube, und verbinde dich nur mit den Domains, die ich erlaube.” Ohne CSP schränkt der Browser nicht ein, wohin Skripte Daten senden dürfen.

Die Lösung

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mBase64'

Ergänzungen:

• Für jede Response eine neue zufällige nonce erzeugen und an legitime <script nonce="...">-Tags hängen. Eingeschleuste Skripte haben keine Nonce und werden nicht ausgeführt.
• 'unsafe-inline' und 'unsafe-eval' vermeiden. Damit steht die Tür halb offen.
• Vor dem Livegang eine Weile als Content-Security-Policy-Report-Only laufen lassen, um sicherzugehen, dass keine echten Funktionen blockiert werden.
• connect-src beschränkt, wohin fetch sich verbinden darf. Selbst wenn ein Skript läuft, kommt es so kaum an Daten heraus.

B. Missbrauchtes Browser-Verhalten

02 CSRF (Cross-Site Request Forgery)

Anmeldedaten, die der Browser automatisch mitschickt, werden von einer anderen Seite für gefälschte Requests genutzt.

Grundursache: Der Server prüft nur „Gibt es ein Session-Cookie?”, aber nicht, ob der Nutzer den Request tatsächlich auf der Seite der Bank ausgelöst hat.

Die Lösung

// SameSite am Cookie setzen
res.cookie('session', token, { httpOnly: true, sameSite: 'strict', secure: true });

// Für kritische Aktionen zusätzlich einen zufälligen Token prüfen
app.post('/transfer', (req, res) => {
  if (req.body.csrfToken !== req.session.csrfToken) {
    return res.status(403).send('CSRF-Token stimmt nicht');
  }
  doTransfer(req.body);
});

Ergänzung: Moderne Browser verwenden standardmäßig SameSite=Lax, wenn nichts gesetzt ist. Das blockiert die meisten Cross-Site-POSTs. GET-Requests mit Seiteneffekten (z. B. GET /delete?id=1) sind aber weiterhin angreifbar. Die Regel: Nichts, was Daten ändert, über GET abwickeln, und auf dem Server den Origin-Header prüfen.

11 Zu großzügiges CORS

Access-Control-Allow-Origin: * öffnet jeder Website die Tür.

Grundursache: CORS dient dazu, die Same-Origin-Policy zu lockern. Ist es zu locker konfiguriert, kann jede Seite deine API im Namen des Nutzers auslesen.

Die Lösung: eine Allowlist statt einer Wildcard.

const allowedOrigins = ['https://yourapp.com', 'https://admin.yourapp.com'];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowedOrigins.includes(origin)) callback(null, true);
    else callback(new Error('Origin nicht erlaubt'));
  },
  credentials: true,
}));

Ergänzung (die Animation vereinfacht hier): Browser lehnen Allow-Origin: * in Kombination mit Allow-Credentials: true tatsächlich ab; diese Kombination wird direkt blockiert. Was in der Praxis wirklich zu Vorfällen führt, ist das unveränderte Zurückspiegeln des Origin-Headers zusammen mit credentials: true. Das wirkt wie eine Wildcard, und der Browser blockiert es nicht. Außerdem Vorsicht beim Erlauben des null-Origins und bei Prüfungen wie endsWith('yourapp.com'), die evil-yourapp.com bestehen würde.

12 Clickjacking

Der Button, den du siehst, und der Button, den du tatsächlich klickst, sind vielleicht nicht derselbe.

Grundursache: Die Seite schränkt nicht ein, ob andere Seiten sie per iframe einbetten dürfen.

Die Lösung

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

Ergänzung: frame-ancestors ist der moderne Standard, X-Frame-Options der Fallback für ältere Browser; beide zu setzen ist am sichersten. frame-ancestors funktioniert nur als HTTP-Header; in einem <meta>-Tag hat es keine Wirkung.

13 Open Redirect

Erst auf der echten Seite landen und Vertrauen aufbauen, dann unbemerkt woandershin geleitet werden.

Grundursache: Das Weiterleitungsziel vertraut einem vom Nutzer übergebenen Parameter vollständig.

Die Lösung: nur Pfade aus einer Allowlist zulassen.

const allowedPaths = ['/dashboard', '/profile', '/settings'];

app.get('/login', (req, res) => {
  const target = req.query.redirect;
  if (allowedPaths.includes(target)) return res.redirect(target);
  return res.redirect('/dashboard'); // alles Unbekannte geht zur Standardseite
});

Ergänzung: Ist keine Allowlist möglich, zumindest mit new URL(target, location.origin) parsen und den origin vergleichen. Nur zu prüfen, „beginnt es mit /”, reicht nicht: Browser behandeln sowohl //evil.com als auch /\evil.com als externe URLs.

C. Vertrauensgrenze an der falschen Stelle

04 Autorisierung nur im Frontend geprüft

Einen Button zu verstecken, macht nichts sicher.

Grundursache: Die Berechtigungsprüfung existiert nur im Frontend, und das Backend vertraut jedem Request.

Die Lösung

app.delete('/api/users/:id', requireAuth, (req, res) => {
  if (req.user.role !== 'admin') return res.status(403).send('Keine Berechtigung');
  deleteUser(req.params.id);
});

Ergänzung: Neben „Bist du Admin?” auch prüfen: „Gehört dieser Datensatz dir?“. Wer nur den Login und nicht die Eigentümerschaft prüft, zeigt fremde Daten an, sobald jemand die ID in der URL ändert. Das nennt sich IDOR (Insecure Direct Object Reference) und ist die häufigste Form von „Broken Access Control”, Platz eins der OWASP Top 10. Berechtigungsprüfungen im Frontend dienen nur der Nutzerfreundlichkeit.

07 Secrets hartcodiert im Frontend-Code

Alles, was an den Browser geht, kann jeder haben.

Grundursache: Frontend-Code wird vollständig an den Browser ausgeliefert, also ist jeder String darin faktisch öffentlich.

Die Lösung: Das Frontend ruft dein eigenes Backend auf, und der Schlüssel bleibt in einer Umgebungsvariable auf dem Server.

// ✅ Frontend
fetch('/api/ask');

// ✅ Backend
app.get('/api/ask', async (req, res) => {
  const r = await fetch('https://api.openai.com/v1/...', {
    headers: { Authorization: `Bearer ${process.env.OPENAI_KEY}` },
  });
  res.json(await r.json());
});

Ergänzungen:

• Umgebungsvariablen mit dem Präfix VITE_, NEXT_PUBLIC_ oder PUBLIC_ landen im Frontend-Bundle und dürfen nie Secrets enthalten.
• Manche Schlüssel sind bewusst öffentlich (Stripe Publishable Key, Firebase-Config). Ihre Sicherheit beruht auf Backend-Regeln und Domain-Einschränkungen.
• Ist ein Schlüssel einmal geleakt, hilft Löschen aus dem Code nicht, denn er steht noch in der Git-Historie. Sofort widerrufen und neu ausstellen.

08 Sensible Daten in Console-Logs

Ein vergessenes Debug-Log wird in Produktion zum öffentlichen Datenfenster.

Ein console.log('user data:', userData) aus der Entwicklung bleibt drin und wird ausgeliefert. Wer die Console öffnet, sieht persönliche Daten, Rollen und interne Notizen und kann daraus die Datenstruktur des Backends ableiten, als Hinweis für den nächsten Angriff.

Grundursache: Debug-Ausgaben passen sich nicht an die Umgebung an.

Die Lösung: beim Build automatisch entfernen.

// webpack (Terser)
optimization: {
  minimizer: [new TerserPlugin({
    terserOptions: { compress: { drop_console: true } },
  })],
}

// Vite (esbuild)
export default defineConfig({
  esbuild: { drop: ['console', 'debugger'] },
});

Ergänzung: Besser als nachträgliches Entfernen ist ein Logger mit Log-Leveln (Debug-Ausgaben nur in der Entwicklung) plus die ESLint-Regel no-console, die es schon vor dem Code-Review abfängt.

09 Source Maps legen den Originalcode offen

Der Code sieht minifiziert und verschleiert aus, aber eine einzige .map-Datei stellt ihn komplett wieder her.

Grundursache: Eine .map-Datei ist eine vollständige Zuordnungstabelle zwischen Original- und minifiziertem Code.

Die Lösung

// webpack
module.exports = {
  devtool: process.env.NODE_ENV === 'production' ? false : 'source-map',
};

// Vite (false ist bereits der Standard)
export default defineConfig({ build: { sourcemap: false } });

Ergänzung: Wer in einem Error-Tracker wie Sentry die Originalzeilen braucht, erzeugt Source Maps mit 'hidden' (ohne Verweis im JS), lädt sie zum Error-Tracker hoch und löscht sie aus den deployten Dateien. Und nicht vergessen: Auch ohne Source Maps lässt sich Frontend-Code lesen. Sicherheit nicht darauf aufbauen, dass „es eh keiner versteht”.

D. Lieferkette und Transport

05 Supply-Chain-Angriffe über Drittanbieter-Pakete

Das Paket, dem du vertraust, hängt vielleicht von einem Paket ab, das du nicht kennst und das bereits kompromittiert ist.

Grundursache: Das Projekt vertraut der gesamten Abhängigkeitskette, kann aber nicht jedes Update jeder Ebene prüfen.

Die Lösung

# Exakt nach Lockfile installieren, keine automatischen Versionssprünge
npm ci

# Automatischer Scan in der CI
npm audit
# Oder GitHub Dependabot aktivieren (.github/dependabot.yml), der automatisch Fix-PRs öffnet

Ergänzung: Das Lockfile immer committen. Vor dem Hinzufügen eines Pakets Downloadzahlen, Wartungsstatus und Anzahl der Abhängigkeiten prüfen. npm install --ignore-scripts in Betracht ziehen, damit postinstall-Skripte nicht schon bei der Installation laufen. Echte Vorfälle wie event-stream (2018) und ua-parser-js (2021) folgten genau diesem Muster.

06 CDN-Ressourcen ohne SRI

Wird ein CDN kompromittiert und eine Datei ausgetauscht, ist SRI die letzte Verteidigungslinie.

Die ganze Animation ist ein direkter Vergleich. Dieselbe Datei auf dem CDN wird ersetzt. Die Seite ohne integrity übernimmt sie einfach. Bei der Seite mit SRI erkennt der Browser, dass der Hash nicht passt, und verweigert die Ausführung.

Grundursache: Ohne das integrity-Attribut prüft der Browser den Inhalt der Datei nicht.

Die Lösung

<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-..."
  crossorigin="anonymous">
</script>

Ergänzung: Den Hash erzeugt man so:

openssl dgst -sha384 -binary lib.js | openssl base64 -A

crossorigin="anonymous" ist Pflicht, sonst kann der Browser nicht prüfen. SRI funktioniert nur für Dateien mit fester Version. Für lib@latest oder Ressourcen, die je nach Browser unterschiedliche Inhalte liefern, klappt es nicht; dann ist es besser, die Datei herunterzuladen und selbst zu hosten.

10 Kein erzwungenes HTTPS / Mixed Content

Die Seite selbst ist verschlüsselt, aber eine einzige unverschlüsselte Ressource kann abgefangen werden.

Grundursache: Geht auch nur eine Ressource über HTTP, wird genau diese Ressource völlig unverschlüsselt übertragen.

Die Lösung

Content-Security-Policy: upgrade-insecure-requests
Strict-Transport-Security: max-age=31536000; includeSubDomains

Ergänzung: upgrade-insecure-requests stuft http://-Requests auf der Seite automatisch auf https:// hoch. Strict-Transport-Security (HSTS) sorgt dafür, dass sich der Browser „diese Seite nur über HTTPS” merkt, sodass selbst ein beim ersten Mal getipptes http:// über HTTPS geht. Moderne Browser blockieren gemischte Skripte direkt, aber die eigentliche Lösung bleibt, alle Ressourcen-URLs auf https:// umzustellen.

Zusammenfassung: alle Probleme in einer Tabelle

Checkliste vor dem Livegang

Spickzettel: Security-Header

Die oben genannten Header an einem Ort. Die meisten lassen sich direkt in die Server- oder CDN-Konfiguration übernehmen:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; frame-ancestors 'none'; upgrade-insecure-requests
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Danach mit securityheaders.com oder dem Mozilla Observatory prüfen.

Quiz

Fertig gelesen? Teste dich an sieben echten Szenarien: Erkennst du den Angriff an seinen Symptomen?

Fazit

Meine wichtigste Erkenntnis aus diesen Problemen: Frontend-Sicherheit ist kein Haufen unzusammenhängender Tricks, sondern ein paar Prinzipien, die immer wiederkehren.

• Was der Nutzer hereinschickt, ist nicht vertrauenswürdig (XSS, Open Redirect, Frontend-Autorisierung).
• Was an den Nutzer geht, ist öffentlich (Schlüssel, Console-Logs, Source Maps).
• Die Komfortfunktionen des Browsers sind auch für Angreifer bequem (CSRF, CORS, Clickjacking).
• Jede Ebene sollte davon ausgehen, dass die vorherige versagen kann (httpOnly, CSP und SRI sind alles Defense in Depth).

Wer das systematischer lernen möchte, startet am besten mit den OWASP Top 10 und MDN Web Security. Oder einfach zurück zur Animationsübersicht oben, eine auswählen und aus Sicht des Angreifers durchspielen.