So funktioniert LokalPix
im Detail.

Kurzfassung

Kernaussage: Kein Bildinhalt wird an den LokalPix-Server gesendet. Der Server liefert die Anwendung aus und stellt eine aggregierte Aufrufstatistik bereit; die eigentliche Bildverarbeitung findet auf dem Endgerät statt.

Datenfluss einer Konvertierung

1. 1
   Seite laden

   Beim Laden einer Konverterseite kann der Browser HTML, CSS, JavaScript, Manifest, Symbol und Service Worker von derselben LokalPix-Adresse abrufen. Die Seite liest zusätzlich /api/stats. Die Technikseite selbst lädt nur HTML, CSS und gegebenenfalls das Symbol; sie führt kein App-JavaScript aus.

2. 2
   Datei auswählen

   Die Dateiauswahl erfolgt über das native Datei-Auswahlfeld des Browsers. JavaScript erhält nur die vom Nutzer ausgewählten Dateien.

3. 3
   Datei lokal prüfen

   Dateityp, Dateigröße und Bildabmessungen werden im Browser geprüft. Bei SVG sucht die Anwendung nach festgelegten riskanten Elementen und Mustern und lehnt die Datei bei einem Treffer ab.

4. 4
   Bild lokal dekodieren

   Standardformate dekodiert der Browser über createImageBitmap oder ein lokales Image-Objekt. DNG und weitere Kamera-RAW-Formate verarbeitet die selbst gehostete WebAssembly-Bibliothek LibRaw; HEIC/HEIF verarbeitet die ebenfalls selbst gehostete WebAssembly-Bibliothek libheif. Die großen Decoder werden erst bei Bedarf geladen. Bilddaten werden dabei nicht an eine Serveradresse übertragen.

5. 5
   Neu zeichnen und codieren

   Das Bild wird in ein Canvas gezeichnet. canvas.toBlob() erzeugt PNG, JPG oder WebP. Für JPG wird zuvor ein weißer Hintergrund eingefügt.

6. 6
   Aggregierte Bildanzahl melden

   Nach mindestens einer erfolgreichen Ausgabe sendet der Browser an POST /api/convert ausschließlich eine kleine JSON-Nachricht mit der Anzahl erfolgreich konvertierter Bilder. Der Server akzeptiert ganze Werte von 1 bis 20 und addiert sie zum aggregierten Bildzähler. Bildinhalt, Dateiname, Format, Größe und Konvertierungseinstellungen werden nicht gesendet.

7. 7
   Download

   Die Ausgabedatei wird als temporäre Blob-URL im Browser bereitgestellt. Erst der Nutzer speichert sie über „Herunterladen“ auf seinem Gerät.

8. 8
   Speicher freigeben

   Beim Entfernen oder vollständigen Zurücksetzen widerruft die Anwendung zugehörige Blob-URLs. Alte Ausgabe-URLs werden nach erfolgreicher Neukonvertierung beziehungsweise beim Formatwechsel widerrufen. Zusätzlich ist ein Widerruf bei beforeunload registriert; dessen Ausführung ist nicht in allen Browser-Lebenszyklen garantiert.

Bildverarbeitung und Formate

Eingaben

Akzeptiert werden JPEG/JPG einschließlich JFIF, PNG, WebP, GIF, BMP, HEIC/HEIF, DNG, CR2, CR3, NEF, ARW, RAF, RW2, ORF, PEF, SRW, ERF, SVG und AVIF mit höchstens 75 MB pro Datei. Maximal 20 Dateien werden gleichzeitig in die Warteschlange aufgenommen. Leere oder allgemeine MIME-Angaben dürfen anhand einer bekannten Dateiendung ergänzt werden; ein ausdrücklich fremder MIME-Typ wird nicht durch die Endung überschrieben.

JFIF, BMP und GIF

JFIF ist kein eigenes Format, sondern die verbreitetste Containervariante von JPEG. Dateien mit den Endungen .jfif, .pjp und .pjpeg werden deshalb dem MIME-Typ image/jpeg zugeordnet und durchlaufen denselben Weg wie gewöhnliche JPEG-Dateien.

BMP (image/bmp, zusätzlich die Varianten image/x-ms-bmp und image/x-bmp) und GIF (image/gif) dekodiert der Browser selbst. Für beide Formate liest LokalPix die Abmessungen vorab aus dem Dateikopf: bei BMP aus dem BM-Kennzeichen und dem darauf folgenden Header, bei GIF aus der Signatur GIF87a beziehungsweise GIF89a und dem anschließenden Logical Screen Descriptor. Schlägt diese Prüfung fehl, wird die Datei abgelehnt, bevor ein Decoder sie verarbeitet. Für diese drei Formate wird keine zusätzliche Bibliothek nachgeladen.

