Sichere Header für Web‑Apps: CSP, HSTS, Framing und Schnelltests

Warum sichere Header wichtig sind (und warum sie manchmal Apps kaputtmachen)

„Browser-Hardening“ läuft oft auf ein paar Response-Header hinaus, die dem Browser sagen, riskantes Verhalten zu verweigern. Ihre App kann trotzdem Fehler haben, aber der Browser bekommt klarere Regeln, was er laden darf, wo er eingebettet werden darf und ob er jemals auf unverschlüsseltes HTTP zurückfallen darf.

Deshalb kann eine App in der Entwicklung noch gut aussehen und dann in einer Produktions-Security-Review durchfallen. In Dev sind Sie meist auf localhost, haben weniger Drittanbieter-Skripte und lockere Defaults. In Produktion kommen echte Domains, CDNs, Analytics, Payment-Widgets und SSO dazu. Genau diese Extras können von Security-Headern blockiert werden, wenn Sie sie zu aggressiv setzen.

Bei gut konfigurierten Headern reduzieren sie häufige Risiken wie XSS, das zu Kontoübernahmen führt, Clickjacking (Ihre App wird eingebettet, um Nutzer zu täuschen), HTTPS-Downgrade-Angriffe und Datenlecks an unerwartete Drittanbieter.

Der Haken: ein einziger „falscher“ Header kann wichtige Abläufe kaputtmachen. Eine strikte Content Security Policy (CSP) kann das Skript blockieren, das Ihren Login-Button rendert, das iFrame, das Ihr Payment-Provider nutzt, oder ein Analytics-Tag, das nach Consent lädt. HSTS kann Teams ebenfalls überraschen: schalten Sie es ein, bevor HTTPS wirklich sauber läuft, sperren Sie Nutzer kurzfristig auf HTTPS und die Seite kann für diese Nutzer „down“ aussehen.

Ein realistisches Beispiel: ein KI-generiertes Prototype funktioniert in einer Preview-URL, aber in Produktion kommt eine Custom-Domain und echtes Auth dazu. Dann blockiert CSP das Auth-Callback-Skript oder Framing-Regeln verhindern den eingebetteten Checkout. FixMyMess sieht das oft, weshalb Header schrittweise eingeführt werden sollten und nicht einfach per Schalter anschalten und vergessen.

Die drei Header, die meist gemeint sind: CSP, HSTS und Framing

Die meisten Gespräche über Security-Header laufen auf drei Kontrollen hinaus, die zu drei Risiken passen:

• Steuern, was der Browser ausführen darf (CSP)
• Steuern, wie der Browser sich verbindet (HSTS)
• Steuern, wo Ihre Seiten erscheinen dürfen (X-Frame-Options oder CSP frame-ancestors)

1) CSP (Content-Security-Policy)

CSP sagt dem Browser, welche Skripte, Styles, Bilder und Verbindungen erlaubt sind. Die Hauptaufgabe ist, den Schaden durch XSS zu begrenzen, indem unerwarteter Code blockiert wird.

Es ist auch der Header, der am wahrscheinlichsten zuerst Dinge kaputtmacht, besonders Analytics-Tags, Inline-Skripte und Drittanbieter-Widgets.

2) HSTS (Strict-Transport-Security)

HSTS sagt dem Browser, für eine bestimmte Zeit immer HTTPS für Ihre Seite zu verwenden. Es schützt Nutzer vor SSL-Striping und versehentlichem HTTP-Zugriff, indem es verschlüsselte Verbindungen erzwingt.

Aktivieren Sie es nur, wenn Ihre App vollständig über HTTPS läuft. Sobald ein Browser HSTS für Ihre Domain gecached hat, können Sie das für diesen Nutzer nicht schnell rückgängig machen.

3) Framing-Schutz (X-Frame-Options und frame-ancestors)

Framing-Header steuern, ob andere Seiten Ihre Seiten in einem iframe einbetten dürfen. Sie wehren Clickjacking ab, indem sie verhindern, dass eine bösartige Seite Ihre UI unter einer falschen Überlagerung platziert.

Sie sehen zwei Optionen:

• X-Frame-Options: älter und einfach (DENY oder SAMEORIGIN)
• frame-ancestors (innerhalb von CSP): moderner, flexibler und meist vorzuziehen, wenn Sie bereits CSP nutzen

Wenn Ihre App nie eingebettet werden sollte, ist ein Default „kein Framing“ meistens richtig. Wenn Sie sie bewusst einbetten (z. B. in einem Partner-Portal), behandeln Sie das als eine sorgfältige Allowlist-Entscheidung.

