Blog

Die unangenehme Wahrheit: Tests prüfen nur, was sie testen. Sie ersetzen keinen Audit. Konkret hatte ich drei Lücken übersehen:

1. Der echte Anthropic-API-Key stand im Klartext in der docker-compose.yml. Nicht im Git-Repo, aber jeder mit Server-Zugriff hätte ihn lesen können. Fix: Schlüssel in eine .env mit chmod 600, im Compose nur noch ${ANTHROPIC_API_KEY} referenziert. Gleiches gilt für das DB-Passwort.

2. XSS im Frontend. Der KI-Output (Kernaussage, Stichworte, Bewertung) wurde direkt per innerHTML in das Dashboard gerendert. Wenn ein User in seine simulierte E-Mail <script>-Tags einschmuggelt und Claude diese im extrahierten Text spiegelt – Code-Ausführung im Browser. Fix: eine winzige esc()-Funktion, die HTML-Sonderzeichen escapt, und konsequent vor jedem dynamischen Wert anwenden.

3. Keine Schutz-Header. Keine Content-Security-Policy, kein X-Frame-Options, kein X-Content-Type-Options, keine Referrer-Policy. Fix: eine FastAPI-Middleware, die alle vier auf jede Antwort setzt – fünf Zeilen Code.

Was ich daraus mitnehme: Security-Audit ist eine eigene Phase, kein Nebenprodukt grüner Tests. Tests sichern App-Logik ab – Deployment-Artefakte (Compose, .env, Workflows) und Frontend-Rendering müssen separat durchgesehen werden. Ich habe dafür jetzt eine eigene Memory-Regel angelegt: „Bandit/Tests grün ≠ sicher; docker-compose, .env, Frontend-XSS, HTTP-Header explizit prüfen."

Bonus-Lektion am gleichen Tag: Drei Push-Zyklen, weil ich nach jedem CI-Fehler einzeln gefixt habe statt vorher den Workflow + die Repo-Struktur einmal zu lesen. Auch das ist jetzt eine Memory-Regel. Manchmal ist die teuerste Zeit die, in der man sich für „schnell mal pushen" entscheidet.

Antwort: Ja, wenn man das E-Mail-System komplett simuliert. Die KI-Extraktion bleibt echt (Claude Haiku 4.5), alles andere – Versand, Posteingang, Antwort – passiert im Browser. Damit lässt sich der gesamte Workflow demonstrieren, ohne externe Abhängigkeiten.

Architektur: FastAPI + PostgreSQL im Docker-Container, fünf Tabellen (Umfragen, Teilnehmer, Zuordnung, Antworten, Seminar-Referenzen), ein einseitiges Vanilla-JS-Dashboard. Jede Umfrage bekommt eine ID im Format UMF-2026-001. Wer eine Antwort simuliert, gibt sie als „E-Mail" mit dieser ID im Betreff ein – das System parst die ID per Regex, schickt den Freitext an Claude und speichert das JSON-Resultat als JSONB.

Human-in-the-Loop: Jede KI-Extraktion landet zuerst im Status PENDING. Erst nach manueller Freigabe geht die Antwort in die Auswertung – wird sie abgelehnt, ist die Extraktion verworfen. Ein simpler, aber wichtiger Schritt: Die KI ist hier ein Vorschlag, kein Urteil.

Eskalation: Ein zusätzlicher Endpoint /eskalieren findet alle überfälligen Versendungen (Frist überschritten, keine Antwort) und markiert sie. Das passt gut zum Use-Case, in dem regelmäßig Erinnerungen rausgehen müssen.

Tests: 18 Unit-Tests (ID-Generierung, Betreff-Parsing, KI-Output-Validierung), 23 Integrationstests gegen eine echte Postgres-Test-DB (alle API-Endpunkte), 26 Security-Tests (SQL-Injection-Payloads, Input-Validierung, HTTP-Methoden, XSS-Regression, Schutz-Header). Dazu Bandit für statische Code-Analyse und Safety für CVE-Checks – alles in einer GitHub-Actions-Pipeline mit vier parallelen Jobs.

Das Schöne an dem Ansatz: Wenn Outlook oder ein anderer Mail-Connector irgendwann tatsächlich angedockt werden muss, ist das nur eine Eingangsroute mehr. Die Logik dahinter – Parsen, KI-Extraktion, Review, Eskalation – bleibt unverändert. Simulation war hier kein Notnagel, sondern die ehrliche Antwort auf die Frage, welcher Teil der Wertschöpfung tatsächlich neu ist: nicht das Versenden, sondern das Verstehen der Antworten.