Animierte GIFs: Die Ausgabe enthält ausschließlich das erste Frame. Das ist kein Fehler der Anwendung, sondern das im HTML Living Standard beschriebene Verhalten beim Zeichnen einer animierten Bildquelle in ein Canvas: Es wird der Standbild-Frame verwendet. Eine Animation lässt sich auf diesem Weg nicht in PNG oder JPG überführen. Nachzulesen unter html.spec.whatwg.org, Abschnitt zu Canvas-Bildquellen.

Lokale Decoder

LibRaw-Wasm entwickelt unterstützte RAW-Dateien zu RGB-Pixeln. Einige neuere Apple-ProRAW-DNGs mit JPEG-XL-Kompression werden von diesem Build nicht unterstützt. libheif-js dekodiert HEIC/HEIF-Dateien zu RGBA-Pixeln. Beide Bibliotheken und ihre WebAssembly-Bestandteile liegen auf der LokalPix-Domain und laufen im Browser; es wird kein externer Konvertierungsdienst angesprochen. Die Ausgabe übernimmt nicht zuverlässig sämtliche EXIF-Metadaten, Tiefeninformationen, RAW-Bearbeitungsreserven oder den vollständigen HDR-Umfang der Quelle.

Abmessungsgrenzen

Erlaubt sind höchstens 16.384 Pixel pro Kante und insgesamt 40 Megapixel. Bei PNG, JPEG, WebP und AVIF versucht LokalPix, die Abmessungen bereits aus den ersten 512 Dateibytes auszulesen. Nach dem Dekodieren wird die Grenze erneut geprüft.

Ausgaben

PNG, JPG und WebP werden über die Canvas-Schnittstelle des Browsers erzeugt. Die Qualitätswahl beeinflusst JPG und WebP. AVIF wird nicht als Ausgabe angeboten, weil die Canvas-Unterstützung dafür nicht browserübergreifend zuverlässig ist.

Ausrichtungsmetadaten

Beim bevorzugten Dekodierweg fordert createImageBitmap mit imageOrientation: 'from-image' die Anwendung der in der Quelldatei hinterlegten Ausrichtung an. Beim Rückfall auf ein Image-Objekt ist das Verhalten browserabhängig. Die Wirkung einer EXIF-Ausrichtung kann dadurch in Abmessungen und Ausgabepixel einfließen, obwohl das ursprüngliche Metadatenfeld nicht ausdrücklich in die Ausgabedatei kopiert wird.

SVG-Sonderbehandlung

SVG ist ein XML-basiertes Dokumentformat und kann aktive oder externe Inhalte enthalten. LokalPix parst SVG im Browser und sucht nach einer im Quellcode definierten Denylist, unter anderem nach Skripten, Ereignisattributen, eingebetteten Fremdinhalten, Animationen, Stylesheets, externen href-Zielen, externen CSS-URLs, CSS-Imports, Expressions, maskierten Stilwerten und nicht zuverlässig auflösbaren CSS-Maßeinheiten. Bei einem Treffer wird die Datei abgelehnt; andernfalls wird die serialisierte SVG-Struktur weiterverarbeitet. Diese Prüfung reduziert das Risiko, ist aber keine vollständige Element- und Attribut-Allowlist und garantiert nicht die Erkennung jeder denkbaren aktiven SVG-Funktion.

Komprimierung

Die Seiten „JPG komprimieren“ und „PNG komprimieren“ verwenden eine eigene Anwendungsdatei compress-app.mjs. Sie lädt keine zusätzlichen Decoder und sendet keine Bilddaten an eine Serveradresse; der Ablauf entspricht dem der Konvertierung.

Komprimiert wird, indem das Bild in ein Canvas gezeichnet und über canvas.toBlob() mit dem gewählten Qualitätswert neu codiert wird. Es handelt sich damit um eine verlustbehaftete Neucodierung, nicht um eine verlustfreie Optimierung bestehender Bilddaten. Bildinformationen, die beim Neucodieren verworfen werden, lassen sich nicht zurückgewinnen.

