Im Jahr 2018 erlitt British Airways einen katastrophalen Datenverstoß. Hacker haben die Kreditkartendaten von 380.000 Kunden gestohlen. Sie sind nicht in die Datenbank eingebrochen. Sie haben das Admin-Passwort nicht erraten. Sie haben über eine manipulierte Bibliothek eines Drittanbieters 22 Zeilen JavaScript in die Checkout-Seite eingeschleust. Dieses Skript las stillschweigend Formulareingaben und sendete sie an „baways.com“ (eine gefälschte Domain).

Dies ist ein Supply-Chain-Angriff (insbesondere Formjacking oder Magecart). Der gruselige Teil? Ihre Firewall (WAF) kann es nicht stoppen. Die Anfrage kommt vom Browser des Benutzers, nicht von Ihrem Server.

Der einzige Schutz dagegen ist die Content Security Policy (CSP). CSP ist ein HTTP-Header, der dem Browser mitteilt: „Dies sind die vertrauenswürdigen Domänen. Blockieren Sie alles andere.“

Bei Maison Code Paris betrachten wir CSP als obligatorisch für jede Website, die Transaktionen ausführt. Ohne sie zu arbeiten ist so, als würde man die Tresortür offen lassen, weil „das Schloss schwer zu bedienen ist“.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Warum der Maison Code eine strikte CSP erzwingt

Sicherheit ist kein Zusatz; es ist unsere Grundlinie. Für den hochwertigen Fachhandel ist das Risiko von Magecart (Digital Skimming) existenziell. Wir haben kürzlich einen potenziellen Kunden überprüft und ein bösartiges jQuery-Plugin entdeckt, das Kreditkarteneingaben sammelt. Es war seit 6 Monaten dort. Ein strenger CSP hätte dies sofort blockiert. Wir implementieren Nonce-basiertes CSP auf jeder von uns ausgelieferten Headless-Storefront und stellen so sicher, dass nur Code, dem wir ausdrücklich vertrauen, im Browser Ihres Kunden ausgeführt werden kann.

Der Mechanismus: Whitelisting

Standardmäßig sind vorhandene Webbrowser promiskuitiv. Wenn der HTML-Code „

„http Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://analytics.google.com; „

Wenn ein Angreifer mit diesem Header „. Das Skript wird nie ausgeführt.

Die Strategie: Nonce-basiertes CSP (Strict CSP)

Das Whitelisting von Domains („https://google.com“) ist fragil. Google hostet Millionen von Skripten (Drive, Maps, Benutzerinhalte). Wenn ein Angreifer eine Datei auf Google Drive hochladen kann, kann er Ihre Whitelist umgehen.

Der Goldstandard ist Nonce-based CSP. Ein Nonce (EINMAL verwendete Zahl) ist ein zufälliges kryptografisches Token, das vom Server für jede einzelne Anfrage generiert wird.

Servergenerierung: const nonce = crypto.randomBytes(16).toString('base64'); // "r4nd0m"
Kopfzeile: script-src 'nonce-r4nd0m'
HTML-Injection: <script nonce="r4nd0m" src="/app.js"></script>

Wenn ein Angreifer „“ einfügt, kennt er die Nonce nicht. Der Browser blockiert es.

Umsetzung in Wasserstoff (Remix)

In einer Server-Side Rendered (SSR)-App wie Hydrogen generieren wir die Nonce in „entry.server.tsx“.

„tsx // app/entry.server.tsx import { createContentSecurityPolicy } from ‘@shopify/hydrogen’;

Exportieren Sie die asynchrone Standardfunktion handleRequest(request, ResponseStatusCode, ResponseHeaders, RemixContext) { // Der Helfer von Hydrogen generiert die Nonce und den Header const { nonce, header, NonceProvider } = createContentSecurityPolicy({ // Standardrichtlinien defaultSrc: [“‘self’”], imgSrc: [“‘self’”, ‘cdn.shopify.com’, ‘data:’, ‘https://www.google-analytics.com’], styleSrc: [“‘self’”, “‘unsafe-inline’”], // Gültig für gestaltete Komponenten connectSrc: [“‘self’”, ‘https://monorail-edge.shopifysvc.com’, ‘https://vitals.vercel-insights.com’],

// Der kritische Teil
scriptSrc: [
  „‚Selbst‘“,
  // 'strict-dynamic' teilt modernen Browsern mit: „Vertraue jedem Skript, das von einem vertrauenswürdigen Skript geladen wird.“
  // Dadurch kann GTM Facebook Pixel laden, ohne dass wir Facebook explizit auf die Whitelist setzen.
  "'streng-dynamisch'", 
  // Fallback für ältere Browser
  „https://cdn.shopify.com“,
  „https://www.googletagmanager.com“ 
],

});

