Audit des Creator Workspace, App-Symbole fuer alle Apps der Domain

AUDIT (Auftrag: vollstaendiger Durchgang, Fehler direkt beheben)

Ausgangslage waren 40 Pruefungen mit 1616 Einzelpunkten, alle gruen.
Acht neue Pruefungen kamen dazu; sie haben gefunden, was die alten nicht
sehen konnten.

Der schwerste Fund: Die Zugangsschranke verglich req.path EXAKT gegen
eine Liste. Express raeumt Punkt-Segmente selbst weg, mehrfache
Schraegstriche aber nicht. Damit kam //workspace/start.html OHNE
Anmeldung mit HTTP 200, und ein Creator bekam ueber
/workspace//personen.html die Verwaltungsseite. Die DATEN waren nie
betroffen (nachgemessen: 404 bzw. 401). Behoben durch Normalisierung
UND eine Umkehr der Logik -- jetzt ist jede .html geschuetzt ausser der
Anmeldeseite, statt nur die in der Liste. Eine vergessene neue Seite
steht damit nicht mehr versehentlich offen.

Weiter behoben:
  * Kaputter/abgebrochener Rumpf ergab 500 in HTML statt 400 in JSON --
    die Oberflaeche ruft ueberall a.json() und lief in einen zweiten
    Fehler; der Knopf hing ohne Meldung.
  * POST /zustand/sichern war der einzige von 60 schreibenden Wegen
    ohne Herkunftspruefung.
  * workspace-sicherung.js gab interne Pfade in Fehlermeldungen nach
    aussen; alle 23 anderen Module antworten neutral.
  * admin_notiz war als einziges von 14 Feldern ohne <label>.
  * Der aktive Filter hatte keinen sichtbaren Fokus (CSS-Spezifitaet
    0,3,0 schlug 0,2,0) -- genau der Knopf, auf dem man steht.
  * h1 -> h3 ohne Zwischenstufe auf zwei Seiten.
  * HSTS ging auch ueber http mit (RFC 6797, 7.2 verbietet das).
  * upgrade-insecure-requests galt auch auf 127.0.0.1 -- dadurch war
    WebKit/Safari ueberhaupt nicht pruefbar, also der Browser, den
    jedes iPhone benutzt.
  * pruef-grosscheck las readdirSync(".") und pruefte aus server/
    gestartet NULL oeffentliche Seiten -- meldete aber "ok".

Neue Pruefungen: struktur, schranke, haerte, alle-wege,
barrierefrei-workspace, breiten, tempo-workspace, browser.
Jede mit Gegenprobe und mit der geprueften Anzahl in der Bedingung.
Vier davon sind beim Bauen durch die eigene Gegenprobe aufgeflogen und
haetten sonst dauerhaft gruen gemeldet, ohne etwas zu messen.

APP-SYMBOLE (Wunsch: alle Apps der Domain, jede anders, ausser
safeaddress)

Zehn Apps, zehn Stile, zehn in OKLCH gerechnete Farben. Zusammen haelt
sie dasselbe Logo, dieselbe Eckenrundung und eine gemeinsame gedeckte
Farbreihe. Beim Bauen wird gemessen, ob sich das Logo vom Grund abhebt
(19 bis 58 Helligkeitsstufen).

Dabei aufgefallen: Das Kundenportal hatte kein eigenes Manifest und
trug Namen und Symbol der Webdesign-Seite. Der Workspace hatte gar
keins und war als App nicht installierbar. Beide haben jetzt eins.

Geaendert wurde AUSSCHLIESSLICH das Symbol. Ein Zwischenstand hatte
auch die Themenfarben gesetzt; das war mehr als bestellt und wurde
zurueckgenommen.

Werkzeuge: tools/logo-freistellen.mjs, tools/app-symbole.mjs,
tools/app-symbole-einbinden.mjs -- alles im Browser gerechnet, kein
Bildprogramm, keine neue Abhaengigkeit.

Gitea und Nextcloud sind bereits live und nachgeprueft.

Co-Authored-By: Claude Opus 5 <[email protected]>

server/index.js

