SESSION 04 / 06
F12 drücken
und alles sehen
F12 · 6 Schutzmaßnahmen · Sicherheitsaudit · account.md
Jee Jun Young
BWL statt Informatik → Journalismus · Auslandsvertrieb → Wechsel in die Entwicklung
iOS · Android · Frontend Etwa 5½ Jahre (im sechsten Jahr)
Entwicklung von iOS-/macOS-Apps für ein Kollaborationstool eines Großunternehmens
Seit 2026 Web- und Serverentwicklung sowie Vermarktung als Einzelentwickler mit Vibe Coding
TEIL 1 — Rückblick auf Einheit 3
Heute sprechen wir über
etwas Beängstigendes.
WHY WEB IS WILD
Web und Server sind Wildnis
Auch ich habe Respekt vor Sicherheitsleuten. Ich bin kein Sicherheitsexperte.
Mobil vs. Web — unterschiedliche Verantwortungsbereiche für Entwickler
Sandbox · Code Signing · ATS · Keychain · App-Store-Prüfung — Basissicherheit durch Betriebssystem und Plattform
HTTPS · CORS · CSRF · XSS · SQL Injection · DDoS · Server-OS · Authentifizierung und Berechtigungen — alles selbst
Das Web ist das Gebiet, auf dem KI am meisten trainiert wurde
Anmeldung, Foren, Dashboards — der Mittelwert der Trainingsverteilung. Stark darin, Funktionen zum Laufen zu bringen.
Randfälle, ungewöhnliche Eingaben, Sonderbedingungen. Der wissenschaftliche Begriff: adversarial robustness
Kümmern Sie sich darum, läuft es gut. Vernachlässigen Sie es, geht es schief.
Die heutigen 6 Schutzmaßnahmen sind das notwendige Minimum.
RANDFALL · Zahlungen
Ein Paradebeispiel weit außerhalb des Durchschnitts: Zahlungen einbauen
„In 5 Minuten fertig? Nach dem Tutorial hat es doch funktioniert?“
Versuchen Sie es. Ohne Umsatz merken Sie womöglich nichts, schließen den Betrieb und begraben das Thema.
Wenn der Umsatz steigt und Sie zum Ziel werden — dann merken Sie es.
Zahlungen sind die komplexeste Funktion: zahllose Abläufe und Verzweigungen stapeln sich Schicht um Schicht.
Diese Schichten dürfen sich nicht widersprechen. Randfälle, die durchschnittlicher KI-Code kaum behandelt, nehmen explosionsartig zu.
Warum das Angst macht — zwei bekannte Beispiele
• iOS-In-App-Käufe — das Gebiet, das Spielefirmen früher quälte. Apples 30% Gebühr, automatische Verlängerung, Erstattungen, Belegprüfung …
• Kundendienst kleiner Unternehmen — bei Zahlungsproblemen trifft Sie der Kundenärger direkt. „Wo ist mein Geld?“ Beschimpfungen, eine Flut von 1-Stern-Bewertungen, der Ruf in einem Monat zerstört.
Was mich als Dozenten beschäftigt
Zahlungen — was mich derzeit am meisten beschäftigt
Ich habe Ihnen im Kurs mehrmals meinen Dienst zum Veröffentlichen von Romanen gezeigt, oder?
Genau das beschäftigt mich derzeit am meisten —
die Angriffspunkte der Zahlungsfunktion absichern.
F12 · DEVTOOLS
F12 ist das Röntgengerät des Browsers.
In Chrome: auf einer beliebigen Seite Rechtsklick → Untersuchen.
Oder Claude fragen: „Habe ich Windows oder Mac? Wie öffne ich die Webentwicklertools?“
Was der Network-Tab zeigt
API-Pfade, Anfrage- und Antwortinhalte
Verwendetes KI-Modell, Umgebungsvariablen, localStorage, Cookies
Alles öffentlich sichtbar.
Dass man beim Röntgen Knochen sieht, ist normal.
Auf dem eigenen Computer nachzusehen, ist ebenfalls kein Hacken.
Das Problem: Jeder kann es öffnen.
Der Browser unterscheidet nicht zwischen Entwicklern und Hackern.
TWO RISKS
Zwei Gründe, warum Sichtbarkeit per F12 gefährlich ist
Direkte Folgen für Sicherheit und Geld.
Gleich folgen 3 Vorfälle als Beleg.
Ihr Kernrezept liegt vollständig offen.
Ein Konkurrent kopiert es an einem Wochenende.
Bei F12 geht es um den Schutz Ihrer Nutzer und zugleich
den Schutz Ihrer Ideen.
ANALOGY
Echte Sicherheit heißt: „Können sie es mitnehmen?“
Das Beispiel mit der Schublade
Im eigenen Zimmer das eigene Tagebuch herauszunehmen, ist kein Vorfall.
Der echte Vorfall ist, einen Dieb durchs Fenster einbrechen und es stehlen zu lassen.
Freizeitpark-Armband — der Aufbewahrungsort entscheidet
Dasselbe Armband ist je nach Aufbewahrungsort anders geschützt.
Der „Dieb“ ist ein XSS-Angreifer
Jemand hat schädliches JavaScript in die Seite eingeschleust (Cross-Site Scripting).
JavaScript derselben Domain kann localStorage vollständig lesen → das Schadskript stiehlt den Token.
HttpOnly-Cookies sind für JavaScript unsichtbar → es kann sie nicht stehlen. Die Aufgabe von HttpOnly: Token-Diebstahl auch bei XSS verhindern.
PART 2
Ein 10-Sekunden-Angriff
3 echte Vorfälle
Ein Hacker braucht keine
10 Sekunden, um die Website eines Einzelentwicklers auszunehmen.
INCIDENT 01
EnrichLead — 2 Tage angegriffen, nach 1 Woche geschlossen
Das Problem: Alle 4 grundlegenden Schutzmaßnahmen fehlten
Ein B2B-Lead-SaaS, dessen Gründer prahlte: „Ich habe keine einzige Zeile geschrieben.“
API-Schlüssel im Frontend offengelegt, keine Authentifizierung, ungeschützte Datenbank, keine Ratenbegrenzung.
Angriffsweg
Zahlung über die Browserkonsole umgangen → kostenpflichtige Funktionen gratis genutzt → API-Kontingent aufgebraucht.
Reparatur mit Cursor versucht → „Es machte ständig andere Teile kaputt“ → aufgegeben und geschlossen.
SCHLÜSSELTYPEN · Zwei Arten unterscheiden
apiKey · Google Maps · Stripe pk_* · Supabase anon→ Einschränkungen und Richtlinien (Security Rules, App Check, Restrictions) immer aktivieren.
sk-ant-* · OpenAI sk-* · Stripe sk_* · Supabase service_role→ Immer in Backend-Umgebungsvariablen.
Selbsttest: „Kann bei Offenlegung jeder den Dienst aufrufen, Kosten verursachen oder Rechte erhalten?“ JA → geheim. NEIN → öffentlich.
Lehre: Geheime Schlüssel sicher aufbewahren.
Bei Web-/Serversystemen in Backend-Umgebungsvariablen isolieren. iOS-/Android-Apps rufen über das eigene Backend auf. Öffentliche Schlüssel dürfen eingebettet werden, aber nur mit Richtlinien.
INCIDENT 02
Moltbook — 1,5 Millionen API-Schlüssel geleakt
Ablauf: zwei Fehler zugleich
Eine soziale Plattform für KI-Agenten, deren Gründer Matt Schlicht erklärte: „Ich habe keine einzige Zeile geschrieben.“
Auf Supabase: RLS ausgeschaltet + privilegierter Schlüssel im Client-JavaScript sichtbar.
→ Der anon-Schlüssel selbst darf öffentlich sein. Ursache war die Kombination aus deaktivierter RLS und offengelegtem Geheimschlüssel.
Ergebnis: 1,5 Millionen API-Schlüssel, 35.000 E-Mail-Adressen und sämtliche privaten Agentengespräche offengelegt.
Die Sicherheitsfirma Wiz Research veröffentlichte ihre Untersuchung.
Lehre: Supabase RLS und Firebase Security Rules immer einschalten.
Claude jedes Mal prüfen lassen.
INCIDENT 03
Tea-App — 72.000 Bilder und 1,1 Millionen Nachrichten
Erstes Leck (Juli 2025)
Eine App nur für Frauen, die bei Registrierung Führerscheine und Selfies sammelte.
Firebase Storage blieb für jeden zugänglich.
72.000 Bilder wurden offengelegt, darunter rund 13.000 Selfies einschließlich Führerscheinaufnahmen.
Zweites Leck (wenige Tage später)
Weitere 1,1 Millionen private Nachrichten wurden offengelegt.
Darunter höchst sensible Gespräche über Abtreibung und Affären.
Lehre: Bei Datei-Uploads
immer die Storage-Berechtigungen prüfen.
KBS Chang, Folge 540 · Zwei wichtige Abschnitte
Die Sendung zeigt nur das fertige Ergebnis
„Meine perfekte Assistenz: Das Zeitalter der KI-Agenten“ · youtu.be/QQJpyIO014A
Fall ① · Beginn des Videos — Hauptperson der Dokumentation
CEO eines Sicherheits-Startups · Lebt auf Bali · Arbeitet 30 Minuten am Tag · Gibt nur Agentenergebnisse frei
Vier Dinge auf dem Weg dorthin, über die wir nur mutmaßen können:
（Zum Vergleich: Manche Firmen zahlen für Palantir Enterprise über 20 Millionen Won im Monat.）
Fall ② · Minute 28–32
Ein Hotelbuchungsagent sollte „nur 500.000 Won ausgeben“ und landete bei 760.000 Won.
Ein kontrolliertes Angriffsexperiment von KAIST-Forschern und KBS-Mitarbeitern. Feindlicher Code und Prompts auf einer externen Webseite bringen den Agenten im Szenario zu Fehlhandlungen. Kein echtes Opfer.
Mein Hintergrund: Zeitschriftenreporter (am ersten Kurstag vorgestellt). Wie Medien wirken, ist das Ergebnis redaktioneller Absichten.
Zu Hause ansehen und zwei Dinge prüfen:
① Mühe, Lernen, Fehlversuche und Kosten des CEOs — sieht man sie?
② Der Angriffsmechanismus (Attention, Tool Calling, Urteilsbildung, IDPI) — wird er klar erklärt?
Falls nicht: Es wurde herausgeschnitten. So funktionieren Medien.
Die entscheidende Frage:
„Ist mein Dienst darauf vorbereitet, diesen Angriff abzuwehren?“
PART 3
Grundlegende Schutzmaßnahmen:
6 Stück
Nicht auswendig lernen. Fotografieren Sie es.
Entscheidend ist ein Zusatz an Claude: „Das bitte auch.“
TODAY · 6 BASIC DEFENSES
Die 6 grundlegenden Schutzmaßnahmen im Überblick
Für jede Datenbankzeile den Eigentümer kennzeichnen → nur eigene Zeilen lesen und schreiben.
Beispiel: „Meine Beiträge sehe nur ich, fremde nicht.“
Supabase/Firebase standardmäßig AUS — ohne Aktivierung kann jeder auf alle Zeilen zugreifen.
Ein fest codierter Schlüssel ist beim Hochladen zu GitHub weltweit sichtbar. In .env auslagern.
Schlüssel mit NEXT_PUBLIC_, VITE_ oder REACT_APP_ werden ins Bundle eingebaut und im Browser sichtbar.
OpenAI-/Anthropic-Schlüssel im Client (Browser/App) einzubauen und dort aufzurufen, führt sofort zum Diebstahl. BFF/API-Proxy-Muster nutzen.
Liegen in Produktion .map-Dateien offen, lässt sich verschleierter Code zum Original rekonstruieren. productionBrowserSourceMaps: false
Wird .env versehentlich committet, sammeln Bots die Schlüssel automatisch innerhalb von 30 Minuten nach dem Push.
Diese sechs gehen wir einzeln durch.
IF YOU SKIP — WORST CASE
Was passiert, wenn Sie alle 6 auslassen?
API-Schlüssel offengelegt → Bots sammeln ihn binnen 30 Minuten → OpenAI-/AWS-Rechnungen explodieren.
Zig bis Hunderte Millionen Won in einem Monat sind möglich.
Verstoß gegen Koreas Datenschutzgesetz → Geldbuße bis zu 3% des Umsatzes plus Schadenersatz je Opfer.
Eine Sammelklage kann auch den Inhaber eines Kleinbetriebs persönlich in die Insolvenz treiben.
Ransomware verschlüsselt die Datenbank → fordert Lösegeld in Bitcoin.
Ohne Backup endet der Betrieb. Durchschnittliches Lösegeld weltweit: 800.000–1,5 Millionen US-Dollar.
Eine Flut von 1-Stern-Bewertungen und Bloßstellung auf X (Twitter) → Vertrauen lässt sich in einem Monat nicht wiederherstellen.
„Die Seite hatte einen Zahlungszwischenfall“ — ein Satz kann Umsatz 0 bedeuten.
Diese vier Folgen können schon bei einer fehlenden der 6 Schutzmaßnahmen eintreten.
Ruin. Keine Übertreibung. Jede Woche gibt es echte Fälle.
RLS-Richtlinien und tatsächliche Zugriffsrechte jeder Tabelle gemeinsam prüfen.
RLS, einfach erklärt
Was ist RLS? Briefkästen im Wohnhaus
Vergleich
Im Erdgeschoss stehen Briefkästen für 100 Wohnungen.
„Nur ich kann meinen Briefkasten öffnen“ — so gehört es sich.
→ RLS eingeschaltet = normal
Was passiert ohne Aktivierung?
Jeder Bewohner kann alle 100 Briefkästen öffnen.
Kontoauszüge, Kartenrechnungen und Einschreiben der Nachbarn sind lesbar.
→ Supabase/Firebase standardmäßig AUS. Ohne Aktivierung kann jeder alle Nutzerdaten lesen und ändern.
RLS = „Nur der Eigentümer darf diese Datenzeile öffnen.“
Kurz: Jeder Briefkasten bekommt ein Schloss.
Bei Vercel oder Netlify in die Umgebungsvariablen-Felder des Dashboards eintragen.
API-Schlüssel, einfach erklärt
Was ist ein geheimer API-Schlüssel? Ein Hotel-Generalschlüssel
Vergleich (nur für geheime Schlüssel)
Der Generalschlüssel eines Hotelmitarbeiters öffnet jedes Zimmer.
Geheime Schlüssel von OpenAI, Anthropic und AWS funktionieren ebenso. „Mit diesem Schlüssel können Sie die Dienste der Firma nach Belieben nutzen.“
→ Bezahlt wird vom Schlüsselinhaber: Ihnen. Öffentliche Schlüssel sind anders; siehe S10.
Was passiert, wenn er im Code steht?
Als hinge der Hotel-Generalschlüssel ungesichert am Haupteingang.
Jeder Passant kann ihn nehmen, alle Zimmer öffnen und Minibars und Tresore plündern.
→ Auf GitHub sammeln Bots den Schlüssel binnen 30 Minuten → OpenAI-Rechnungen explodieren, zig bis Hunderte Millionen Won in einem Monat.
Nicht in den Code schreiben, sondern in eine eigene Datei namens .env auslagern.
.env niemals in Git ablegen (nächste Folie).
Genau dieser Fehler führte zum EnrichLead-Vorfall.
Andere Frameworks haben dieselbe Regel: VITE_ (Vite), REACT_APP_ (CRA). Andere Namen, dieselbe Sichtbarkeit im Client.
Bei öffentlichen Schlüsseln ist das Präfix erlaubt
Öffentliche Schlüssel wie Firebase apiKey, Stripe pk_* und Supabase anon dürfen NEXT_PUBLIC_* oder VITE_* verwenden. Sie sind ohnehin zur Veröffentlichung gedacht.
→ Niemals bei geheimen Schlüsseln. Siehe S10.
NEXT_PUBLIC_, einfach erklärt
Was ist NEXT_PUBLIC_? Ladenschild oder Tresor des Inhabers
Vergleich
Ein Laden hat zwei Arten von Schrift.
Das Schild sieht jeder Passant (Telefon, Adresse, Speisekarte).
Den Tresorinhalt sehen nicht einmal Mitarbeiter (Bargeld, Stempel, Bankbücher).
→ Ein Schlüssel mit NEXT_PUBLIC_ ist Schrift auf dem Schild. Beim Build gelangt er direkt in den Browser.
Was, wenn es versehentlich vor einem geheimen Schlüssel steht?
Als schrieben Sie die Tresorkombination aufs Ladenschild.
Bei geheimen Schlüsseln wie OpenAI sk-* oder Supabase service_role genügt NEXT_PUBLIC_, und ein Druck auf F12 liefert sie dem Dieb.
→ VITE_ und REACT_APP_ funktionieren ebenso: dieselbe Falle in anderen Frameworks.
Regel: Das Präfix bedeutet „gelangt zum Client“.
→ Hier nur öffentliche Schlüssel (Firebase apiKey, Supabase anon, Stripe pk_*). Niemals geheime: Sonst steht die Tresorkombination auf dem Schild.
Claude immer sagen: „Rufe es über eine serverseitige API-Route auf.“
PLATTFORM · Umsetzung je Plattform
/api/*; bei Vite separat Express, Hono oder Vercel Functions). Schlüssel in Backend-Umgebungsvariablen.→ Gemeinsames Prinzip: Geheime Schlüssel (OpenAI, Anthropic, Stripe `sk_*`, Supabase service_role usw.) nur im eigenen Backend verwenden. Nutzer-Authentifizierungstokens (JWT/OAuth) gehören in OS-Keychain/Keystore. Diese drei Typen sind verschieden.
Häufige Verwechslung: „Firebase sagt doch, ich soll den Schlüssel in Info.plist eintragen?“
Richtig. Firebase apiKey ist ein öffentlicher Schlüssel ohne eigene Berechtigungen und darf in die App.
Die eigentliche Abwehr bilden Firebase Security Rules und App Check. Google-Maps-Schlüssel, Stripe `pk_*` und Supabase `anon` sind ähnlich.
→ Denken Sie an die Tabelle in S10. Geheime Schlüssel ins Backend; öffentliche dürfen in Apps, aber Richtlinien müssen aktiv sein.
BFF, einfach erklärt
Was ist BFF? Gast / Mitarbeiter / Inhaber
Vergleich: ein Restaurant
Gast = Nutzer (Browser)
Mitarbeiter = Ihr Server (BFF, Backend For Frontend)
Inhaber = externe API (OpenAI, Bank, Zahlungen)
→ Gäste dürfen nicht direkt ins Büro zum Tresor. Der Mitarbeiter nimmt ihren Wunsch entgegen und trägt ihn zum Inhaber.
Was, wenn der Gast direkt zum Inhaber geht?
Der Gast erfährt die Tresorkombination (API-Schlüssel).
Danach kommt er täglich als anderer Gast getarnt zurück und plündert den Tresor.
→ OpenAI/Banken direkt vom Client aufrufen legt Schlüssel offen. Bots sammeln sie, Rechnungen explodieren.
Regel: Gäste sprechen nur mit dem Mitarbeiter. Er vermittelt zum Inhaber.
Also KI-, Zahlungs- und Datenbankaufrufe immer über Ihren Server (BFF), nicht vom Client.
Was ist eine Source Map?
Ihr Code (TS, JSX, modernes JS) → das Build-Werkzeug führt eine vierstufige Umwandlung mit Komprimierung, Übersetzung und Bündelung durch → sendet ihn an den Browser. Den umgewandelten Code kann ein Mensch nicht lesen.
Zum Debuggen erstellt der Build eine Zuordnungstabelle zwischen Original und komprimiertem Code. Das ist die .map-Datei, die Source Map.
Vergleich: eine Zuordnungstabelle zur englischen Übersetzung eines koreanischen Buchs. Bei einem Tippfehler findet man damit die koreanische Originalstelle.
Dieselbe Funktion: Original und Build-Ergebnis (vom Menschen geschrieben, an den Browser geliefert)
Mit aktiven Source Maps zeigt F12 das Original links unverändert: Funktion, Geschäftslogik und Kommentare.
SCHUTZ 05 · Einstellungen und Gründe für Offenlegung
Source Maps: eine Einstellungszeile — und andere Firmen?
Fälle öffentlich zugänglicher Source Maps
Build-Einstellungen wurden nicht geprüft
②Veröffentlichung des Client-Codes wurde erlaubt
③Produktionsfehler werden anhand des Originalcodes verfolgt
④Code wurde als Open Source veröffentlicht
⑤Kernlogik liegt auf dem Server
Prüfen Sie, ob Ihr Projekt Originalcode, Kommentare oder Kernlogik offenlegt.
Claude fragen: „Prüfe, ob der Produktionsbuild dieses Projekts Source Maps offenlegt.“
FORTGESCHRITTEN · Erweiterte Option
hidden-source-map: Standardmuster für Sicherheit und Debugging
Zwei Optionen zur Auswahl
① Ganz abschalten (`sourcemap: false`): am sichersten, aber Produktionsfehler sind schwerer nachzuverfolgen.
② hidden-source-map: Maps erzeugen, aber keinen sourceMappingURL-Kommentar einfügen. Normale Nutzer sehen sie nicht in F12.
So funktioniert hidden-source-map
Erzeugte .map-Dateien nicht mit dem Server ausliefern, sondern getrennt bei Sentry, Datadog oder einem ähnlichen Fehlerdienst hochladen.
→ Produktionsfehler sind im Sentry-Dashboard bis zur Originalzeile nachvollziehbar, aber nicht über F12 sichtbar.
Optionen je Framework
Next.js — productionBrowserSourceMaps: false + Sentry-Anbindung
Vite — build.sourcemap: 'hidden'
Webpack — devtool: 'hidden-source-map'
CRA — GENERATE_SOURCEMAP=false (CRA unterstützt hidden nicht)
Kurz: Ganz abschalten ist am sichersten, hidden verbindet Sicherheit und Debugging.
Mit wachsender Größe und dem Einsatz von Sentry oder Datadog zu hidden wechseln.
Source Maps, einfach erklärt
Was ist eine Source Map? Ein Bauplan
Vergleich
Von außen erkennt man an einem fertigen Gebäude weder Lüftungsschächte noch Geheimgänge oder Tresore.
Erst der Bauplan zeigt, wo alles liegt.
→ Eine Source Map ordnet komprimierten und ursprünglichen Code zu. Damit zeigt F12 das Original.
Was passiert, wenn der Bauplan öffentlich ist?
Der Dieb kennt alle Lüftungsschächte, Geheimgänge und Tresororte.
Außen bleibt alles gleich, doch die Zugangswege werden zahllos.
→ Öffentliche .map-Dateien zeigen Geschäftslogik, Sicherheitsprüfungen und Kommentare. Schwächen sind sofort erkennbar.
Regel: Ist das Gebäude fertig, kommt der Bauplan in den Firmentresor. Nicht veröffentlichen.
Eine Zeile: productionBrowserSourceMaps: false.
Bei einem versehentlichen Commit bleibt es im Git-Verlauf.
Den Schlüssel sofort neu ausstellen.
Git, .gitignore und .env, einfach erklärt
Was ist Git? Ein Tagebuch-Backup
Vergleich
Git = automatisches Tagebuch-Backup (täglich fotografieren und in der Cloud speichern)
.env = geheimes Tagebuch (Passwörter, Bankcodes, Lästereien)
.gitignore = Liste „Nicht sichern“
→ Git lädt alle Dateien automatisch in die Cloud. Das geheime Tagebuch muss in .gitignore stehen, damit es nicht hochgeladen wird.
Was passiert ohne Eintrag in .gitignore?
Auch das geheime Tagebuch wird in der Cloud gesichert. Und bleibt dauerhaft im Verlauf. Einmal hochgeladen: Schlüssel sofort neu ausstellen.
→ Nach versehentlichem .env-Commit sammeln Bots die Schlüssel binnen 30 Minuten. AWS-/OpenAI-Rechnungen explodieren. Auch nach Löschen bleibt der Verlauf.
Regel: .env, .env.local und .env.*.local immer in .gitignore aufnehmen.
Der erste Schritt bei jedem neuen Projekt.
6 DEFENSES — CHECKLIST
Mit diesen sechs Punkten
offengelegte Schlüssel, Datenbankrechte und Dateizugriff prüfen.
SCHLÜSSELVERWALTUNG · Gesamtüberblick
Die vielen Schlüssel meines Dienstes — wie ordne und verwalte ich sie?
Ein Dienst: Supabase anon, Firebase apiKey, OpenAI sk-, Stripe pk_/sk_, Google Maps, Anthropic sk-ant- … 5–10 Schlüssel sind üblich.
Firebase apiKey · Google Maps · Stripe pk_* · Supabase anon
→ Zur Identifikation. Allein keine Rechte oder Kosten.
Anthropic sk-ant-* · OpenAI sk-* · Stripe sk_* · Supabase service_role
→ Nur Backend-Umgebungsvariablen.
Kurzer Selbsttest: „Muss ich bei Diebstahl zahlen? Kann meine Datenbank geknackt werden?“
JA → geheim. Nur Backend. | NEIN → öffentlich. Client erlaubt, aber zusätzliche Schutzmaßnahmen nötig.
Öffentliche Schlüssel absichern: zusätzliche Maßnahmen
Je Datenbankzeile/Dokument: „Dieser Nutzer darf nur auf eigene Daten zugreifen.“ Supabase RLS, Firebase Security Rules.
Application Restrictions: Google-Maps-Schlüssel nur von Ihrer Domain oder Bundle-ID aus aufrufbar. Andere Aufrufe werden abgewiesen.
Firebase App Check prüft, ob Aufrufe wirklich aus Ihrer App kommen. Blockiert Bots und Scraping.
Geheime Schlüssel immer in .env auslagern, in .gitignore eintragen und nur in Backend-Umgebungsvariablen halten.
Kurz: Öffentlicher Schlüssel + Richtlinien = sicher. Ohne Richtlinien = Desaster.
Mit dem Schlüssel allein ist Sicherheit nicht erledigt. Richtlinien einzuschalten ist die halbe Arbeit.
10 Minuten Pause
Nach der Pause
sprechen wir darüber, dass Claude vergisst.
PART 4
Claude vergisst
+ KI mit KI überwachen
HEUTE · Zwei weitere der 10 Prinzipien
In der zweiten Hälfte ergänzen wir 2 weitere der 10 Prinzipien.
Diese beiden behandeln wir in der zweiten Hälfte.
Zuerst Claudes Lüge „Ich habe es notiert“ und die Lösung mit account.md.
PART 4 — CLAUDE FORGETS
„Ich habe es notiert“ — glauben Sie es nicht.
Meine eigene Erfahrung
Ich sagte Claude: „Schreib das auf.“
Antwort: „Ja, ich habe es notiert.“
In der nächsten Sitzung gefragt: Keine Ahnung. Oft war tatsächlich nichts notiert worden.
Claude beginnt jede Sitzung von vorn.
Es hat kein Gedächtnis. Das hatten wir in Einheit 3.
Noch schlimmer
Manchmal erinnert es sich selbst innerhalb derselben Sitzung nicht an etwas von vor 2 Stunden.
→ Je länger der Kontext, desto unschärfer wird der Anfang. Genau die Context Rot aus Einheit 3.
Wenn Claude „notiert“ sagt, immer nachsehen.
Wichtiges schreiben Sie selbst auf.
Lösung: Der Mensch schreibt selbst mit
account.md (in .gitignore aufnehmen)
Aussteller der Schlüssel, Cloud-Konto-E-Mails, Infrastruktureinstellungen, Containernamen
Niemals Passwörter eintragen
Wachsende Regeln in eigene Datei auslagern
Lange Sicherheitsregeln nach SECURITY.md auslagern und in CLAUDE.md nur darauf verweisen.
→ Referenzmuster aus Einheit 3: CLAUDE.md kurz halten, Details auf Dateien verteilen.
Praktische Sicherheitsanwendung des Konzepts aus Einheit 3. Claude liest und berücksichtigt diese Regeln in jeder Sitzung.
PART 5
KI ein
Sicherheitsaudit durchführen lassen
Einheit 2: dokumentieren, überwachen, antreiben.
Bei Sicherheit ist Überwachung entscheidend.
AUDIT PROMPT
Sicherheitsaudit-Prompt: direkt kopieren
Claudes Auditbericht noch einmal an Gemini und Codex geben.
Prüft dieselbe KI den eigenen Code, heißt es: „Keine Probleme.“ Gemini kommentiert den Bericht oft hilfreich und schlägt nächste Schritte vor.
Entscheidend ist die Gegenprüfung.
Damit ist es nicht getan
Web und Backend müssen sich gegen enorm viele Dinge schützen.
Diese 6 sind ein Anfang. OWASP Top 10, Tokenspeicher, CSP, CORS, Rate Limits, SQL Injection, CSRF, SSRF, Race Conditions — die Liste geht weiter.
→ Die heutigen 6 werden beim Vibe Coding am häufigsten vergessen.
PRAXIS · Externe Prüfung kurz vor dem Kurs
Ein Schritt weiter: Prüfergebnisse aus externer Sicht
S36 dient der statischen Analyse des eigenen Codes. Hier geht es um externe Laufzeitprüfung anhand einer einzigen Seite (Tokenspeicher, Antwortheader, offene Pfade).
Ziel: koreanisches KI-Schreib-SaaS · Werkzeug: Claude Chrome MCP · Nur der Auftrag „Mach ein Sicherheitsaudit“ · Anonymisiert
① Authentifizierungstoken: in localStorage gespeichert
Schlüssel *_token, JWT-Format, 120 Zeichen.
→ Zentrales Antimuster aus Einheit 4. Jeder sieht den Token per F12.
② Token decodiert: 24 Stunden gültig
HS256; Payload nur sub und exp (iat, jti, iss, aud fehlen); Ablauf nach 24 Stunden.
→ Übliche Access-Tokens: 15 Minuten bis 1 Stunde. 24 Stunden ohne jti heißt nach Diebstahl nicht zwangsweise widerrufbar, 24 Stunden unbegrenzt nutzbar.
③ Sicherheits-Antwortheader: 5 fehlen
CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy und Permissions-Policy fehlen alle.
→ Nur HSTS ist aktiv. Eine CSP-Zeile hätte Inline-XSS-Skripte blockieren können — null Abwehrschichten.
④ Viele Drittanbieter + keine CSP = größere Angriffsfläche in der Lieferkette
GTM, GA und mehrere externe CDNs werden geladen. Keine CSP → bei kompromittierter Domain kann Schadcode alle Nutzer der Website erreichen.
Ein regulärer kostenpflichtiger Dienst läuft mit fast allen Antimustern aus Einheit 4.
Bisher nur noch nicht geknackt — aber sehr leicht angreifbar.
GENAUER · Präzise erklärt
① Nur die Tokenspeicherung in localStorage: diskutierbar
Tokenspeicherung gemeinsam mit CSP- und XSS-Schutz prüfen.
② Kombination (localStorage + keine CSP + 24h + kein jti) — gemeinsam zu prüfende Punkte
CSP, Token-Ablaufzeit und Schutz gegen Wiederverwendung gemeinsam prüfen.
③ Kurz gesagt
Sensible Werte (Authentifizierung, Zahlungen, Personenkennungen) niemals in localStorage.
Dunkelmodus, Sprache und UI-Zustand sind okay. Geheimnisse nicht.
④ Dieser Dienst
Liegt näher bei Kombination ②.
Nicht localStorage allein wird kritisiert: Die Kombination ist gefährlich.
ALSO — Wenigstens das Minimum
Darum müssen Sie wenigstens die grundlegende Sicherheit beachten
Erstens: Nicht Unvermögen, sondern Unterlassung
Mit Vite, React und Vercel sauber gebaut. Offensichtlich kluge Leute.
Nur eine 5-Minuten-Aufgabe ausgelassen: Authentifizierungstokens in HttpOnly-Cookies legen.
Zweitens: Selbst Billionen-Won-Firmen lassen es aus
EnrichLead, Moltbook, Tea — alle nahmen Zahlungen an.
Das Minimum fehlte, und ein Vorfall führte nach einer Woche zur Schließung (EnrichLead).
Drittens: Sie sind denselben Gefahren ausgesetzt
Sobald Sie beim Vibe Coding Zahlungen und Nutzer zulassen, zeigt ein Druck auf F12 alles.
Das Minimum: 6 Schutzmaßnahmen + account.md + Audit-Prompt.
Alle drei unbedingt. Ein einziger irreparabler Vorfall reicht zum Ende.
Noch ein letzter Satz
Mein ganzer Auftrag war auf Koreanisch: „Mach ein Sicherheitsaudit.“
Claude fand damit bereits all das.
Was, wenn ein versierter Angreifer dieselbe Seite ins Visier nimmt? Was dann?
TEST
Tests: Maschinen überwachen Maschinen
Unit-Tests, E2E-Tests, UI-Tests — jetzt nicht auswendig lernen.
Einfach gesagt: automatische Prüfprogramme.
Klassische Entwicklung: Entwickler schreiben sie.
Vibe Coding: Claude damit beauftragen.
Ein Satz: „Erstelle auch Testdateien für diese Funktion.“
MARTIN FOWLER · 1999
„Jeder Dummkopf
kann Code schreiben, den ein Computer versteht.
Gute Programmierer
schreiben Code, den Menschen verstehen.“
— Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.
『Refactoring: Improving the Design of Existing Code』 (1999)
Das wurde vor 27 Jahren gesagt.
Zurück zu Einheit 1: „Bücher / Experten nicht abwerten / auch Anthropic lernte aus Büchern.“
Dieser Mann ist ein Beispiel. Ein Gott der Softwarebranche.
Natürlich gibt es auch Dijkstra vom Dijkstra-Algorithmus und Liskov vom Liskovschen Substitutionsprinzip.
Genauer: ein Gott der Unternehmenspraxis, nicht der Theorie.
Andere Gebiete, aber ja: selbst nach tausend Jahren Programmierlernen unerreichbar.
2023–2025 — weiterhin aktiv
martinfowler.com · Betreibt die Reihe Exploring Generative AI.
Der Autor des Buchs von vor 27 Jahren schreibt weiter über Programmieren im KI-Zeitalter.
Anders gesagt: Auch Ihr Claude dürfte seine Texte gelernt haben.
Für das Vibe-Coding-Zeitalter abgewandelt:
„Jede KI schreibt Code, den Computer verstehen.
Gute Nutzer schreiben Code und Dokumente, die KI und Menschen verstehen.“
Das beginnt mit Grundlagen
und Begriffen, mit denen Entwickler arbeiten: Architektur, Entwurfsmuster, Codekomplexität.
F12, RLS, NEXT_PUBLIC_, Source Maps, BFF-Proxy, Rechteprüfung —
ohne diese Begriffe können Sie KI-Code nicht hinterfragen.
Wenn Claude „sicher“ sagt, fragen Sie:
„Ist RLS aktiv? Wird dieser Schlüssel dem Client offengelegt?“
Auch die Begriffe aus Einheit 5 werden Werkzeuge:
Clean Architecture, MVVM, FSD, Idempotenz, Atomarität, Entwurfsmuster …
Wer die Aufgaben aus Einheit 2 und 3 gemacht hat,
drückt heute F12 und merkt: „Ach, das ist alles sichtbar.“
Wer nie veröffentlicht hat, kennt es nur theoretisch.
Erst selbst sehen schafft ein Gefühl dafür.
PRINZIP 08 · Praxis
Der schnellste Weg zum Gespür: Bilder verfeinern
Einfacher als Code. Für jeden machbar.
Mit Bild-KI Illustrationen, Landschaften, Öl- und Aquarellbilder ausprobieren.
Mein Beispiel: seit dem Start der Gemini-App über 100 Bilder verfeinert. Das Emblem meiner Motorradgruppe selbst erstellt.
KI vergleichen: Das lernt man nur durch eigenes Verfeinern
„Könnte Duct Tape Nano Banana schlagen?“ Selbst vergleichen.
„Zu Codex wechseln? Codex nur für Reviews? Claude für die Arbeit?“
Mein Vergleich nach eigener Nutzung beider Modelle
Stark im Brainstorming. In langen Texten zeigen sich überzogene Gedankensprünge.
Stark bei Konkretisierung, Aufbau und logischer Konsistenz. Klug, aber ein Drückeberger, den man ständig antreiben muss.
Methoden zum Antreiben von KI: von Entwicklern intensiv erforscht
• Harness Engineering: der Oberbegriff. Wie gestaltet man die Arbeitsumgebung der KI?
• Agenten: autonome Einheiten darin. KI wählt Werkzeuge, plant und handelt selbstständig (Claude Code, Cursor Composer).
Teil derselben Forschungsrichtung. Mehr in Einheit 6.
10 PRINZIPIEN — 10/10 vollständig
Wir haben alle 10 Prinzipien behandelt.
Sie bilden das Gerüst des Kurses mit 6 Einheiten.
PART 6 — HOMEWORK
Die heutige Aufgabe
SESSION 04 / 06
Vielen Dank
für Ihre Arbeit heute.
Nächstes Mal: Einheit 5.
„Mach einfach“ funktioniert nicht — die Kraft technischer Begriffe.
Fragen bitte im offenen KakaoTalk-Chat.