CSP-Grundlagen ohne Fachjargon

CSP ist der Header, der dem Browser sagt, was Ihre Seite laden und ausführen darf. Er ist auch der, der am ehesten plötzlich für Ausfälle sorgt, weil er JavaScript blockieren kann, das bisher frei lief.

Stellen Sie sich CSP wie einen Türsteher vor. Skripte, Styles, Bilder, Fonts und Frames dürfen nur rein, wenn sie den Regeln entsprechen. Wenn Ihre App auf ein Inline-Snippet, ein Analytics-Tag oder ein Widget eines Drittanbieters angewiesen ist, stoppt CSP das, bis Sie es explizit erlauben.

Zwei Direktiven tauchen ständig auf:

• default-src ist die Fallback-Regel. Wenn Sie sie eng setzen, wird alles geblockt, das nicht durch eine spezifischere Regel abgedeckt ist.
• script-src steuert, von wo Skripte geladen werden und welche Ausführungsarten erlaubt sind. Hier treten Probleme meist zuerst auf.

Die meisten Überraschungen entstehen durch dieselben Muster:

• Inline-Skripte (Code im HTML) werden geblockt, es sei denn, Sie nutzen Nonce/Hash oder erlauben 'unsafe-inline' (keine gute langfristige Lösung).
• eval() und ähnliche dynamische Pfade werden geblockt, es sei denn, Sie erlauben 'unsafe-eval' (kommt bei älteren Bibliotheken und Tools vor).
• Drittanbieter-Tags (Chat, Analytics, A/B-Testing) laden von Domains, die Sie nicht erlaubt haben, oder sie injizieren Inline-Code.

Ein sicherer erster Schritt ist Content-Security-Policy-Report-Only. Der Browser meldet Verstöße, blockiert aber nichts — so sehen Sie, was brechen würde, bevor es echte Nutzer tut.

Ein schnelles Beispiel: wenn ein Lovable- oder Replit-Prototyp „funktioniert“, weil er auf Inline-Skripte setzt, zeigt Report-Only das sofort. Teams bringen solche Befunde oft zu FixMyMess, sodass riskante Muster durch Nonce-basierte Skripte ersetzt und versteckte eval()-Nutzung entfernt werden kann, ohne dass sich das Verhalten der App ändert.

CSP-Einstellungen, mit denen Sie starten können (und dann verschärfen)

CSP ist einer der nützlichsten Header und gleichzeitig einer der einfachsten Wege, eine funktionierende UI an Tag eins kaputtzumachen, wenn Sie zu strikt sind. Beginnen Sie mit einer Policy, die das Schlimmste blockiert, und verschärfen Sie sie, während Sie lernen, was Ihre App tatsächlich lädt.

Hier ein vernünftiges "Starter"-CSP, das für typische Apps (insbesondere SPAs) oft funktioniert und trotzdem Schutz bietet:

Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; img-src 'self' data: https:; font-src 'self' https: data:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline' https:; connect-src 'self' https:; upgrade-insecure-requests

Das erlaubt weiterhin riskantes Verhalten ('unsafe-inline' und 'unsafe-eval'), damit Ihre App weniger wahrscheinlich auseinanderfällt. Das Ziel ist, diese Erlaubnisse sicher zu entfernen — eine Änderung nach der anderen.

Schrittweise verschärfen

Machen Sie eine Änderung, deployen Sie und beobachten Sie dann Fehlermeldungen in der Browser-Konsole.

• Fixieren Sie zuerst Skripte: Ersetzen Sie 'unsafe-inline' durch Nonces und entfernen Sie 'unsafe-eval', wenn möglich.
• Engen Sie connect-src ein: Lassen Sie nur die APIs und Drittanbieter-Endpunkte zu, die Sie tatsächlich nutzen.
• Begrenzen Sie img-src und font-src: Behalten Sie https:, wenn Sie CDNs nutzen; entfernen Sie data:, wenn Sie es nicht brauchen.
• Wenn Sie etwas einbetten müssen (Zahlungen, Docs), setzen Sie Framing-Regeln gezielt statt alles zu lockern.

Nonces vs. Hashes (eine einfache Regel)

Verwenden Sie Nonces, wenn Ihre HTML-Templates Inline-Skripte zur Laufzeit generieren (häufig bei server-gerenderten Apps). Verwenden Sie Hashes, wenn das Inline-Snippet stabil ist und sich selten ändert.