ResponseHeaders.set(‘Content-Security-Policy’, Header);

zurück ( // NonceProvider übergibt die Nonce an die -Komponente ); } „

Die „Strict Dynamic“-Richtlinie

Moderne Websites verwenden Google Tag Manager (GTM). GTM lädt Facebook Pixel. Facebook Pixel lädt andere Tracking-Skripte. Sie können den vollständigen Baum der Abhängigkeiten nicht vorhersagen. Dies führte dazu, dass Entwickler „unsafe-eval“ und „unsafe-inline“ aktivierten, was den Zweck von CSP zunichte machte.

strict-dynamic löst dieses Problem. Darin heißt es: „Wenn ein Skript vertrauenswürdig ist (eine gültige Nonce hat), erlauben Sie ihm, andere Skripte dynamisch zu laden.“ Da wir GTM vertrauen (indem wir es nicht aktivieren), vertrauen wir dem, was GTM lädt. Warnung: Dies setzt ein großes Vertrauen in GTM voraus. Stellen Sie sicher, dass Ihr GTM-Container über strenge Zugriffskontrollen verfügt.

Identifizieren von Richtlinien

Eine robuste Richtlinie deckt mehr als nur Skripte ab.

base-uri 'none': Verhindert die Entführung von „“-Tags (Umleitung relativer Links zu bösartigen Websites).
object-src 'none': Blockiert Flash, Java-Applets und „“.
frame-ancestors 'none': Verhindert Clickjacking. Ihre Website kann nicht in einen Iframe eingefügt werden.
form-action 'self': Stellt sicher, dass Formulare nur an Ihre eigene API gesendet werden können. Verhindert, dass Angreifer eine Formularaktion auf ihrem Server ändern.
connect-src: Schränkt fetch() / XHR ein. Selbst wenn ein Angreifer JS ausführt, kann er die Daten nicht an „evil.com“ senden.

Sichere Bereitstellung: Der Nur-Bericht-Modus

Sie können CSP am Freitagnachmittag nicht „einschalten“. Sie werden die Website zerstören. Sie blockieren das Chat-Widget. Sie blockieren die Bewertungen-App. Sie beginnen im Nur-Berichtsmodus.

Content-Security-Policy-Report-Only: default-src 'self'; ... report-uri /api/csp-report;

Der Browser führt alles aus, sendet jedoch immer dann einen JSON-Verletzungsbericht an Ihr Backend, wenn er etwas blockiert hätte.

Der Collector-Endpunkt

Sie benötigen einen Dienst, um diese Berichte aufzunehmen. Am besten ist die Verwendung von Sentry oder Datadog; sie visualisieren die Verstöße.

„json { „csp-report“: { „document-uri“: „https://maisoncode.paris/checkout“, „Referrer“: „“, „violated-directive“: „script-src“, „effektive-Anweisung“: „script-src“, „original-policy“: „default-src ‚self‘; script-src ‚nonce-xyz‘“, „blocked-uri“: „https://malicious-analytics.com/tracker.js“, „Statuscode“: 200 } } „

Arbeitsablauf:

Stellen Sie „Nur Bericht“ bereit.
Warten Sie 1 Woche.
Protokolle analysieren. „Ah, wir haben vergessen, das Pinterest-Tag auf die Whitelist zu setzen.“
Update-Richtlinie.
Wenn die Protokolle still sind (nur tatsächliche Angriffe), wechseln Sie zu „Content-Security-Policy“ (Erzwingen).

Refactoring-Code für CSP

CSP zwingt Sie dazu, besseren Code zu schreiben. Es blockiert Inline-Event-Handler.

Schlecht (Blockiert): <button onclick="trackClick()">Kaufen</button>

Gut (Erlaubt): <button id="buyBtn">Kaufen</button> <script nonce="...">document.getElementById('buyBtn').addEventListener('click', trackClick);</script>

Es trennt Verhalten und Markup.

10. Vertrauenswürdige Typen (Die Zukunft der XSS-Prävention)

CSP blockiert die Quelle des Skripts. Vertrauenswürdige Typen blockieren die Senke (innerHTML). Es zwingt Entwickler dazu, Strings zu bereinigen, bevor sie sie injizieren. div.innerHTML = string -> Blockiert. div.innerHTML = TrustedHTML.create(string) -> Erlaubt. Dadurch werden DOM-XSS-Schwachstellen auf der Ebene der Browser-Engine beseitigt. Es ist streng („Hard Mode“), aber für Sicherheit auf Bankniveau ist es das Endspiel.

11. Edge CSP (Cloudflare Workers)

Das Generieren von CSP am Ursprung (Node.js) ist gut. Es ist besser, es am Rand einzuspritzen. Wir verwenden Cloudflare Workers, um Sicherheitsheader einzufügen. Dadurch werden statische Assets (Bilder, reine HTML-Dateien) geschützt, die möglicherweise nicht die Node.js-Anwendungslogik passieren. Es ermöglicht auch eine „Notfallblockierung“. Wenn eine Bibliothek kompromittiert wird, können wir den CSP am Edge innerhalb von 300 ms global aktualisieren.

13. CSP in einer Micro-Frontend-Welt

Was passiert, wenn Sie ein Widget von Team B laden? Sie können die Nonce nicht teilen (sie wird auf dem Server generiert). Hash-basierter CSP. Statt Noncing berechnen Sie den SHA-256-Hash des Skriptinhalts. `script-src ‘sha256-K7g…”. Der Browser hasht das Inline-Skript. Wenn es übereinstimmt, wird es ausgeführt.

Pro: Statisch. Kann zwischengespeichert werden.
Nachteil: Wenn Sie ein Zeichen (sogar ein Leerzeichen) ändern, wird der Hash unterbrochen. Wir verwenden dies für stabile Skripte von Drittanbietern, deren Version selten geändert wird.

14. Das Schlüsselwort „Unsafe-Hashes“.

Manchmal müssen Sie Inline-Ereignishandler (alte Bibliotheken) verwenden. navigate('foo') innerhalb eines onclick. Standard-CSP blockiert dies. Mit „unsafe-hashes“ können Sie bestimmte Event-Handler-Strings auf die Whitelist setzen. script-src 'unsafe-hashes' 'sha256-...' (wobei Hash von “navigate(‘foo’)” ist). Dadurch können Sie Legacy-Code sperren, ohne das gesamte DOM-Ereignismodell neu schreiben zu müssen.

15. Fazit

Content Security Policy ist der Sicherheitsgurt des Webs. Es verhindert nicht den Absturz (Injektion), aber es verhindert, dass Sie durch die Windschutzscheibe fliegen (Datenexfiltration). Die Konfiguration ist mühsam. Es erfordert eine ständige Wartung, wenn Sie neue Marketingtools hinzufügen. Aber für eine Luxusmarke, die mit vermögenden Privatpersonen zu tun hat, ist es die Grundlage des Vertrauens.

Ist Ihre Website weit geöffnet?

Wenn Sie keinen CSP-Header senden, sind Sie anfällig für Magecart. Beauftragen Sie unsere Architekten.