Also erst mal sortiert: Ein Idempotency Key sorgt dafür, dass ein doppelt abgeschickter Request nicht zweimal ausgeführt wird – klassisch bei Zahlungen, damit 50 € nicht versehentlich zweimal abgebucht werden. Da ich keine Payment-Flows habe, fällt das weg. Rate-Limit und IP-Throttling dagegen schützen öffentliche Endpoints vor Brute-Force und Flood-Angriffen – und genau das hat mir gefehlt.

Der kritische Punkt auf meinem Server ist der Musik-Upload-Proxy (FastAPI + SFTP), über den die Admin-Seite MP3-Dateien auf Hostinger schickt. Er ist zwar per Bearer-Token geschützt, aber SHA-256 ist schnell zu brute-forcen, und bei jedem fehlgeschlagenen Versuch würde der Server bis zu 50 MB Upload-Body entgegennehmen, bevor überhaupt die Auth greift. Klassisches DoS-Risiko.

Die Lösung: Rate-Limit-Middleware direkt auf Traefik-Ebene – kein Code-Rebuild nötig, blockt schon, bevor der große Body durchkommt. Vier Zeilen im docker-compose.yml: average=20, period=1m, burst=40 pro IP. Für mich beim Hochladen völlig unkritisch – für einen Angreifer bedeutet das, dass Brute-Force auf den Token statistisch unmöglich wird.

Seitenfund beim Reinschauen ins docker-compose.yml: Das SFTP-Passwort stand dort im Klartext. „Nicht heute" habe ich kurz gedacht – dann korrigiert vom User: „Warum nicht heute?" Gute Frage, kein guter Grund. Also gleich hinterher: Passwort in eine .env-Datei mit chmod 600, .gitignore daneben, env_file-Referenz im Compose-File. Damit ist auch ein späterer Git-Push des Verzeichnisses safe.

Lektion: Security-Fachbegriffe sind keine Checkliste, die man komplett abhaken muss. Erst verstehen, welches Problem sie lösen, dann prüfen, ob man dieses Problem überhaupt hat. Und wenn man dann doch etwas absichert: richtig, nicht halb.

Lösung für Teil eins: ein eigener MCP-Hub-Server unter mcp.eiskopani.de. MCP steht für Model Context Protocol – der Standard, über den Claude Tools von außen einbinden kann. Der Hub läuft als Docker-Container, hat die vier Projektverzeichnisse (LernyTube, Whisky, EIS, vita) read-only eingebunden und stellt Tools bereit wie list_projects, read_project_file oder run_shell. Jede neue Claude-Session kennt ab sofort alle Projekte automatisch. Authentifizierung per Secret im URL-Query, HTTPS via Traefik + Let's Encrypt.

Teil zwei war härter. Meine Telegram-Pipeline – ich schicke eine Nachricht ans Bot, und Claude Code erledigt die Aufgabe auf dem Server – hatte bisher ein Zwischenglied: Ein lokales Ollama-Modell (Qwen 2.5 Coder 7B) sollte die Nachricht in einen strukturierten Task formatieren. Klang clever, war in der Praxis aber ein Problem: Das Modell braucht 4,3 GB RAM, mein VPS hat nur 3,4 GB frei. Jeder zweite Aufruf endete mit Memory-Error.

Die ehrliche Erkenntnis: Claude Code selbst ist das smarte LLM. Warum soll ein zweites, kleineres Modell davor versuchen, Dinge zu „verstehen", wenn das eigentliche Modell dahinter das viel besser kann? Also Ollama komplett aus dem Workflow entfernt. Die Telegram-Nachricht geht jetzt direkt als Markdown-Datei in den Claude-Inbox-Ordner, ein systemd-Watcher pollt alle fünf Sekunden, Claude Code übernimmt, antwortet via Stop-Hook zurück an Telegram. Kein RAM-Problem, kein Memory-Error, und die Reaktionszeit ist spürbar schneller.

Beide Änderungen teilen eine Lektion: Komplexität ist kein Qualitätsmerkmal. Ein Layer, der Ressourcen frisst ohne Mehrwert zu bringen, muss raus – auch wenn er am Anfang schlau wirkte.

Also habe ich alle meine Projekte durchsucht – vita.eiskopani.de, das Whisky-Kuratorium und LernyTube. Das Ergebnis: Keines davon setzt Browser-Cookies. Was ich im Code gefunden habe, sind ausschließlich serverseitige Datenbank-Sessions (SQLAlchemy Session) – die haben mit Browser-Cookies nichts zu tun.