Für Analytics-, Zahlungs- und Support-Widgets rechnen Sie damit, Domains zu script-src und connect-src hinzuzufügen. Wenn ein KI-generierter Prototyp unordentliche Inline-Skripte hat, brauchen Sie oft erst eine kurze Cleanup-Phase (ein häufiger FixMyMess-Auftrag), bevor CSP ohne Überraschungen verschärft werden kann.

HSTS: HTTPS schützen ohne sich auszusperren

HSTS sagt dem Browser: „Verwende immer HTTPS für diese Seite.“ Nachdem ein Browser den Header einmal gesehen hat, schreibt er zukünftige Besuche auf HTTPS um, selbst wenn jemand http:// eintippt oder auf einen alten Link klickt. Das ist gut, um Downgrades zu verhindern, kann Sie aber auch sperren, wenn Ihre HTTPS-Setups fehlerhaft sind.

Sobald ein Browser HSTS für Ihre Domain merkt, können Sie das für diesen Nutzer nicht schnell rückgängig machen. Wenn HTTPS morgen ausfällt (abgelaufenes Zertifikat, schlechter Redirect, falsch konfigurierte Load-Balancer), kommen diese Nutzer möglicherweise nicht mehr auf die Seite, bis das Problem behoben ist.

Warten Sie mit HSTS, wenn eines dieser Dinge noch zutrifft:

• Sie haben Mixed Content (HTTP-Bilder, -Skripte oder -API-Aufrufe), den Sie noch nicht bereinigt haben.
• Redirects sind auf verschiedenen Seiten inkonsistent.
• Staging teilt dieselbe Domain oder Subdomains, die Nutzer in einem echten Browser besuchen könnten.
• Sie testen noch Zertifikate, CDN-Einstellungen oder Custom-Domains.

Ein sicherer Startpunkt ist eine kleine max-age (1 Stunde bis 1 Tag). Nach ein paar sauberen Deploys erhöhen Sie auf eine Woche, dann auf einen Monat und schließlich auf 6–12 Monate, sobald Sie sich sicher sind.

Seien Sie vorsichtig mit zwei Flags:

• includeSubDomains bedeutet, jede Subdomain muss HTTPS unterstützen (Admin, API, alte Landingpages, vergessene Hobby-Subdomains).
• preload ist ein noch größeres Commitment. Es passt zu reifen Domains mit permanentem HTTPS, nicht zu Prototypen.

Wenn Sie eine AI-erstellte App übernehmen, verifizieren Sie Redirects und Mixed Content zuerst. Teams fragen FixMyMess oft danach, weil ein falscher Header in einem wackeligen Prototyp einen kleinen Bug in einen Ausfall verwandeln kann.

Framing-Schutz: X-Frame-Options und frame-ancestors

Clickjacking passiert, wenn Ihre App in einem versteckten oder irreführenden Frame auf einer anderen Seite geladen wird. Der Nutzer denkt, er klickt einen harmlosen Button, tatsächlich klickt er Ihren darunterliegenden „Account löschen“- oder „Überweisen“-Button.

Um das zu stoppen, nutzen Sie X-Frame-Options und/oder CSP frame-ancestors. X-Frame-Options ist älter und eingeschränkt. Es kann „deny“ (nie einbetten) oder „sameorigin“ (nur gleiche Origin) sagen. frame-ancestors ist die moderne Wahl, weil es präzise Allowlists erlaubt.

Ein sicherer Default für die meisten Apps ist: kein Framing erlauben. Wenn es einen echten Grund zum Einbetten gibt, halten Sie die Erlaubnis eng.

Praktische Muster:

• Keine Embeds: frame-ancestors 'none'
• Nur Ihre Seite: frame-ancestors 'self'
• Ihre Seite plus ein vertrauenswürdiger Host: frame-ancestors 'self' https://partner.example
• X-Frame-Options als Backup: DENY oder SAMEORIGIN

Schnelltest: Laden Sie eine sensitive Seite in einem iframe in einer einfachen HTML-Datei. Wenn sie noch gerendert wird, funktioniert der Framing-Schutz nicht. Das ist bei AI-generierten Prototypen häufig, weil Templates diese Header oft vergessen oder nicht konsistent über Routen anwenden.

Schritt für Schritt: Header mit minimalem Risiko ausrollen

Der sicherste Weg, Security-Header hinzuzufügen, ist mit einem Baseline-Set zu starten, das wenig ändert, zu beweisen, dass nichts kaputtgeht, und dann eine Regel nach der anderen zu verschärfen. Behandeln Sie es wie ein Feature-Release, nicht wie eine schnelle Konfig-Änderung.