Der Qualitätswert wirkt ausschließlich auf JPG und WebP. Für PNG ignoriert canvas.toBlob() den Qualitätsparameter, weil PNG verlustfrei arbeitet. Die Seite „PNG komprimieren“ bietet deshalb JPG und WebP als Ausgabe an, nicht PNG.

Die angezeigte Ersparnis vergleicht die Byte-Größe der Ausgabedatei mit der Byte-Größe der Eingabedatei. Eine Ersparnis ist nicht garantiert: Bei bereits stark komprimierten Quellen oder hoher Qualitätseinstellung kann die Ausgabe größer sein als die Eingabe. In diesem Fall wird das offen angezeigt und nicht als Gewinn dargestellt.

Größenänderung

Die Seite „Bildgröße ändern“ verwendet die Anwendungsdatei resize-app.mjs. Auch hier verlässt kein Bildinhalt das Gerät.

Die Zielgröße lässt sich in Pixeln oder in Prozent angeben. Optional bleibt das Seitenverhältnis erhalten; dann wirkt eine Pixelangabe als begrenzender Rahmen. Eine Vergrößerung über die Originalabmessungen hinaus kann unterbunden werden. Es gelten dieselben Obergrenzen wie bei der Konvertierung: höchstens 16.384 Pixel pro Kante und 40 Megapixel; die Mindestgröße beträgt 1 × 1 Pixel.

Die Skalierung erfolgt über das Canvas des Browsers. Welcher Interpolationsalgorithmus verwendet wird, bestimmt der Browser; LokalPix wendet keine zusätzliche Nachschärfung an. Die Schärfe des Ergebnisses kann sich deshalb zwischen Browsern unterscheiden.

Formatgrenze: HEIC/HEIF und Kamera-RAW-Dateien werden auf dieser Seite nicht unterstützt und mit einer eindeutigen Fehlermeldung abgelehnt. Die dafür nötigen Decoder sind bewusst nicht eingebunden. Solche Dateien lassen sich zuerst über eine Konverterseite in PNG oder JPG umwandeln und anschließend in der Größe ändern.

Welche Netzwerkzugriffe erfolgen?

Startseite

Service-Worker-Installation und Wiederholungsaufrufe

Bei der Installation ruft cache.addAll() die deutschen und englischen Konverterseiten, die Technik- und Impressumsseite sowie /styles.css, /app.mjs, /converter-core.mjs, /manifest.webmanifest und /icon.svg ab. Die großen RAW- und HEIC-Decoder bleiben davon ausgenommen und werden erst beim ersten passenden Bild geladen. Spätere Abrufe statischer Dateien können aus Cache Storage beantwortet werden. Seitennavigationen bleiben network-first; bei einem Netzwerkfehler wird eine vorhandene Cachekopie verwendet. Die konkrete Anfragemenge hängt deshalb von Browser, HTTP-Cache und Service-Worker-Zustand ab.

Technikseite

Ein direkter Aufruf dieser Seite lädt HTML und CSS sowie browserabhängig /icon.svg. Die Seite selbst lädt weder app.mjs noch /api/stats und registriert keinen Service Worker. Ein bereits von der Startseite aktiver Service Worker kann ihre Navigation dennoch verarbeiten.

Die Anwendung enthält keine Analyse-, Werbe-, Social-Media-, Schriftarten- oder sonstigen Drittanbieter-Skripte. Ihre Content Security Policy erlaubt Skripte, Styles und Netzwerkverbindungen nur zur eigenen Herkunft. Vorschaubilder und Ergebnisse verwenden lokale blob:- beziehungsweise eingebettete data:-Quellen.

Abgrenzung: Technisch notwendige Vorgänge des Betriebssystems oder Browsers – beispielsweise DNS-Auflösung oder Zertifikatsprüfung – liegen außerhalb der Anwendungslogik und sind nicht mit einem Bild-Upload gleichzusetzen.

Besucherstatistik

Eine Browsernavigation wird serverseitig gezählt, wenn eine GET-Anfrage für eine deutsche oder englische Konverterseite den Header Sec-Fetch-Mode: navigate enthält und nicht zuvor als bekannter Crawler oder Bot eingeordnet wurde. Gewöhnliche Service-Worker-Vorabrufe werden dadurch nicht erfasst. Technikseite und Impressum werden nicht mitgezählt. Damit die öffentlich sichtbare historische Gesamtsumme vergleichbar bleibt, wird sie weiterhin nur für die bereits vor dieser Erweiterung gezählten Kern-Konverter fortgeschrieben; die neue Seitenaufschlüsselung umfasst alle Konverterseiten. Der geprüfte Node-Anwendungscode greift für diese Zählung nicht auf die im Socket verfügbare Client-IP zu, protokolliert sie nicht, setzt keine Cookies und speichert keine Gerätekennung. Jede HTTP-Verbindung offenbart die Quell-IP technisch mindestens dem Netzwerk- und Hosting-Stack; dessen Verhalten ist separat zu prüfen.