@@ -54,7 +54,42 @@ app.use((req, res, next) => {
   res.setHeader("X-Frame-Options", "SAMEORIGIN");
   res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");
   res.setHeader("Permissions-Policy", "geolocation=(), microphone=(), camera=(), payment=()");
-  res.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains");
+
+  /* HSTS NUR ÜBER EINE GESICHERTE VERBINDUNG (Befund 04.09.2026, Audit).
+
+     RFC 6797, Abschnitt 7.2, ist an dieser Stelle unmissverständlich:
+     "An HSTS Host MUST NOT include the STS header field in HTTP
+     responses conveyed over non-secure transport."
+
+     Vorher ging der Header bei JEDER Antwort mit, auch über http. Live
+     fällt das nicht auf -- hinter Cloudflare und Caddy kommt ohnehin
+     alles über https an, und `trust proxy` macht `req.secure` dort zu
+     `true`. Aufgefallen ist es beim Browsertest: WebKit (Safari) nimmt
+     den Header auch von einer http-Adresse an, merkt sich 127.0.0.1 als
+     "nur noch https" -- und ab da scheitert jede Verbindung zum lokalen
+     Testserver mit "SSL connect error". Chromium und Firefox machen für
+     localhost eine Ausnahme, WebKit nicht.
+
+     Der Fehler war also nie in der Website zu sehen, hätte aber jede
+     künftige Safari-Prüfung unmöglich gemacht -- und das ist genau der
+     Browser, den jedes iPhone benutzt.
+
+     BEWUSST NICHT NUR `req.secure`. Das wäre die reine Lehre, hängt
+     aber daran, dass Caddy X-Forwarded-Proto wirklich setzt. Sollte das
+     einmal nicht so sein, fiele HSTS auf der echten Domain STILL weg --
+     eine Sicherheitsverschlechterung, die niemandem auffällt. Ein
+     Audit-Fix darf nicht die Möglichkeit schaffen, dass er selbst
+     Schaden anrichtet.
+
+     Deshalb die umgekehrte Bedingung: Weggelassen wird der Header nur
+     dort, wo er nachweislich nicht hingehört -- auf einer unsicheren
+     Verbindung zu einem LOKALEN Namen. Auf der echten Domain geht er
+     immer mit, egal was der Proxy meldet. */
+  const host = (req.get("host") || "").toLowerCase();
+  const lokal = /^(localhost|127\.\d+\.\d+\.\d+|\[::1\]|0\.0\.0\.0)(:\d+)?$/.test(host);
+  if (req.secure || !lokal) {
+    res.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains");
+  }
   next();
 });
 
@@ -213,8 +248,58 @@ app.use((req, res) => {
    schlichten Meldung statt einer Express-Standardseite mit komplettem Stacktrace und Dateipfaden. */
 // eslint-disable-next-line no-unused-vars
 app.use((err, req, res, next) => {
+  /* EIN KAPUTTER RUMPF IST KEIN SERVERFEHLER (Befund 04.09.2026, Audit).
+     Vorher wurde JEDER Fehler zu einer 500 in Text/HTML. Gemessen mit
+     abgeschnittenem JSON ('{"titel": "ab'), wie es bei einer
+     abgebrochenen Verbindung entsteht:
+
+       -> 500 "Es ist ein Fehler aufgetreten. Bitte später erneut versuchen."
+
+     Drei Dinge waren daran falsch. Erstens die Nummer: Der Rumpf kam vom
+     Client, das ist eine 400. Zweitens die ANTWORTART -- die Oberflaeche
+     ruft ueberall `await a.json()` auf; auf Text laeuft sie in einen
+     zweiten Fehler, und der Knopf haengt ohne jede Meldung. Drittens der
+     Rat "spaeter erneut versuchen": Spaeter hilft nie, der Rumpf bleibt
+     kaputt. Dazu stand jedes Mal ein voller Stacktrace im Log, in dem
+     ein echter Fehler untergeht.
+
+     body-parser kennzeichnet diese Faelle selbst (`err.type`), es muss
+     also nichts geraten werden. */
+  const NUTZERFEHLER = new Set([
+    "entity.parse.failed",    // kaputtes JSON
+    "entity.verify.failed",
+    "request.aborted",        // Verbindung mittendrin weg
+    "request.size.invalid",
+    "encoding.unsupported",
+    "charset.unsupported",
+  ]);
+  const istJson = req.path.startsWith("/workspace/api/");
+
+  if (NUTZERFEHLER.has(err?.type)) {
+    /* Bewusst NUR eine Zeile ins Log, kein Stacktrace: Das passiert bei
+       jeder abgebrochenen Verbindung und darf das Protokoll nicht
+       zumuellen -- sonst uebersieht man darin die echten Fehler. */
+    console.warn(`[rumpf] ${req.method} ${req.originalUrl}: ${err.type}`);
+    if (res.headersSent) return;
+    return istJson
+      ? res.status(400).json({ fehler: "Die Anfrage kam unvollständig oder fehlerhaft an." })
+      : res.status(400).send("Die Anfrage kam unvollständig oder fehlerhaft an.");
+  }
+
+  if (err?.type === "entity.too.large") {
+    console.warn(`[rumpf] ${req.method} ${req.originalUrl}: zu gross`);
+    if (res.headersSent) return;
+    return istJson
+      ? res.status(413).json({ fehler: "Die Daten sind zu groß." })
+      : res.status(413).send("Die Daten sind zu groß.");
+  }
+
   console.error(`[fehler] ${req.method} ${req.originalUrl}:`, err?.stack || err);
   if (res.headersSent) return;
+  /* Auch der echte Serverfehler kommt unter /workspace/api als JSON --
+     sonst bricht die Oberflaeche schon am Auswerten der Antwort ab und
+     zeigt gar nichts an, statt "da ging etwas schief". */
+  if (istJson) return res.status(500).json({ fehler: "nicht_verfuegbar" });
   res.status(500).send("Es ist ein Fehler aufgetreten. Bitte später erneut versuchen.");
 });