1) Baseline hinzufügen, dann verschärfen

Eine praktische Reihenfolge:

• Setzen Sie Framing-Schutz zuerst (am wenigsten wahrscheinlich, Skripte zu brechen).
• Fügen Sie HSTS vorsichtig hinzu (erst wenn HTTPS überall sauber ist).
• Fügen Sie eine grundlegende CSP hinzu, die aktuelle Skripte erlaubt, und entfernen Sie unsichere Erlaubnisse schrittweise.
• Testen Sie kritische Flows (Login, Checkout, Uploads, Embeds) nach jeder Änderung.
• Dokumentieren Sie Ausnahmen mit Begründung und Besitzer.

2) Wählen Sie einen Ort, um Header zu setzen

Sie können Header im App-Server (Express, Rails, Django), im Reverse-Proxy (Nginx) oder in den Einstellungen Ihrer Hosting-Plattform setzen. Wählen Sie eine Single Source of Truth. Wenn Header an mehreren Stellen definiert sind, liefern Sie irgendwann widersprüchliche Werte und verschwenden Stunden damit, herauszufinden, welche Werte der Browser tatsächlich sieht.

3) Rollout wie ein Feature

Wenden Sie Änderungen zuerst in Staging an, dann auf einen kleinen Traffic-Slice oder in einer begrenzten Umgebung, bevor Sie global ausrollen. Halten Sie eine schnelle Rollback-Option bereit (eine Konfig-Änderung, nicht ein Redeploy), damit Sie schnell wiederherstellen können, falls ein Drittanbieter-Skript oder ein OAuth-Redirect scheitert.

4) Dokumentieren Sie Ausnahmen, damit sie sich nicht ausbreiten

Wenn Sie etwas erlauben müssen (ein Script-Host, ein Inline-Snippet, ein iFrame), schreiben Sie auf, was es ermöglicht, warum es nötig ist und was es später ersetzen würde. Sonst werden „temporäre“ Ausnahmen dauerhaft.

Wenn Sie einen AI-generierten Prototyp übernommen haben, bringen diese Header oft versteckte Probleme schnell ans Licht. FixMyMess kann eine schnelle Prüfung durchführen und Ihnen helfen, Header sicher hinzuzufügen, ohne Produktion zu zerbrechen.

Wie man schnell testet (und versteht, was gebrochen ist)

Schnelles Testen schlägt Raten. Bestätigen Sie zuerst, dass der Browser die Header erhält. Schauen Sie dann, was der Browser geblockt hat.

Zuerst in DevTools prüfen

Öffnen Sie Ihre Seite und DevTools:

• Network: Klicken Sie die Haupt-Dokument-Anfrage und prüfen Sie die Response Headers auf CSP, HSTS und Framing.
• Console: CSP-Verstöße erscheinen mit Meldungen wie „Refused to load...“ plus der geblockten URL und der Direktive (z. B. script-src).
• Security-Panel (in den meisten Browsern): Bestätigen Sie HTTPS und sehen Sie Zertifikatsdetails ein.
• Application-Panel: Prüfen Sie, ob HSTS greift.

Wenn nach einer CSP-Änderung etwas kaputtgeht, ist die Konsolenmeldung Ihre Karte. Ordnen Sie das geblockte Element der Direktive zu:

• Geblocktes Script oder Inline-Code -> script-src
• Geblockter API-Call -> connect-src
• Geblocktes Bild/Font -> img-src oder font-src

Beispiel: Wenn Login nicht mehr funktioniert und die Konsole meldet, dass eine Anfrage an https://api.yourapp.com von connect-src geblockt wurde, erlauben Sie diesen Host in connect-src (nicht alles lockern).

Schnelle Kommandozeilen-Checks

Diese Prüfungen bestätigen Redirects, HTTPS und dass Header wirklich vom Server gesendet werden (und nicht irgendwo konfiguriert sind, das Sie gerade umgehen):

curl -I http://yourdomain.com
curl -I https://yourdomain.com
curl -I -L https://yourdomain.com

Achten Sie auf:

• Strict-Transport-Security nur in HTTPS-Antworten
• dass die finale Antwort nach Redirects (mit -L) noch Ihre Header enthält

