Astro-Entwickler in Frankfurt

#Sicherheitsheader für Astro-Seiten in Frankfurt und Hessen

Eine statische Astro-Seite hat keine Datenbank, die ein Angreifer abfragen könnte. Sie lädt trotzdem Skripte, Styles, Schriften und Bilder, und jede dieser Quellen ist ein Weg, über den fremder Code in die Seite gelangen kann. Sicherheitsheader sagen dem Browser, was er davon annehmen darf. Für Betriebe in Frankfurt und Hessen, die eine Astro-Seite betreiben oder planen, beschreibe ich hier, was Astro selbst dafür mitbringt, wo es endet und wie Sie das Ergebnis prüfen, bevor die Seite live geht.

Die Quellen sind die Astro-Dokumentation, die MDN Web Docs, die CSP-Spezifikation des W3C und das OWASP-Merkblatt zu HTTP-Headern. Zur Content Security Policy für Next.js gibt es eine eigene Seite: Next.js Entwickler in Frankfurt. Hier geht es nur um Astro.

Foto: Thomas Roessler, CC BY-SA 3.0, Wikimedia Commons.

#Was die CSP-Option von Astro ausliefert

Die Option security.csp ist standardmäßig aus. Laut Konfigurationsreferenz gibt es sie seit Astro 6.0.0; nach der npm-Registry erschien diese Version am 10. März 2026. Ist sie eingeschaltet, setzt Astro in den <head> jeder Seite ein <meta http-equiv="content-security-policy">. Die Werte für script-src und style-src stammen aus den Skripten und Styles, die Astro auf der jeweiligen Seite selbst einbindet, jeweils als Hash.

Die Konfiguration kennt vier Stellschrauben:

• algorithm: SHA-256 (Standard), SHA-384 oder SHA-512 für die erzeugten Hashes.
• directives: weitere Direktiven wie img-src, die auf allen Seiten stehen.
• styleDirective und scriptDirective: je ein Objekt mit hashes für eigene Hashes und resources für Quellen. Setzen Sie resources, ersetzen Sie Astros Standardquellen; 'self' steht dann nur noch drin, wenn Sie es eintragen.
• strictDynamic in der scriptDirective: fügt strict-dynamic hinzu. Astro trägt dann den Hash jedes gebündelten Skripts ein und rendert eine Import-Map mit integrity-Angaben. Das verlangt Chrome 127, Firefox 138 oder Safari 18.

Ein Beispiel für astro.config.mjs:

import { defineConfig } from 'astro/config';

export default defineConfig({
  security: {
    csp: {
      algorithm: 'SHA-256',
      directives: ["img-src 'self' data:"],
      scriptDirective: { resources: ["'self'"] },
      styleDirective: { resources: ["'self'"] },
    },
  },
});

Seit Astro 7.1.0 (16. Juli 2026 laut npm-Registry) lässt sich jede Quelle und jeder Hash mit kind auf element, attribute oder default begrenzen, also auf style-src-elem, style-src-attr oder style-src. Die API-Referenz beschreibt dazu eine Falle: Wer eine Direktive auf element oder attribute eingrenzt, bei dem greift der Browser nicht mehr auf die allgemeine Direktive zurück. Astro verschiebt die eigenen Hashes automatisch, die allgemeinen Quellen aber nicht, und warnt, wenn es das bemerkt.

Pro Seite lässt sich die Richtlinie im Frontmatter einer .astro-Datei ergänzen: Astro.csp?.insertDirective(), insertScriptResource(), insertScriptHash() und die Gegenstücke für Styles. Astro führt alle Angaben zusammen und entfernt Doppelte.

#Wo die Option an Grenzen stößt

Die Dokumentation nennt die Grenzen selbst:

