azena secure
Du verstehst die häufigsten Angriffsklassen auf moderne Web-Apps (XSS, IDOR, Injection, kaputte Auth) und kannst sie verhindern — Auth & Sessions richtig, Secrets sicher, Webhooks & Deploys gehärtet — und nutzt Claude als gründlichen Security-Review-Partner.
Was du danach kannst
- Die OWASP-Top-Risiken (XSS, IDOR/Broken Access, Injection, CSRF) erkennen & verhindern
- Auth & Sessions sicher umsetzen (Hashing, Token, httpOnly+SameSite-Cookies, RLS)
- Den Browser per Security-Header & CSP zum Verbündeten machen
- APIs & Datei-Uploads härten (Scopes, Validierung, Typ/Größe, sicherer Ablageort)
- Secrets sauber verwalten — nie im Client, nie im Repo — und Webhooks verifizieren
- Sehen, wenn es brennt: Logging/Monitoring + Incident Response, plus KI-Security-Review
Das Curriculum
19 Lektionen · Schritt für Schritt
- 01
Das Angreifer-Mindset — Vertraue nie dem Client
9′Jede Eingabe ist potenziell feindlich. Sicherheit beginnt mit einer Haltung, nicht mit einem Tool.
- 02
XSS & Injection — wenn Eingaben zu Code werden
11′Wie fremde Daten zu ausgeführtem Code werden — und wie Escaping & Parametrisierung das stoppen.
- 03
Auth, Sessions & Broken Access Control (IDOR)
12′Passwörter, Tokens, Cookies — und der häufigste echte Bug: Zugriff auf fremde Daten über die ID.
- 04
Secrets, Webhooks & dein KI-Security-Review
10′Keys richtig verwahren, Webhooks verifizieren — und Claude als gründlichen Security-Reviewer einsetzen.
- 05
Brich es selbst — die Lücke sehen, dann schließen
12′Eine Lücke verstehst du erst, wenn du sie einmal selbst ausgelöst hast — in einer sicheren Übungsumgebung.
- 06
Threat Modeling — denk wie ein Angreifer (STRIDE)
12′Bevor du verteidigst, listest du systematisch auf, was schiefgehen kann — mit dem STRIDE-Raster.
- 07
Krypto-Grundlagen — Hashing, Verschlüsselung & Encoding
12′Die drei werden ständig verwechselt — der Unterschied entscheidet über Sicherheit.
- 08
Supply-Chain-Sicherheit — deine Abhängigkeiten sind Angriffsfläche
11′Der meiste Code in deiner App ist fremd. Genau da setzen moderne Angriffe an.
- 09
Slopsquatting — wenn die KI ein Paket erfindet, das es (noch) nicht gibt
9′Die KI-Variante des Typosquatting: Angreifer registrieren Paketnamen, die KI-Assistenten halluzinieren — dein `install` zieht dann Schadcode.
- 10
Rate-Limiting & Missbrauchsschutz
10′Auth allein reicht nicht — auch erlaubte Endpunkte muss man vor Massen-Missbrauch schützen.
- 11
CSRF & SameSite-Cookies — Anfragen, die im Namen des Nutzers feuern
11′Eine fremde Seite löst eine echte Aktion in deiner App aus — weil der Browser das Session-Cookie brav mitschickt.
- 12
Security-Header & CSP — die Schutzschicht aus dem Response-Header
11′Ein paar gut gesetzte HTTP-Header verwandeln den Browser selbst in deinen Verbündeten gegen XSS & Co.
- 13
Sichere Datei-Uploads — fremde Dateien sind fremder Code
11′Ein Upload-Feld nimmt im Zweifel alles an. Typ, Größe und Speicherort entscheiden, ob daraus ein Einfallstor wird.
- 14
API-Sicherheit — Auth, Scopes & Rate-Limits an der Schnittstelle
11′APIs werden direkt angesprochen, ohne deine UI. Jeder Endpunkt muss für sich allein sicher sein.
- 15
OWASP Top 10 als Landkarte — die häufigsten Risikoklassen im Überblick
10′Eine geteilte Sprache und Prioritätenliste für Web-Risiken — verbindet alles, was du in diesem Track gelernt hast.
- 16
Moderne Auth-Flows — OAuth 2.0, OIDC, SSO & MFA richtig einsetzen
12′Login selbst bauen ist gefährlich. Wie delegierte Identität (OAuth/OIDC), SSO und ein zweiter Faktor das Risiko senken.
- 17
Sicheres Session-Management — Lebensdauer, Refresh, Rotation, Logout-überall
11′Nach dem Login geht es weiter: Wie lange gilt eine Sitzung, wie wird sie erneuert — und wie killst du sie sofort, wenn ein Token geleakt ist?
- 18
Security-Audit & Pentest-Grundlagen mit KI — die eigene App systematisch angreifen lassen
12′Vom Einzelfund zum strukturierten Audit: Wie du mit KI deine eigene App methodisch durchleuchtest — und wo die Grenzen liegen.
- 19
Logging, Monitoring & Incident Response — wenn es doch passiert
10′Kein System ist unverwundbar. Ein Plan für den Ernstfall entscheidet über den Schaden.
Was du baust
Echte Artefakte, keine Theorie
IDOR in der eigenen App jagen
Ergebnis: Liste der geprüften Routen + mindestens ein konkreter Fix (Diff/Snippet) mit kurzer Begründung.
RLS-Policies aktivieren
Ergebnis: Die RLS-Migration (SQL) + ein kurzer Test-Nachweis, dass fremder Zugriff blockiert wird.
KI-Security-Review mit Checkliste
Ergebnis: Das priorisierte Review-Ergebnis + dein Plan, welche 1-2 Funde du zuerst fixt und warum.
Ein geleaktes Secret korrekt rotieren
Ergebnis: Deine Rotations-Checkliste + die eingerichtete Vorbeugung (z. B. .gitignore-Eintrag und aktiviertes Secret-Scanning).
Capstone: Threat-Model + Härtung einer App (break → fix)
Ergebnis: STRIDE-Tabelle + break→fix→verify einer Lücke + Rotations-Checkliste + die Top-3-Funde des KI-Reviews mit Fix-Plan.
Belege & Quellen
Jede Aussage ist belegt — echte, geprüfte Quellen statt Behauptungen.
Reinschnuppern
Gratis-VorschauGO vs. NO-GO — ein echtes Beispiel aus dem Track.
Wie der Track läuft
Mit Nova als Mentor
Dein KI-Mentor erklärt jedes Konzept, gibt dir fertige Claude-Code-Prompts und hilft bei jeder Frage.
Geprüftes Siegel
Erkläre Nova an einem Stück deiner eigenen App (oder einem realistischen Beispiel), welche Angriffsklasse hier am gefährlichsten wäre — XSS, Injection, IDOR oder kaputte Auth — und WARUM. Beschreibe die konkrete Gegenmaßnahme. Formuliere dann das gezielte Security-Review, das du Claude geben würdest: welche Angriffsklassen, welche Checkliste, und warum das besser ist als 'ist das sicher?'.
In deinem Tempo
Rund 198 Minuten Kerninhalt — plus deine eigenen Projekte. Jederzeit pausierbar.
Fehler, die du vermeidest
- Prüfungen nur im Frontend — der API-Call ist ungeschützt.
- Zugriff nur auf 'eingeloggt?' prüfen statt auf 'gehört das DIESEM Nutzer?' (IDOR).
- Secrets mit `NEXT_PUBLIC_` ausliefern oder `.env` ins Repo committen.
- SQL/HTML per String-Verkettung bauen statt parametrisieren/escapen.
- RLS in Supabase nicht aktivieren — Tabelle ohne Policy ist offen.
- Webhooks ungeprüft verarbeiten — gefakte Events vertrauen.
Bereit für azena secure?
250 Token · 19 Lektionen · von der KI geprüft.