Um Framing-Blockierung ohne Spezialtools zu prüfen, erstellen Sie eine winzige HTML-Datei, die Ihre Seite in ein iframe lädt, und öffnen Sie sie lokal. Bleibt das iframe leer oder zeigt einen Fehler, funktioniert Ihre Framing-Policy.

Wenn Sie Hilfe beim Interpretieren von Violation-Logs oder beim Reparieren eines Prototyps brauchen, der nach Header-Verschärfung kaputtging, kann FixMyMess den Code auditieren und schnelle, sichere Fixes anwenden.

Häufige Fehler, die Ausfälle oder falsche Sicherheit erzeugen

Die meisten Probleme mit Security-Headern sind keine „Sicherheitsprobleme“, sondern Rollout-Probleme. Eine kleine Änderung kann Skripte blockieren, Logins zerstören oder echte Probleme hinter einer schnellen Workaround-Lösung verstecken.

CSP-Fehler, die echte Features kaputtmachen

Die schnellste Art, ein Frontend lahmzulegen, ist eine strikte CSP zu erzwingen, bevor Sie inventarisiert haben, was die Seite tatsächlich lädt. Inline-Skripte, Inline-Event-Handler (wie onclick), Drittanbieter-Widgets und injizierte Analytics-Tags gibt es oft selbst in „einfachen“ Apps.

Typische Fallen:

• Strikte CSP durchsetzen, bevor Sie Inline-Skripte und Drittanbieter-Quellen inventarisiert haben
• 'unsafe-inline' und breite Wildcards nutzen, damit es „funktioniert“, und dann nie verschärfen
• connect-src aus Versehen blockieren, sodass API-Aufrufe fehlschlagen und es so aussieht, als wäre das Backend down

Ein sichereres Muster ist: mit Reporting starten, die lautesten Verursacher beheben und dann zur Durchsetzung übergehen. Bei Prototypen ist es oft schneller, Inline-Skripte in echte JS-Dateien zu überführen, als immer neue Ausnahmen hinzuzufügen.

HSTS- und Framing-Fallen

HSTS ist super, bis es auf einer Domain gesetzt wird, die irgendwo noch HTTP ausliefert (alte Subdomains, ein vergessenes Admin-Panel, ein Staging-Host). Wenn Browser HSTS cachen, hilft „einfach zurückschalten“ betroffenen Nutzern nicht schnell.

Framing-Schutz kann ebenfalls verwirren. X-Frame-Options hilft, aber moderne Kontrolle ist meist frame-ancestors in CSP. Wenn Sie Ihre App in einer anderen Seite einbetten (Zahlungen, Partner-Portale, interne Tools), kann eine strikte Einstellung diesen Flow brechen.

Ein weiterer Ausfalltreiber: CORS mit CSP verwechseln. CORS-Fehler betreffen das Lesen cross-site; CSP-Fehler betreffen, was die Seite laden oder ausführen darf. Die falsche Jagd nach dem Problem kostet Stunden.

Wenn Sie AI-generierten Code übernommen haben, häufen sich diese Probleme schnell. FixMyMess sieht oft Teams, die Symptome „fixen“, indem sie Schutzmechanismen deaktivieren, statt Inline-Skripte zu entfernen, Quellen aufzuräumen und Secrets aus dem Client zu verlagern. Das führt zu einem grünen Häkchen, aber nicht zu echter Härtung.

Schnelle Checkliste bevor Sie in Produktion gehen

Bevor Sie diese Header in Produktion aktivieren, machen Sie einen schnellen Durchlauf, um die „funktioniert auf einer Seite“-Falle zu vermeiden. Header helfen nur, wenn sie konsistent sind und Nutzer nicht mit kaputten Logins, hängenden Redirects oder leeren Seiten überrascht werden.

• Stichproben: normale Seiten, API-Antworten, Redirects (301/302) und Fehlerseiten (404/500). Bestätigen Sie, dass die Header auf allen auftauchen.
• Laden Sie Ihre App und prüfen Sie auf Mixed Content-Warnungen (HTTP-Bilder, -Skripte oder -Fonts auf einer HTTPS-Seite).
• Starten Sie CSP in Report-Only, beheben Sie die lautesten Punkte, dann erzwingen.
• Blockieren Sie Framing standardmäßig und erlauben Sie es nur mit klarer Begründung.
• HSTS erst aktivieren, wenn HTTPS überall stabil ist, inklusive Subdomains und typischer Einstiegsseiten wie Marketing-Pages und Callback-URLs.

Zwei schnelle Tests:

# Check headers on a normal page
curl -I https://yourdomain.com/