• Externe Skripte und Styles gibt es nicht von Haus aus; Sie liefern eigene Hashes.
• Der <ClientRouter /> wird nicht unterstützt. Die Dokumentation verweist auf die native View-Transition-API des Browsers. Wie Seitenübergänge ohne den Router aussehen, zeigt die Seite für Münster.
• Shiki wird nicht unterstützt, weil seine Funktionen Inline-Styles erzeugen. Die Dokumentation empfiehlt <Prism />. Wie Markdown und MDX Code hervorheben, steht auf der Seite für Bonn.
• Steht 'unsafe-inline' in einer Direktive, gibt Astro dort keine Hashes aus, und die Direktive schützt nur noch auf dem Niveau von 'unsafe-inline'.
• Im Dev-Modus arbeitet die Funktion nicht. Geprüft wird mit build und preview.

Dazu kommt eine Grenze, die nicht in der Astro-Dokumentation steht, sondern in der CSP-Spezifikation. Abschnitt 3.3 des W3C-Entwurfs CSP Level 3 zum meta-Element schließt report-uri, frame-ancestors und sandbox aus. Auch Content-Security-Policy-Report-Only funktioniert dort nicht. Wer also verhindern will, dass andere Seiten die eigene in einem Frame einbetten, kommt um einen echten Antwortheader nicht herum.

Der Header und das meta-Element schließen sich nicht aus. Laut MDN erlaubt der Mechanismus mehrere Richtlinien gleichzeitig, unter anderem über den Header und über ein meta-Element. Ein sinnvoller Zuschnitt: Astro erzeugt die Hashes für Skripte und Styles im meta-Element, der Host liefert frame-ancestors und die übrigen Header.

Bilder, die von einer anderen Domain kommen, etwa aus einer WordPress-Installation hinter der Astro-Seite, brauchen eine passende img-src-Quelle. Wie das Zusammenspiel von Astro und WordPress als Headless-Backend aufgebaut ist, beschreibt die Seite für Wien. Und wer Inseln mit Frameworks hydriert, findet die Grundlagen auf der Seite für Wiesbaden.

#Header setzen: statischer Host oder Adapter

Wer wo die Header setzt, hängt davon ab, wie die Seite ausgeliefert wird.

Statischer Host. Die Seite besteht aus fertigen Dateien. Eine Headerdatei der Plattform schreibt die Antwortheader. Bei Cloudflare Pages ist das die Datei _headers im Ordner public/. Laut Cloudflare-Dokumentation gibt es bis zu 100 Regeln, jede Zeile darf höchstens 2000 Zeichen lang sein, und die Datei gilt nicht für Antworten aus Pages Functions. Ein Header lässt sich für einen engeren Pfad mit vorangestelltem Ausrufezeichen wieder abziehen.