Die Statistik ordnet gezählte Navigationen zusätzlich nach Seite und Kalendertag, Sprache sowie grober Verweisquelle ein: direkt, interner Link, Suchmaschine, soziale Plattform, sonstiger Verweis oder unklar. Ein User-Agent wird nur während der Anfrage gegen feste Muster geprüft und als „wahrscheinlich Browser“, bekannter Suchmaschinen-Crawler, sonstiger Bot/Scraper oder unklar gezählt. Konvertierungen werden der vom Browser gemeldeten, gegen die feste Seitenliste geprüften Route zugeordnet.

Eine neu angelegte Statistikdatei enthält zunächst die Grundzähler. Nach passenden Aufrufen oder Konvertierungen können zusätzlich enthalten sein:

• Datum des Zählbeginns,
• Gesamtzahl der Seitenaufrufe,
• Anzahl der Seitenaufrufe je Kalendertag in der Zeitzone Europe/Berlin,
• aggregierte Aufrufe nach Route, Sprache, Quellen- und Client-Kategorie,
• aggregierte Crawler-/Bot-Anfragen nach Route und Kategorie,
• Gesamtzahl gemeldeter erfolgreich konvertierter Bilder und deren Route.

Vorhandene Statistikdateien werden nicht vollständig gegen ein externes Schema validiert; bereits enthaltene zusätzliche Felder können bei späteren Schreibvorgängen erhalten bleiben. Ungeeignete, aber parsebare Detail-Buckets werden beim nächsten passenden Ereignis durch leere, gültige Aggregate ersetzt. Bei einer fehlerhaften oder nicht lesbaren Statistikdatei fällt der Store auf einen neuen Zustand im Arbeitsspeicher zurück; ein späterer erfolgreicher Schreibvorgang kann die vorherige Datei ersetzen. Persistenz erfolgt best effort und wird für mehrere Ereignisse bis zu etwa zwei Sekunden gebündelt. Ein Schreibfehler wird gegenüber dem Seitenaufruf abgefangen; der aktualisierte Zähler kann dann nur lokal im Prozess vorliegen und bei einem Neustart verloren gehen.

Gesamtsumme und Zählbeginn bleiben bis zur administrativen Löschung oder Ersetzung der Statistikdatei erhalten. Die bisherigen öffentlichen Tageswerte werden auf höchstens 370 vorhandene Datumsschlüssel reduziert; die detaillierten Tagesaggregate auf höchstens 90 Nutzungstage. Dies sind keine zeitbasierten Löschfristen: Bei weniger Nutzungstagen können ältere Werte bestehen bleiben. Bei erfolgreicher Persistenz wird die temporäre JSON-Datei mit Dateirechten 0600 angelegt und umbenannt. Verzeichnisrechte, Backups und privilegierte Systemzugriffe sind davon nicht erfasst. Der öffentliche Statistik-Endpunkt gibt ausschließlich den heutigen Aufrufwert, die Aufruf-Gesamtsumme, die gemeldete Bild-Gesamtsumme und das Startdatum aus und erhält Cache-Control: no-store; die Detailaggregate werden nicht öffentlich ausgeliefert. Der frühere Zähler für Konvertierungsdurchläufe wird nicht als Bildanzahl übernommen; die Bildzählung im Feld convertedImagesTotal startet deshalb semantisch getrennt bei null. Der historische Wert von 17 im Altfeld conversionsTotal zählte abgeschlossene Durchläufe der Stapelverarbeitung, nicht einzelne Bilder. Ein Durchlauf konnte mehrere Bilder enthalten. Die beiden Werte sind deshalb nicht vergleichbar und werden nicht addiert.

Wichtig: Gespeichert werden keine IP-Adressen, vollständigen User-Agents, vollständigen Referrer-URLs, Suchbegriffe, Cookies oder Gerätekennungen. Der Service-Worker-Vorabruf erhöht den Zähler nicht. Header lassen sich fälschen; die Kategorien sind daher nur probabilistische Hinweise und kein Nachweis, ob hinter einer Anfrage ein Mensch, Browser oder Bot steht. Die Statistik erkennt weder eindeutige Besucher noch wiederholtes Neuladen.

