Back to Blog

Code Cleanup mit Opus 4.8

Heute ist Opus 4.8 in Claude Code gelandet, und ich wollte das neue Modell direkt an etwas Echtem ausprobieren. Der Anlass kam aus dem Browser, wo mir aufgefallen war, dass jeder Besucher den Quelltext meiner Seite lesen kann.

Auslöser war F12, Tab Sources. Statt blind etwas zu verstecken, haben wir erst geklärt was überhaupt ein Risiko ist, dann den Frontend-Code systematisch durchsucht und am Ende genau eine relevante Stelle plus ein paar Kosmetik-Reste entfernt.

Der F12-Moment

Ich hatte newwaves.dev offen, F12 gedrückt und unter Sources auf einmal meinen kompletten HTML-, CSS- und JS-Code vor mir. Der erste Gedanke war simpel. Wenn ich das sehe, sieht das jeder. Der zweite ging weiter. Stehen da vielleicht Kommentare oder Infos, die nicht für fremde Augen gedacht sind?

Genau an dem Tag kam Opus 4.8 für Claude Code raus. Eine gute Gelegenheit, das neue Modell nicht an einer Spielaufgabe zu testen, sondern an einer echten kleinen Frage an meiner eigenen Seite.

Das eigentliche Risiko sind Geheimnisse

Bevor irgendetwas geändert wurde, ging es um die Einordnung. Sichtbarer Frontend-Code ist normal. HTML, CSS und JavaScript müssen zum Browser geschickt werden, damit die Seite überhaupt funktioniert. DevTools zeigt nur, was ohnehin schon auf dem Rechner des Besuchers liegt. Das lässt sich technisch nicht verhindern, und es gilt für jede Website.

Das eigentliche Risiko ist nicht der sichtbare Code, sondern was versehentlich darin steht, etwa API-Keys, Tokens, Passwörter, interne Kommentare, versteckte Pfade oder E-Mail-Adressen. Code unleserlich zu machen (Minification, Obfuscation) gibt nur ein Gefühl von Sicherheit. Die richtige Regel ist simpel, nämlich keine Geheimnisse ins Frontend. Also kein Verstecken, sondern Aufräumen.

Wie der Audit lief

Opus 4.8 hat alle 23 HTML-, CSS- und JS-Dateien gezielt nach Mustern durchsucht, statt sie nur quer zu lesen:

  • Secrets wie api_key, token, secret, password, private_key und Verwandte.
  • E-Mail-Adressen, die crawlbar im Quelltext stehen könnten.
  • Kommentare mit internen Notizen wie TODO, FIXME, HACK, Platzhalter und alle HTML-Kommentare.
  • Server-Spuren in JS/CSS, etwa IP-Adressen, Pfade wie /var/www, console.log oder debugger.

Aus den Treffern wurde sortiert, was bewusster Inhalt ist, was harmlos ist und was wirklich weg sollte. Die meisten Treffer waren normaler Blog-Text (Wörter wie „wichtig" oder „intern" in Artikeln) oder bewusst veröffentlichte Beispiele.

Was der Audit gefunden hat

Zuerst die gute Nachricht. Keine API-Keys, Tokens oder Passwörter, nirgends. JavaScript und CSS waren komplett sauber, kein vergessenes console.log, kein debugger, keine IP-Adressen, keine Serverpfade.

Genau ein echter Fund blieb übrig, ein interner Notiz-Kommentar im <head>-Bereich der Startseite, der für jeden Besucher im Quelltext stand. 

<!-- TODO: ... Pfad und Mail sind Platzhalter
     aus dem Design - bitte austauschen ... -->

Drei Dinge waren daran unschön. Der Kommentar war eine Notiz an mich selbst, die öffentlich mitlas. Er nannte eine E-Mail-Adresse (Futter für Spam-Crawler) und einen geplanten, noch nicht existierenden Pfad. Und er gab zu, dass Teile noch Platzhalter aus dem Design sind, was unfertig wirkt.

Bewusst stehen geblieben sind Dinge, die kein Risiko sind, etwa ein paar Struktur-Kommentare im HTML, eine GitHub-noreply-Adresse, die ich in einem Tutorial-Post absichtlich zeige, und die SSH-Beispiele in den Security-Artikeln (die echte Portnummer hatte ich dort schon vorher durch einen Platzhalter ersetzt).

Die kleinen Fixes

Aufgeräumt wurde nur, was ich vorher freigegeben hatte:

  • Den internen TODO-Kommentar in index.html ersatzlos gelöscht.
  • Die rein kosmetischen Struktur-Kommentare in index.html und blog.html entfernt.

Unterm Strich elf gelöschte Zeilen über zwei Dateien. Am sichtbaren Inhalt und am Layout ändert sich nichts, im Quelltext steht dafür nichts mehr, was da nicht hingehört.

Einmal bewusst hinschauen

Die Angst vor dem sichtbaren Code war die falsche Sorge. Die richtige Frage ist nicht „wie verstecke ich den Code", sondern „steht da etwas drin, das nicht raus soll". Bei einer statischen Seite wie dieser ist die Antwort fast immer beruhigend, solange man einmal bewusst hinschaut.

Und als erster echter Test war Opus 4.8 ein guter Start, erst einordnen, dann gezielt suchen, dann nur das anfassen, was wirklich freigegeben war.