/*
  Strict-Transport-Security: max-age=300
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Content-Security-Policy: frame-ancestors 'self'

Andere statische Hosts haben ähnliche Dateien oder Oberflächen, jeweils mit eigenen Grenzen. Ich lese vor dem Einrichten deren Dokumentation, nicht diese Seite.

Adapter und Rendering auf Abruf. Läuft die Seite mit einem Adapter, setzen Sie die Header entweder weiterhin beim Host oder in der Astro-Middleware. Nach der Middleware-Seite läuft die Middleware bei vorab gerenderten Seiten zur Build-Zeit, bei Seiten auf Abruf bei jeder Anfrage. Daraus folgt: Header für fertig gebaute statische Dateien setzt der Host, nicht die Middleware. Wie Adapter, Edge und eigene Server sich unterscheiden, beschreibt die Seite für Berlin.

#Die übrigen Header

Das OWASP-Merkblatt zu HTTP-Headern nennt für die gängigen Header feste Werte. Die MDN-Referenzen erklären, was jeder bewirkt.

Zu jedem Header ein paar Hinweise aus den Quellen:

• HSTS gilt nur, wenn der Browser den Header über HTTPS erhält; über HTTP ignoriert er ihn. max-age=0 hebt die Regel auf, aber erst, wenn der Browser wieder eine HTTPS-Antwort sieht. Für preload verlangt MDN mindestens ein Jahr als max-age und includeSubDomains. Die Preload-Liste gilt laut hstspreload.org für alle Subdomains, auch für interne, und die Aufnahme lässt sich nicht ohne Weiteres rückgängig machen. Deshalb steht im Beispiel oben ein kurzer Wert: erst prüfen, dann erhöhen.
• Referrer-Policy: Fehlt der Header, gilt in aktuellen Browsern strict-origin-when-cross-origin. OWASP rät trotzdem, den Wert ausdrücklich zu setzen.
• Permissions-Policy: Die leere Liste () schaltet die Funktion in allen Kontexten ab, auch in eingebetteten Frames. Abgeschaltet gehört nur, was die Seite nicht braucht.
• X-Content-Type-Options: Der Header setzt voraus, dass der Host die richtigen Content-Type-Werte liefert. Bei einer Astro-Seite mit Standardhosting stimmt das fast immer, bei einem selbst gebauten Nginx lohnt der Blick.
• X-XSS-Protection setzen Sie nicht. OWASP rät, den Header gar nicht zu setzen oder ausdrücklich abzuschalten.

Setzen Sie keine dieser Header per <meta http-equiv>. MDN warnt, das erzeuge ein falsches Sicherheitsgefühl, weil Browser andere Header als die CSP dort nicht zuverlässig verarbeiten.

#Prüfen, bevor die Seite live geht

Ein Build ohne Fehler beweist nicht, dass die Header ankommen. Ich prüfe in dieser Reihenfolge:

1. npm run build und npm run preview, denn im Dev-Modus arbeitet Astros CSP nicht.
2. Im gebauten Ordner nachsehen, ob auf jeder Seitenart das meta-Element mit der Richtlinie steht, etwa mit grep -rl "content-security-policy" dist.
3. Die Konsole des Browsers auf CSP-Verstöße durchsehen, auf der Startseite, einer Inhaltsseite, einer Seite mit Formular und einer Seite mit eingebundenem Fremddienst.
4. Auf der Testumgebung die Antwortheader mit curl -I abrufen und gegen die Liste oben halten, auch für Dateien wie Bilder und Schriften.
5. Den MDN HTTP Observatory laufen lassen, ein Prüfdienst von Mozilla für HTTP-Header und weitere Sicherheitseinstellungen. Er ersetzt die Sichtprüfung nicht, findet aber Header, die ein Host stillschweigend überschreibt.
6. Erst danach HSTS erhöhen und, wenn gewünscht, die Aufnahme in die Preload-Liste beantragen.

Eine Richtlinie im Beobachtungsmodus testen Sie nur mit einem echten Header, wie die Next.js-Seite für den Report-Only-Header zeigt. Ein meta-Element kann das nicht.

#Wer in Hessen für den Datenschutz zuständig ist

Zuständig für den Datenschutz hessischer Unternehmen ist der Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI). Einen eigenen Paragrafen für Sicherheitsheader gibt es nicht. Art. 32 DSGVO verlangt geeignete technische und organisatorische Maßnahmen unter Berücksichtigung des Stands der Technik. Ob Ihre Header dazu zählen, bewertet Ihre Datenschutzberatung. Rechtsberatung gebe ich nicht.

#Wie ein Auftrag abläuft

Ich bin ein einzelner Entwickler, arbeite von Gdynia aus und schriftlich. Termine und Telefonate gibt es nicht, alles läuft per E-Mail. Gestaltung und Layout stellen Sie, ich setze beides um.

1. Sie schicken mir die Adresse der Seite, Host und Adapter sowie die Liste der Fremddienste.
2. Die Antwortheader rufe ich selbst ab. Offene Fragen stelle ich schriftlich, danach schicke ich Umfang, Annahmen und Ausschlüsse.
3. Ich erstelle die Bestandsaufnahme: welche Skripte, Styles, Schriften und Bilder die Seite von wo lädt.
4. Die Konfiguration und die Headerdatei laufen zuerst auf Ihrer Testumgebung. Sie prüfen und nehmen ab.
5. Danach folgt die Produktion. Wer die Seite fortlaufend betreut haben möchte, findet die Methode auf der Seite WordPress Wartung in Frankfurt; sie gilt sinngemäß auch für Astro-Seiten.

Für den Start brauche ich Lesezugriff auf das Repository, Zugang zur Testumgebung und den Namen der Person, die über neue Fremddienste entscheidet.

#Prüfliste für Ihre Astro-Seite

• security.csp ist an, und build plus preview laufen ohne Verstöße in der Konsole.
• Jede Quelle in resources ist nötig; 'unsafe-inline' steht nur dort, wo es ein Fremddienst nachweislich verlangt.
• Externe Skripte sind durch Hash oder Quelle abgedeckt, und jemand ist für Änderungen verantwortlich.
• Der Host liefert frame-ancestors als echten Header.
• Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy und Permissions-Policy stehen für alle Pfade, auch für Dateien.
• HSTS beginnt mit einem kurzen max-age, und preload kommt erst nach der Prüfung aller Subdomains.
• Weder X-XSS-Protection noch Sicherheitsheader per <meta>.
• Nach jedem Astro-Update läuft der Test erneut.

#Häufige Fragen zu CSP und Sicherheitsheadern in Astro

#Reicht die CSP-Option von Astro allein aus?

Für Skripte und Styles in vielen Fällen ja. Sie schreibt aber ein meta-Element, und dort gelten report-uri, frame-ancestors und sandbox laut CSP-Spezifikation nicht. Wer das Einbetten der Seite in fremde Frames begrenzen will, braucht dafür einen echten Antwortheader des Hosts.

#Warum greift die CSP im Astro-Entwicklungsserver nicht?

Die Astro-Dokumentation nennt den Vite-Entwicklungsserver als Grund: Die Funktion wird im Dev-Modus nicht unterstützt. Geprüft wird mit einem Build und mit der Vorschau des Builds.

#Kann ich den Google Tag Manager oder andere externe Skripte einbinden?

Nicht ohne Aufwand. Astro unterstützt externe Skripte und Styles nicht von Haus aus; Sie tragen eigene Hashes oder erlaubte Quellen ein. Ein Skript, dessen Inhalt der Anbieter ändert, passt nicht zu einem festen Hash. Dann bleibt nur eine Quelle in der Direktive, und ich bespreche vorher, was das für die Schutzwirkung heißt.

#Sollte ich HSTS mit preload setzen?

Erst wenn alle Subdomains dauerhaft über HTTPS laufen. Die Aufnahme in die Preload-Liste lässt sich laut hstspreload.org nicht ohne Weiteres rückgängig machen. Ich beginne mit einem kurzen max-age und erhöhe ihn schrittweise.

#Was passiert mit dem ClientRouter, wenn ich die CSP einschalte?

Die Dokumentation sagt, dass Astros ClientRouter nicht unterstützt wird, und nennt die native View-Transition-API des Browsers als Weg. Wer Seitenübergänge braucht, entscheidet deshalb vor der CSP, welchen Weg er geht.

#Welche Angaben brauchen Sie für die erste Einschätzung der Header?

Die Adresse der Seite, den Host oder die Hosting-Art, den Adapter, falls einer läuft, und eine Liste der Dienste, die Skripte, Schriften oder Bilder von fremden Domains laden. Die Antwortheader rufe ich selbst ab. Die erste Einschätzung in Textform kostet nichts.

#Schreiben Sie mir für Ihre Astro-Seite in Frankfurt

Schicken Sie mir über das Kontaktformular die Adresse Ihrer Seite, Ihr Ziel, Ihren Termin und den aktuellen Stand: Host, Adapter, eingebundene Fremddienste. Ich rufe die Header ab, frage schriftlich nach und schicke Ihnen eine erste Einschätzung zu Umfang und Annahmen. Dafür berechne ich nichts. Passt Ihr Host nicht zu den Anforderungen, schreibe ich das gleich dazu.