Für POST /api/convert verwendet der Server standardmäßig die am Socket sichtbare IP-Adresse ausschließlich als Schlüssel eines Rate-Limits im Arbeitsspeicher. Nur bei ausdrücklich aktiviertem TRUST_PROXY=1 wird der letzte Eintrag aus X-Forwarded-For verwendet; der Reverse Proxy muss diesen Wert vertrauenswürdig setzen und der Node-Port darf nicht öffentlich umgangen werden. Das Limit zählt gemeldete Bilder statt nur Anfragen und erlaubt höchstens 60 pro Minute und Schlüssel. Ein Schlüssel kann durch die periodische Bereinigung bis ungefähr zwei Zeitfenster im Arbeitsspeicher verbleiben. Der Rate-Limit-Schlüssel wird nicht dauerhaft gespeichert: Er bleibt nur bis zur Bereinigung im Arbeitsspeicher und wird nicht in die Statistikdatei geschrieben. Gespeichert wird nur die addierte Gesamtzahl, nicht welcher Aufruf wie viele Bilder enthielt. Die Netzwerk- und Hosting-Ebene kann Verbindungsdaten unabhängig davon verarbeiten.

Messgrenze: Der Bildzähler beruht auf anonymen Meldungen des Browsers ohne Anmeldung oder kryptografischen Nachweis. Das strikte JSON-Format, das Body-Limit und das Rate-Limit erschweren Missbrauch, können absichtlich manipulierte Meldungen aber nicht vollständig verhindern. Die Zahl ist daher ein öffentlicher Nutzungsindikator und keine revisionssichere Messung.

Was wird wo gespeichert?

Davon zu unterscheiden sind zwei Cache-Ebenen: Der Server antwortet für HTML mit Cache-Control: no-cache, für andere statische Dateien mit public, max-age=3600 und für /api/stats mit no-store. Der Service Worker nutzt für vorab gespeicherte Nicht-Navigationsressourcen cache-first.

LokalPix verwendet für die Konvertierung weder localStorage noch Cookies, IndexedDB oder ein Benutzerkonto. localStorage speichert ausschließlich die optionale Hell-/Dunkel-Designwahl. Beim Teilen wird nach Nutzeraktion der native Systemdialog geöffnet oder nur die Seitenadresse in die Zwischenablage geschrieben; Bilddateien werden dabei nicht geteilt.

Sicherheitsmaßnahmen

• Content Security Policy: Standardmäßig sind nur Ressourcen derselben Herkunft erlaubt; Objekte, fremde Frames und fremde Formularziele sind blockiert.
• Frame-Schutz: frame-ancestors 'none' und X-Frame-Options: DENY weisen unterstützende Browser an, die Einbettung in andere Seiten abzulehnen.
• MIME-Schutz: X-Content-Type-Options: nosniff schränkt MIME-Sniffing insbesondere für Script- und Style-Ziele ein.
• Referrer-Schutz: Referrer-Policy: no-referrer unterbindet das Senden einer Referrer-Adresse.
• Berechtigungen: Kamera, Mikrofon, Geolocation und Payment API werden per Permissions-Policy deaktiviert.
• Dateigrenzen: Anzahl, Dateigröße, Kantenlänge und Pixelzahl sind begrenzt.
• SVG-Prüfung: Dateien mit den im Quellcode aufgeführten riskanten Elementen, Referenzen oder Stilwerten werden abgelehnt.
• Keine Bild-Upload-API: Statische Seiten und /api/stats verwenden GET beziehungsweise HEAD. POST /api/convert akzeptiert ausschließlich application/json mit exakt einem ganzzahligen Feld count und höchstens 1.024 Bytes; der Server parst dort keinen Bildinhalt. Andere Methoden und POST-Ziele werden mit Status 405 zurückgewiesen.

Hosting- und Reverse-Proxy-Ebene

Der geprüfte Node-Anwendungscode persistiert keine Client-IP, setzt keine Cookies und nimmt keine Bilder entgegen. Für das Rate-Limit von POST /api/convert liest er die vom Reverse Proxy übermittelte beziehungsweise am Socket sichtbare IP-Adresse und hält sie zeitlich begrenzt im Arbeitsspeicher. Jede Verbindung erreicht außerdem einen Netzwerk- und Hosting-Stack, der die Quell-IP technisch verarbeiten kann. Ein VPS-Anbieter, Reverse Proxy, CDN, eine Firewall, DDoS-Schutz, DNS-Dienst oder Systemprotokolle können zusätzliche Verbindungsdaten, Header oder Cookies verarbeiten beziehungsweise setzen.