# Check headers on a redirect target too
curl -I -L https://yourdomain.com/login

Im Browser: DevTools Console öffnen und neu laden. Wenn CSP zu streng ist, sehen Sie meist klare Meldungen, was geblockt wurde.

Ein verbreiteter Real-World-Gotcha: die Homepage hat CSP, aber der Login-Redirect oder der 404-Handler wird von einer anderen Schicht (CDN, Framework-Default) bedient, sodass Header stillschweigend verschwinden.

Bei AI-generierten Prototypen sind solche Inkonsistenzen besonders häufig. Ein kurzer Audit einiger Schlüsselrouten verhindert, dass ein "sicheres" Release nur auf dem Happy-Path sicher ist.

Beispiel: Header in einem Prototyp verschärfen, ohne ihn zu zerstören

Sie übernehmen einen AI-generierten Prototyp (z. B. von Bolt oder Replit). Er funktioniert in der Demo, aber er verlässt sich auf Inline-Skripte im HTML, ein Drittanbieter-Chat-Widget, das in die Seite gepastet wurde, und ein paar Tracking-Skripte, die nachts hinzugefügt wurden.

Wenn Sie sofort eine strikte CSP durchsetzen, kann die App auf den ersten Blick "ok" wirken, bis Sie reale Flows testen. Typische Ausfälle: der Login-Redirect klappt nicht, weil ein Inline-Skript nicht läuft, das Chat-Widget bleibt leer, weil seine Skripte und Frames blockiert werden, und Analytics sendet keine Events mehr, genau dann, wenn Sie sie brauchen.

Ein Rollout-Plan, der die meisten Überraschungen vermeidet:

• Beginnen Sie mit Content-Security-Policy-Report-Only, sodass nichts geblockt wird.
• Nutzen Sie Console- und CSP-Reports, um aufzulisten, was die App tatsächlich lädt.
• Ersetzen Sie Inline-Skripte durch externe Dateien, wo möglich, oder fügen Sie Nonces für die, die Sie behalten müssen.
• Fügen Sie Chat- und Analytics-Domains explizit hinzu (nur die, die Sie nutzen).
• Erzwingen Sie CSP erst, wenn die wichtigsten Nutzerwege (Login, Checkout, Einstellungen) sauber funktionieren.

Danach kann Ihr Header-Set auf hoher Ebene einfach bleiben:

• CSP: default block, dann erlauben Sie Ihre eigenen Skripte plus eine kurze Allowlist für benötigte Vendoren; nutzen Sie Nonces für verbleibende Inline-Codes.
• HSTS: mit angemessener max-age aktivieren, wenn HTTPS überall stabil ist.
• Framing: Einbetten blockieren (oder nur Ihre Origin erlauben) mittels frame-ancestors.

Nächste Schritte: Sicherheit beibehalten, während die App sich verändert

Security-Header sind kein "einmal setzen". Jede neue Route, jedes Analytics-Tag, jedes Chat-Widget, jedes Payment-Skript oder CDN-Änderung kann verschieben, was der Browser erlauben muss.

Halten Sie eine kurze "Header-Policy"-Notiz neben Ihren Deployment-Notes: was Ihre CSP erlauben soll (Skripte, Styles, Frames), ob HSTS aktiv ist und ob Ihre App jemals gerahmt werden darf (meistens nein). Das klingt simpel, verhindert aber Panik-Edits, wenn etwas bricht.

Überprüfen Sie Ihre Header, wann immer Sie Drittanbieter-Skripte hinzufügen, und ziehen Sie eine kurze monatliche Prüfung in Betracht. Die meisten Ausfälle entstehen durch „nur einen Snippet".

Wenn Ihre App von Tools wie Lovable, Bolt, v0, Cursor oder Replit generiert wurde, rechnen Sie mit versteckten Inline-Skripten und unsicheren Mustern. Diese üben Druck auf Teams aus, riskante CSP-Einstellungen wie Inline-Erlaubnis zu nutzen. Betrachten Sie diesen Druck als Code-Geruch: Bereinigen Sie den Code, damit Sie die Policy verschärfen können.

Wenn Sie eine zweite Meinung wollen: FixMyMess (fixmymess.ai) bietet ein kostenloses Code-Audit für AI-generierte Apps an. Das ist ein schneller Weg, die Header-Probleme zu finden, die in Produktion brechen werden, und dann den zugrunde liegenden Code (Auth, Secrets, chaotische Skripte) zu reparieren, sodass Sicherheitsregeln sicher durchgesetzt werden können.