Kein Google Analytics, kein Tracking, keine Third-Party-Cookies. Das bedeutet: Ein Cookie-Banner wäre nicht nur unnötig, sondern sogar fragwürdig. Consent für etwas abfragen, das gar nicht stattfindet? Das verwirrt Besucher und ist rechtlich unsauber.

Die Lektion: Nicht jede „Best Practice" passt zu jedem Projekt. Erst prüfen, was technisch tatsächlich passiert – dann entscheiden. Falls ich später mal Login-Cookies oder Analytics einbaue, kommt der Banner dazu. Bis dahin bleibt er weg.

Die Ursache war, dass meine Upload-Admin-Seite die Dateien nur lokal im Browser gespeichert hat (localStorage), aber nie auf den Server hochgeladen hat. Das habe ich komplett umgebaut: Jetzt gibt es einen Upload-Proxy auf meinem VPS, der die MP3-Dateien per SFTP direkt an den Hostinger-Webserver schickt. Drag & Drop in die Admin-Seite → Fortschrittsbalken → fertig auf dem Server. Löschen geht auch direkt über den Button.

Technisch ist das ein kleiner FastAPI-Service mit Paramiko (Python SFTP-Bibliothek), der hinter Traefik unter lernytube.eiskopani.de/music-api/ erreichbar ist. Die Authentifizierung nutzt denselben Passwort-Hash wie die Admin-Seite – keine doppelte Pflege.

Und weil „es funktioniert" nicht reicht, habe ich 14 Playwright-Tests geschrieben, die den Player automatisiert prüfen: Ist die Playlist da? Funktioniert Next/Prev? Kann man die Lautstärke ändern? Und vor allem: Sind alle 25 MP3-Dateien auf dem Server erreichbar (kein 404)? Alle Tests grün.

Die Antwort war überraschend klar. Microservices lösen ein Teamproblem: Wenn fünf Teams gleichzeitig an einem Produkt arbeiten, braucht man unabhängige Deployments. Wenn ein Service 100-mal mehr Last bekommt als der Rest, will man ihn separat skalieren. Beides trifft auf mich nicht zu. Ich arbeite allein, meine Projekte haben überschaubare Last, und mein Server hat nicht mal genug RAM für Ollama ohne Swap.

Was Microservices kosten würden: mehr Container, mehr RAM-Verbrauch, Service Discovery, Health Checks, Retry-Logik, Distributed Tracing statt einfachem Logging. Jeder dieser Punkte ist ein eigenes Rabbit Hole – und keiner davon macht meine Schuh-Galerie oder mein Whisky-Kuratorium besser.

Mein Ansatz: Ein sauberer Monolith pro Projekt. Whisky-Kuratorium, LernyTube und EIS Schuh-Atelier sind bereits getrennte Repositories mit eigenen Containern – das ist die richtige Schnittlinie. Innerhalb jedes Projekts sorgen Router, Services und Models für Ordnung, ohne dass ich dafür Netzwerk-Calls zwischen Containern brauche.

Die wichtigste Erkenntnis: Architektur-Entscheidungen sollten von den eigenen Rahmenbedingungen ausgehen, nicht vom letzten Conference Talk. Ein Solo-Projekt auf einem VPS ist kein Netflix. Und wenn ein Projekt irgendwann wirklich wächst, kann ich Module immer noch extrahieren – aber dann aus einer funktionierenden Codebasis heraus, nicht aus einer vorzeitig zerlegten.

Dazu kamen GitHub-Actions-Pipelines, die bei jedem Push automatisch loslaufen – mit echten Datenbanken als Service-Container, nicht mit Mocks. Denn genau da hatten wir vorher ein Problem: Mock-Tests bestanden, aber die echte Datenbank verhielt sich anders. Diese Lektion sitzt jetzt im Code statt nur im Kopf.

Was dabei sichtbar wird: Testmanagement und Release-Steuerung beim InGe-Tool, agiles Projektmanagement mit Scrum und SAFe, Prozessautomatisierung mit Power Apps und Power Automate, Stakeholder-Kommunikation quer durch den Konzern. Dazu kommen Seminare wie IREB, ITIL und Leading SAFe – und natürlich die laufende Weiterbildung zur Software Developerin (IHK) mit Python, SQL und Web-Entwicklung.

Besonders spannend finde ich, wie sich der rote Faden zieht: Egal ob Kreditvergabe digitalisieren, Formulare in Form.io bauen oder heute eigene Docker-Container auf dem VPS betreiben – es ging immer darum, Abläufe zu verstehen und dann besser zu machen.