Vor Veröffentlichung sollte deshalb separat dokumentiert und geprüft werden:

• welcher Hosting-Anbieter und Serverstandort verwendet wird,
• ob und wie lange Access- und Fehlerprotokolle gespeichert werden,
• ob IP-Adressen gekürzt oder vollständig vermieden werden können,
• welche Auftragsverarbeitungs- und Unterauftragnehmerbeziehungen bestehen,
• wie TLS, Backups, Updates, Zugriffsrechte und Löschfristen organisiert sind.

Diese Grenze ist entscheidend: „Keine Bild-Uploads“ ist eine Eigenschaft der Anwendung. Aussagen über vollständige Server-Protokollfreiheit sind erst nach Prüfung der konkreten Produktionsumgebung möglich.

Was diese Architektur nicht garantiert

• Ein kompromittierter Browser, eine schädliche Browser-Erweiterung oder ein kompromittiertes Endgerät liegt außerhalb der Kontrolle von LokalPix.
• Browser-Decoder können Sicherheitsfehler enthalten; Größenprüfungen reduzieren Risiken, ersetzen aber keine Browser-Updates.
• Die SVG-Prüfung ist eine vorsichtige Ablehnungslogik, keine formale Sicherheitszertifizierung jedes denkbaren SVG-Inhalts.
• Quell-EXIF-, IPTC- und XMP-Felder werden vom Anwendungscode standardmäßig nicht kopiert; die Rasterausgabe wird über Canvas neu codiert. Es gibt keine nachgelagerte Byte-Prüfung, Browser können eigene Metadaten erzeugen, und sichtbare beziehungsweise in Pixel eingebrannte Informationen bleiben erhalten. Wenn die Oberfläche bei JPEG-Ausgaben das Beibehalten von EXIF erlaubt und diese Option bewusst gewählt wird, ändert dies das Standardverhalten.
• Die Ausgabequalität hängt vom Browser, Eingabeformat und gewählten Qualitätswert ab.
• Die technische Beschreibung ersetzt weder Datenschutz-Folgenabschätzung noch Rechtsprüfung, sofern eine solche im konkreten Einsatz erforderlich ist.

Empfohlene Prüfschritte

1. Browser-Netzwerkprotokoll öffnen: Einen Erstbesuch mit leeren Browserdaten, einen Wiederholungsbesuch, den direkten Aufruf der Technikseite und einen Offline-Fall getrennt prüfen. Danach ein Bild auswählen und konvertieren; während Auswahl und Konvertierung darf keine Anfrage mit Bildinhalt erscheinen.
2. Anfragen kontrollieren: Zulässig sind nur Ressourcen der eigenen Herkunft und lokale blob:-URLs. Es dürfen keine Drittanbieter-Domains erscheinen.
3. Server-Routen prüfen: Der Quellcode in server.mjs enthält keinen Upload-Endpunkt. Neben GET und HEAD existiert ausschließlich POST /api/convert für den aggregierten Zähler; dabei den nicht persistierten In-Memory-IP-Schlüssel für das Rate-Limit mitprüfen.
4. Konvertierungslogik prüfen: public/app.mjs dekodiert, zeichnet und codiert die Bilder ausschließlich über Browser-APIs.
5. Statistik prüfen: stats-store.mjs sowie die produktive Statistikdatei auf reguläre Zählerfelder, unerwartete Zusatzfelder, Dateirechte, Backups und administrative Löschung prüfen.
6. Service Worker prüfen: public/sw.js darf nur Anwendungsdateien, niemals ausgewählte Bilddateien, vorab cachen. Auch Cache-Persistenz und präfixgebundene Bereinigung prüfen.
7. Produktionsumgebung prüfen: Reverse-Proxy-Konfiguration, Zugriffsprotokolle, TLS, Firewall, Backups, Benutzerrechte und Anbietervereinbarungen separat dokumentieren.
8. Regressionstests ausführen: npm test und npm run test:e2e prüfen Kernfunktionen, Sicherheitsgrenzen und den Browserablauf.

Dokumentationsstand: September 2026 · Technische Beschreibung Version 1.7