CSP wurde am 2026-08-10 versucht (next.config.ts, buildCsp()-Funktion existiert bereits, ist aber NICHT verdrahtet). Live-Test hat die komplette App weiss gerendert - ClerkProvider (umschliesst layout.tsx) crasht uncaught, wenn eine Ressource blockiert wird. Hinzufuegen von wss://clerk.pawfeed.org zu connect-src hat es NICHT behoben, echte Ursache unklar. Laut User gibt es einen dokumentierten Clerk-Workaround dafuer - Research noetig bevor ein neuer Versuch gestartet wird. Empfehlung: erst als Content-Security-Policy-Report-Only mit einem /api/csp-report Endpoint ausliefern, um echte Verletzungen zu sehen, bevor scharf geschaltet wird.
CSP wurde am 2026-08-10 versucht (next.config.ts, buildCsp()-Funktion existiert bereits, ist aber NICHT verdrahtet). Live-Test hat die komplette App weiss gerendert - ClerkProvider (umschliesst layout.tsx) crasht uncaught, wenn eine Ressource blockiert wird. Hinzufuegen von wss://clerk.pawfeed.org zu connect-src hat es NICHT behoben, echte Ursache unklar. Laut User gibt es einen dokumentierten Clerk-Workaround dafuer - Research noetig bevor ein neuer Versuch gestartet wird. Empfehlung: erst als Content-Security-Policy-Report-Only mit einem /api/csp-report Endpoint ausliefern, um echte Verletzungen zu sehen, bevor scharf geschaltet wird.
Nachtrag, weil das nie hier kommentiert wurde: Der ursprüngliche Versuch (hand-gerollter buildCsp()-Entwurf in next.config.ts) hat die App komplett weiß gerendert — ClerkProvider crasht uncaught, wenn eine Ressource beim Init geblockt wird. Root Cause: kein 'unsafe-inline'/Nonce für script-src, wodurch Next.js' eigenes Hydration-Script blockiert wurde.
Gelöst über Clerks eigene contentSecurityPolicy-Option in clerkMiddleware() (src/proxy.ts) statt des hand-gerollten Entwurfs — die bringt die nötigen Direktiven für Next.js' Hydration automatisch mit. Aktuell reportOnly: true, Violations landen über /api/csp-report (rate-limitiert, normalisiert beide Report-Formate — legacy report-uri und Reporting-API report-to —, leitet an GlitchTip/Sentry weiter, blockt nie den Request).
Bewusst noch nicht scharf geschaltet (reportOnly: false) — erst nach einer sauberen Beobachtungsphase ohne echte Violations in GlitchTip umstellen, nie direkt live testen. Das ist der einzige noch offene Schritt, falls „erledigt" auch die Enforce-Umstellung meint — ansonsten ist der aktuelle Report-Only-Stand der gewünschte Endzustand für jetzt.
## CSP läuft — Report-Only-Modus (Commit `1351358`, deployed)
Nachtrag, weil das nie hier kommentiert wurde: Der ursprüngliche Versuch (hand-gerollter `buildCsp()`-Entwurf in `next.config.ts`) hat die App komplett weiß gerendert — `ClerkProvider` crasht uncaught, wenn eine Ressource beim Init geblockt wird. Root Cause: kein `'unsafe-inline'`/Nonce für `script-src`, wodurch Next.js' eigenes Hydration-Script blockiert wurde.
Gelöst über Clerks eigene `contentSecurityPolicy`-Option in `clerkMiddleware()` (`src/proxy.ts`) statt des hand-gerollten Entwurfs — die bringt die nötigen Direktiven für Next.js' Hydration automatisch mit. Aktuell **`reportOnly: true`**, Violations landen über `/api/csp-report` (rate-limitiert, normalisiert beide Report-Formate — legacy `report-uri` und Reporting-API `report-to` —, leitet an GlitchTip/Sentry weiter, blockt nie den Request).
**Bewusst noch nicht scharf geschaltet** (`reportOnly: false`) — erst nach einer sauberen Beobachtungsphase ohne echte Violations in GlitchTip umstellen, nie direkt live testen. Das ist der einzige noch offene Schritt, falls „erledigt" auch die Enforce-Umstellung meint — ansonsten ist der aktuelle Report-Only-Stand der gewünschte Endzustand für jetzt.
Entscheidung: Report-Only bleibt vorerst so. Erst abwarten, bis sich in GlitchTip genug CSP-Violation-Reports angesammelt haben, um sie sinnvoll zu prüfen — dann erst über eine Umstellung auf reportOnly: false (scharf) entscheiden.
**Entscheidung:** Report-Only bleibt vorerst so. Erst abwarten, bis sich in GlitchTip genug CSP-Violation-Reports angesammelt haben, um sie sinnvoll zu prüfen — dann erst über eine Umstellung auf `reportOnly: false` (scharf) entscheiden.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
CSP wurde am 2026-08-10 versucht (next.config.ts, buildCsp()-Funktion existiert bereits, ist aber NICHT verdrahtet). Live-Test hat die komplette App weiss gerendert - ClerkProvider (umschliesst layout.tsx) crasht uncaught, wenn eine Ressource blockiert wird. Hinzufuegen von wss://clerk.pawfeed.org zu connect-src hat es NICHT behoben, echte Ursache unklar. Laut User gibt es einen dokumentierten Clerk-Workaround dafuer - Research noetig bevor ein neuer Versuch gestartet wird. Empfehlung: erst als Content-Security-Policy-Report-Only mit einem /api/csp-report Endpoint ausliefern, um echte Verletzungen zu sehen, bevor scharf geschaltet wird.
CSP läuft — Report-Only-Modus (Commit
1351358, deployed)Nachtrag, weil das nie hier kommentiert wurde: Der ursprüngliche Versuch (hand-gerollter
buildCsp()-Entwurf innext.config.ts) hat die App komplett weiß gerendert —ClerkProvidercrasht uncaught, wenn eine Ressource beim Init geblockt wird. Root Cause: kein'unsafe-inline'/Nonce fürscript-src, wodurch Next.js' eigenes Hydration-Script blockiert wurde.Gelöst über Clerks eigene
contentSecurityPolicy-Option inclerkMiddleware()(src/proxy.ts) statt des hand-gerollten Entwurfs — die bringt die nötigen Direktiven für Next.js' Hydration automatisch mit. AktuellreportOnly: true, Violations landen über/api/csp-report(rate-limitiert, normalisiert beide Report-Formate — legacyreport-uriund Reporting-APIreport-to—, leitet an GlitchTip/Sentry weiter, blockt nie den Request).Bewusst noch nicht scharf geschaltet (
reportOnly: false) — erst nach einer sauberen Beobachtungsphase ohne echte Violations in GlitchTip umstellen, nie direkt live testen. Das ist der einzige noch offene Schritt, falls „erledigt" auch die Enforce-Umstellung meint — ansonsten ist der aktuelle Report-Only-Stand der gewünschte Endzustand für jetzt.Entscheidung: Report-Only bleibt vorerst so. Erst abwarten, bis sich in GlitchTip genug CSP-Violation-Reports angesammelt haben, um sie sinnvoll zu prüfen — dann erst über eine Umstellung auf
reportOnly: false(scharf) entscheiden.