{"id":8838,"date":"2026-08-20T14:30:00","date_gmt":"2026-08-20T12:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8838"},"modified":"2026-10-24T01:52:29","modified_gmt":"2026-10-23T23:52:29","slug":"zero-server-side-browser-tools-entwicklung-sicherer-werkzeuge-mit-vanilla","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/web-entwicklung\/zero-server-side-browser-tools-entwicklung-sicherer-werkzeuge-mit-vanilla\/","title":{"rendered":"Zero-Server-Side-Browser-Tools: Entwicklung sicherer Werkzeuge mit Vanilla JavaScript"},"content":{"rendered":"
Ein lokales Browserwerkzeug kann Eingaben hashen, auswerten oder umformen, ohne diese Inhalte an einen Anwendungsserver zu \u00fcbertragen. Der Vorteil ist ein kleinerer Datenfluss: Ein Verarbeitungsendpunkt ben\u00f6tigt die sensiblen Inhalte nicht. Die Seite selbst kann weiterhin aus dem Netz geladen werden; dabei fallen beim Hostingserver Anfragemetadaten an. Die Aussage \u201elokal verarbeitet\u201c braucht deshalb einen klaren Geltungsbereich.<\/p>\n
Lokale Verarbeitung hat eine Vertrauensgrenze<\/h2>\n
Die Browser-Sandbox trennt Webinhalte von Teilen des Betriebssystems. Code auf derselben Seite kann trotzdem Eingabefelder lesen. Ein kompromittiertes Skript, unsicher eingef\u00fcgtes HTML oder eine Browsererweiterung mit passenden Rechten kann die Vertraulichkeit beeintr\u00e4chtigen. Vanilla JavaScript bezeichnet Code ohne Framework und ist keine Sicherheitsgarantie.<\/p>\n
Wenige Abh\u00e4ngigkeiten, HTTPS-Auslieferung, gepr\u00fcfter Quellcode und der Verzicht auf Analytics oder Sitzungsaufzeichnungen im Eingabebereich verringern Risiken. Eingaben geh\u00f6ren nicht in URLs, Anwendungsprotokolle oder Fehlertelemetrie. Beliebiger Text wird \u00fcber textContent<\/code> oder das value<\/code> eines Eingabefeldes ausgegeben, nicht \u00fcber innerHTML<\/code>.<\/p>\n\nLokale Textverarbeitung mit Web Crypto. CSP begrenzt bestimmte \u00dcbertragungswege und erg\u00e4nzt die Codepr\u00fcfung.<\/figcaption><\/figure>\n
Die vorgesehenen Bytes hashen<\/h2>\n
TextEncoder<\/code> kodiert JavaScript-Text als UTF-8-Bytes. TextDecoder<\/code> wandelt Bytes einer ausgew\u00e4hlten Kodierung zur\u00fcck in Text. Auch diese Vorg\u00e4nge ben\u00f6tigen Speicher und Rechenzeit. crypto.subtle.digest()<\/code> liefert ein Promise; vorbereitende Textumwandlungen und Schleifen k\u00f6nnen den Hauptthread trotzdem besch\u00e4ftigen. Hardwarebeschleunigung und fehlende Latenz sind nicht garantiert.<\/p>\n
Das Beispiel berechnet SHA-256 \u00fcber die UTF-8-Darstellung, ohne Leerzeichen zu entfernen oder Gro\u00dfbuchstaben zu ver\u00e4ndern. Die Grenze von einer Million UTF-16-Codeeinheiten ist eine beispielhafte Anwendungsgrenze, keine Browsergarantie und keine Byte-Grenze. Eine aufrufende Oberfl\u00e4che muss abgelehnte Eingaben und Fehler verst\u00e4ndlich anzeigen.<\/p>\n
async function sha256Text(text) {\n if (typeof text !== 'string') throw new TypeError('Expected text');\n if (text.length > 1_000_000) throw new RangeError('Input too large');\n if (!globalThis.isSecureContext || !globalThis.crypto?.subtle) {\n throw new Error('Web Crypto requires a supported secure context');\n }\n const bytes = new TextEncoder().encode(text);\n const digest = await crypto.subtle.digest('SHA-256', bytes);\n return Array.from(new Uint8Array(digest),\n byte => byte.toString(16).padStart(2, '0')).join('');\n}\n<\/code><\/pre>\n
F\u00fcr eine Dateipr\u00fcfsumme sind die urspr\u00fcnglichen Datei-Bytes ma\u00dfgeblich, nicht erneut dekodierter und kodierter Text. digest()<\/code> ben\u00f6tigt die vollst\u00e4ndige Eingabe im Speicher und unterst\u00fctzt kein schrittweises Streaming. Sehr gro\u00dfe Dateien erfordern eine andere gepr\u00fcfte Implementierung und gemessene Ressourcengrenzen. SHA-256 allein ist weder Verschl\u00fcsselung noch ein geeignetes Verfahren zur Passwortspeicherung. Vorhersagbare personenbezogene Angaben werden durch einen Hash nicht automatisch anonym.<\/p>\n
connect-src 'self'<\/code> erlaubt Skriptverbindungen zur eigenen Origin. connect-src 'none'<\/code> blockiert die von dieser Direktive erfassten Verbindungs-APIs, etwa fetch, WebSocket und Beacons. F\u00fcr Bilder, Formulare, Frames und Skriptdateien gelten eigene Regeln. Die Richtlinie eines lokalen Werkzeugs muss auch diese Wege ber\u00fccksichtigen und ausf\u00fchrbaren Code eng begrenzen.<\/p>\n
CSP wird im Browser durchgesetzt und bietet eine zus\u00e4tzliche Schutzschicht, ist aber keine allgemeine Netzwerk-Firewall und kein mathematischer Ausschluss von Datenabfluss. Navigation und erlaubte Ressourcenabrufe ben\u00f6tigen eine eigene Betrachtung. Auch selbst gehostete Skripte k\u00f6nnen kompromittiert sein. Eine durchgesetzte Richtlinie muss gepr\u00fcft werden; Report-Only meldet Verst\u00f6\u00dfe, blockiert aber nicht.<\/p>\n
Workers verbessern die Reaktionsf\u00e4higkeit, nicht die Geheimhaltung<\/h2>\n
Ein Web Worker kann aufwendige Berechnungen vom UI-Thread trennen. Direkter DOM-Zugriff fehlt im Worker, doch die Seite \u00fcbergibt Eingabe und empf\u00e4ngt Ergebnis. Sch\u00e4dlicher Seitencode kann deshalb an beiden \u00dcbergabepunkten mitlesen. Auch Workers k\u00f6nnen Netzwerkanfragen ausf\u00fchren.<\/p>\n
Eine getrennte Workerdatei ben\u00f6tigt den passenden CSP-Antwortheader f\u00fcr den eigenen Ausf\u00fchrungskontext. worker-src<\/code> der Seite steuert das Laden des Workers, nicht automatisch dessen sp\u00e4tere Verbindungen. Blob-Workers erben die Richtlinie des Erzeugers und ben\u00f6tigen eine passende Ladefreigabe. Eine separate Datei erleichtert die Pr\u00fcfung; eine Pr\u00fcfsumme allein belegt jedoch kein netzwerkfreies Verhalten.<\/p>\n
Nachweise und verbleibende Grenzen<\/h2>\n
Eine sinnvolle Pr\u00fcfung umfasst Laden, Eingabe, Verarbeitung, Kopieren oder Download, Fehlerf\u00e4lle und Leeren. Zur Netzwerkpr\u00fcfung geh\u00f6ren Workers und gegebenenfalls aktive Service Workers. Ein Offline-Durchlauf nach dem Laden belegt den gepr\u00fcften Stand und Ablauf, nicht jede sp\u00e4tere Version. Testumgebungen mit gesperrtem Netzwerk liefern einen zus\u00e4tzlichen Nachweis.<\/p>\n
Leere Felder und verworfene Referenzen verringern versehentliche Wiederverwendung. JavaScript kann aber keine forensische L\u00f6schung s\u00e4mtlicher Kopien im Browser- oder Betriebssystemspeicher zusichern. Zwischenablage, Downloads und absichtlich gespeicherte Daten k\u00f6nnen einen Tab \u00fcberdauern. Unn\u00f6tige Speicherung zu vermeiden ist belastbarer als vollst\u00e4ndige L\u00f6schung beim Schlie\u00dfen zu versprechen.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Gilt der sichere Kontext auch bei lokaler Entwicklung?<\/h3>\n
crypto.subtle<\/code> ben\u00f6tigt einen unterst\u00fctzten sicheren Kontext. HTTPS und normale Entwicklung \u00fcber localhost sind geeignet. Eine einfache HTTP-Adresse im privaten LAN gilt normalerweise nicht als sicherer Kontext. Das Beispiel pr\u00fcft sowohl den Kontext als auch die Verf\u00fcgbarkeit der API und meldet fehlende Unterst\u00fctzung.<\/p>\n
Beweist ein leerer Netzwerk-Reiter die Vertraulichkeit?<\/h3>\n
Nur der beobachtete Ablauf ist damit dokumentiert. Ein erg\u00e4nzender Offline-Test, eine gepr\u00fcfte durchgesetzte CSP und Kontrolle der ausgelieferten Abh\u00e4ngigkeiten st\u00e4rken den Nachweis. Ein einzelner Test ersetzt keine Pr\u00fcfung sp\u00e4terer \u00c4nderungen.<\/p>\n<\/div>\n
![\"Lokale](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/quality-8838-20261024.png\")