Dazu kam ein Mini-Kalender auf dem Dashboard, der die eigenen Lernsessions tagesgenau anzeigt und filtert – so sieht man auf einen Blick, wann man wie viel gelernt hat. Über 900 neue Zeilen Code an einem Tag, verteilt auf 15 Dateien: Routen, Modelle, HTML-Templates und JavaScript. Es fühlt sich gut an, wenn aus einer Idee Schritt für Schritt ein echtes Produkt wird.

Im Header leuchtet ab sofort die aktuell besuchte Seite in Champagner-Gold mit einem weichen Glow und einer dunklen Patina-Linie darunter – wie ein Messingschild in einer alten Bibliothek. Die roten Trennlinien unter den Überschriften sind goldenen gewichen, alle Buttons tragen nun Kupfer-Gold mit Navy-Schrift, und das Motto-Band auf der Startseite hat das schreiende Rot gegen ein cremefarbenes Band mit goldenen Linien getauscht.

Drei Vorschläge habe ich Claude machen lassen, eine Test-Seite gebaut, im Browser verglichen, entschieden – und dann lief alles automatisch durch: CSS angepasst, Cache-Buster gebumpt, per SFTP deployt, in GitHub gesichert. Zum Abschluss noch das Portrait auf wer-bin-ich ausgetauscht. Manchmal ist ein guter Tag einfach ein Tag, an dem die Seite endlich so aussieht, wie sie sich anfühlen soll.

Das Ergebnis: Sichere Passwörter generiert (64 Zeichen, kryptografisch zufällig), Datenbank mit den neuen Credentials neu aufgesetzt, ein zentrales Auth-Modul gebaut, alle Routen auf saubere Bearer-Token im Header umgestellt (statt Token in der URL), CORS auf die richtige Domain eingegrenzt, Passwort-Validierung serverseitig verschärft, der Excel-Upload auf 10 MB begrenzt – und am Ende ein Git-Push und ein neuer Blog-Eintrag.

Was übrig blieb: drei Punkte, die wirklich meine Entscheidung brauchen – ein DNS-Eintrag beim Provider, meine echte Admin-Email, und der erste visuelle Test im Browser. Genau die Art von Arbeitsteilung, die ich mir vorgestellt hatte: Die KI macht das Stumpfe und Mechanische, ich treffe die Entscheidungen, die nur ein Mensch treffen kann.

Im zweiten Teil des Tages ging es um Sicherheit: Sichere Passwörter generiert, CORS auf die Domain eingegrenzt, der Login-Mechanismus von URL-Parametern auf richtige Bearer-Token im Header umgestellt, Passwort-Validierung serverseitig verschärft. Aus einem Prototyp wird langsam ein produktionsreifes System.

In einer einzigen Session haben wir die komplette Infrastruktur aufgebaut: Docker-Container, PostgreSQL-Datenbank, Nutzer-System mit Einladungs-Hierarchie (man muss freigeschaltet werden), JWT-Authentifizierung und eine vollständige API für die Sammlung. Das Highlight: Ein Excel-Import, der eine ganze Sammlung per Drag-and-Drop einlesen kann – mit automatischer Erkennung, ob eine Flasche bereits existiert. Manchmal passiert an einem Tag mehr, als man für eine Woche plant.

Das Ergebnis: Ein funktionierender Workflow, der eine Nachricht wie „Baue einen Logout-Button" entgegennimmt, per lokalem KI-Modell (Ollama) in eine strukturierte Entwicklungsaufgabe verwandelt und in eine Warteschlange schreibt. Neu dazu kam ein /status-Befehl, der auf Knopfdruck zeigt, welche Aufgaben offen und erledigt sind. Kleine Nachricht, große Wirkung.

Und eine Ende-Datei, die sicherstellt, dass am Schluss nichts verloren geht. Die echte Herausforderung? Alle laufenden Projekte, Zugangsdaten, Infrastrukturdetails und Arbeitsregeln so zu strukturieren, dass eine KI in Sekunden einsatzbereit ist – ohne dass ich jedes Mal von vorne erklären muss. Das ist wie ein perfektes Briefing für einen neuen Kollegen, den man immer wieder frisch begrüßt.

Es ist der Entschluss, meinen Lernweg öffentlich zu machen. Nicht als Hochglanz-Portfolio, sondern als echtes Tagebuch meiner Entwicklung.

Dieser Blog wird von mir und meinem KI-Assistenten Claude gepflegt. Nach jeder Arbeits-Session entsteht hier ein Eintrag – damit nichts verloren geht und du nachvollziehen kannst, wie Projekte wirklich entstehen.