Astro 7.1: Content Security Policy einrichten, ohne den Header selbst zu pflegen

Das 7.0-Release von Astro war ein Major mit dem, was ein Major so mitbringt: ein neuer Rust-Compiler, ein anderer Bundler, eine Handvoll Breaking Changes, die man vorher prüfen musste. Wie glimpflich das in der Praxis ausging, habe ich beim Upgrade dieser Website auf Astro 7 aufgeschrieben. 7.1 ist das genaue Gegenteil: ein Minor-Release, das man einspielt und danach vergisst - oder besser, das man einspielt und dann eine Sache aufsetzt, die vorher lästiger war, als sie sein müsste.

Astro 7.1 ist am 16. Juli 2026 erschienen. Es bringt keine Breaking Changes, dafür eine deutlich brauchbarere Content Security Policy, eine kleine, aber sinnvolle Pagination-Option und zwei Handgriffe, die bei großen Content Collections den Speicher entlasten. Der Reihe nach - und mit dem Schwerpunkt auf dem Punkt, der sich sofort auszahlt.

Was in 7.1 steckt

Der Umfang ist überschaubar, und das ist bei einem Minor auch so gewollt. Die Punkte, die in der Praxis etwas ändern:

• Content Security Policy, feiner steuerbar: vier neue Direktiven, mit denen sich Scripts und Styles gezielter erlauben lassen.
• Pagination mit eigener URL-Form: paginate() bekommt eine format-Funktion, die jede erzeugte URL umschreiben kann.
• Content Collections, sparsamer: deferRender verschiebt das Rendern auf den Abruf, und eine experimentelle Option teilt große Datenbestände in Blöcke.
• Dev-Server parallel: ein --ignore-lock-Flag lässt mehrere Instanzen desselben Projekts nebeneinander laufen.

Foto: florianolv / Unsplash

Eingespielt wird das Ganze wie jedes Astro-Update, über npx @astrojs/upgrade oder direkt per astro@latest. Ein Minor ohne Breaking Changes heißt: der Build, der vorher lief, läuft danach weiter. Interessant wird es erst, wenn man die neuen Fähigkeiten anfasst.

Content Security Policy: der Header, den du sonst von Hand pflegst

Eine Content Security Policy ist eine der wirksamsten und zugleich unbeliebtesten Sicherheitsmaßnahmen im Web. Die Idee ist simpel: Der Browser bekommt eine Liste, aus welchen Quellen er Scripts, Styles, Bilder und anderes laden und ausführen darf. Alles, was nicht auf der Liste steht, wird blockiert. Landet über eine Lücke fremder Code in der Seite, führt der Browser ihn schlicht nicht aus - die Richtlinie deckt ihn nicht. Gegen Cross-Site-Scripting gibt es kaum etwas Besseres.

Unbeliebt ist sie, weil die Pflege mühsam war. Inline-Scripts und Inline-Styles brauchen entweder ein pauschales 'unsafe-inline' - womit man einen Gutteil des Schutzes wieder aufgibt - oder für jedes einzelne Fragment einen Hash. Und dieser Hash ändert sich, sobald sich am Code auch nur ein Zeichen ändert. Wer die Richtlinie von Hand als Header oder Meta-Tag pflegt, fügt ein Analytics-Snippet hinzu, vergisst den Hash nachzuziehen, und die halbe Seite lädt nicht mehr. Genau diese Reibung sorgt dafür, dass viele Projekte am Ende doch bei 'unsafe-inline' landen oder ganz auf CSP verzichten.

Foto: flyd2069 / Unsplash

Astros eingebaute CSP dreht den Spieß um: Nicht du pflegst die Richtlinie, sondern Astro erzeugt sie aus dem tatsächlichen Build. Das Framework kennt beim Bauen jedes Script und jedes Style-Fragment, das es ausliefert, und schreibt die Richtlinie passend dazu - inklusive der Hashes für Inline-Code, die man sonst manuell nachhalten müsste. In der Grundform genügt dafür ein Schalter in der astro.config:

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  security: {
    csp: true,
  },
});

Ab da liefert jede Seite eine Content Security Policy aus, die zum ausgelieferten Code passt. Fügst du später ein Script hinzu, wird der passende Hash beim nächsten Build automatisch Teil der Richtlinie. Die Fehlerquelle “Hash vergessen” fällt weg, weil niemand mehr einen Hash von Hand einträgt.

Was 7.1 an der Richtlinie feiner macht

Der Schalter allein deckt den Standardfall ab. In echten Projekten will man aber häufiger als gedacht eine einzelne Ausnahme, ohne gleich die ganze Kategorie zu öffnen - und genau da setzt 7.1 an. Neu sind vier granularere Direktiven: script-src-elem, script-src-attr, style-src-elem und style-src-attr. Sie sind spezialisierte Varianten von script-src und style-src und trennen, was vorher in einem Topf lag: -elem regelt die eigentlichen <script>- und <style>-Elemente, -attr die inline gesetzten Attribute wie ein style="..." direkt am Element.

Der praktische Nutzen: Man kann einen unsauberen, aber unvermeidbaren Fall gezielt erlauben, ohne den Rest aufzuweichen. Ein typisches Beispiel sind Inline-Style-Attribute, die eine Fremdkomponente setzt. Statt Inline-Styles pauschal freizugeben, öffnest du nur die Attribut-Variante:

// astro.config.mjs
export default defineConfig({
  security: {
    csp: {
      styleDirective: [
        { resource: "'unsafe-inline'", kind: "attribute" },
      ],
    },
  },
});

Damit akzeptierst du inline gesetzte Styles als “unsafe”, ohne die Sicherheit für externe CSS-Dateien aufzugeben - die laufen weiter über die strenge Regel. Die vollständige Liste der Optionen steht in der Astro-Konfigurationsdoku; das Muster bleibt aber immer dasselbe: eng anfangen und nur den konkreten Fall aufmachen, den man wirklich braucht.

Diese Website läuft selbst auf Astro, und ein CSP-Header gehört zu den Dingen, die man früher genau einmal sauber aufgesetzt und danach bei jeder Änderung nervös im Blick behalten hat. Dass das Framework die Richtlinie aus dem Build ableitet und man nur noch die echten Ausnahmen benennt, ist der Unterschied zwischen “haben wir vor, wenn Zeit ist” und “steht”.

Pagination: URLs, die zu echten Dateien passen

Astros paginate() erzeugt aus einer langen Liste die einzelnen Seiten-Routen - Seite 1, 2, 3 und so weiter. In 7.1 nimmt die Funktion einen zusätzlichen Parameter format entgegen, mit dem sich jede erzeugte URL umschreiben lässt:

export const getStaticPaths = ({ paginate }) => {
  return paginate(posts, {
    pageSize: 10,
    format: (url) => `${url}.html`,
  });
};

Klingt nach einer Kleinigkeit, löst aber ein reales Problem bei statischen Builds: Manche Hoster erwarten, dass eine URL auf eine tatsächliche Datei auf der Platte zeigt. Eine “saubere” URL ohne Endung passt dann nicht zur Dateistruktur, und man behilft sich mit Server-Regeln. Die format-Funktion nimmt jede generierte URL entgegen und gibt die zurück, die man wirklich braucht - hier eine mit .html-Endung, die dem Dateinamen entspricht.

Content Collections: weniger Speicher bei großen Sammlungen

Wer viele Markdown-Dateien in einer Content Collection hat, kennt den Effekt: Der Sync-Schritt zieht alles in den Speicher, und bei mehreren hundert Einträgen wird das spürbar. 7.1 bringt dafür zwei Ansätze.

Der erste ist die Option deferRender am glob-Loader. Sie verschiebt das Rendern eines Eintrags auf den Moment, in dem er tatsächlich abgerufen wird, statt alles im Voraus zu rendern:

// src/content.config.ts
const docs = defineCollection({
  loader: glob({
    pattern: '**/*.md',
    base: 'src/content/docs',
    deferRender: true,
  }),
});

Der zweite ist experimentell und zielt auf sehr große Datenbestände: Mit collectionStorage: 'chunked' teilt Astro die Daten in mehrere Dateien auf, sobald ein Block 10 MB erreicht. Das umgeht Größenbeschränkungen mancher Plattformen für einzelne Dateien.

export default defineConfig({
  experimental: {
    collectionStorage: 'chunked',
  },
});

Foto: winstonchen / Unsplash

Für einen typischen Firmen-Blog mit ein paar Dutzend Artikeln ist beides nicht nötig. Sobald aber eine Dokumentation oder ein Katalog mit Tausenden Einträgen ins Spiel kommt, ist der Unterschied im Speicherverbrauch der Punkt, an dem ein Build in der CI durchläuft oder abbricht.

Dev-Server und Logger

Zwei Details für den Alltag. Astro 7 hatte einen Lock eingeführt, der verhindert, dass man denselben Dev-Server versehentlich doppelt startet. Manchmal will man aber genau das - zwei Instanzen desselben Projekts nebeneinander. Dafür gibt es jetzt astro dev --ignore-lock. Der Preis: Instanzen, die so gestartet wurden, tauchen in astro dev stop, astro dev status und astro dev logs nicht auf, weil diese Befehle sie nicht mitzählen.

Dazu lässt sich das Logging über einen eigenen Einstiegspunkt ersetzen. Wer die Ausgaben von Astro in ein eigenes Format oder System lenken will, verweist in der Config auf eine eigene Logger-Datei:

export default defineConfig({
  logger: {
    entrypoint: new URL('./src/custom-logger.js', import.meta.url),
  },
});

Ein neuer Typ AstroRuntimeLogger sorgt dabei für die passende Typisierung, wenn man den Logger in eigene Hilfsdateien reicht.

Fazit

Astro 7.1 ist kein Release, das man mit einem Wochenende Migration bezahlt - es ist eines, das man mitnimmt. Kein Breaking Change, ein Befehl, und danach eine Content Security Policy, die sich aus dem Build ergibt, statt in einer Textdatei gepflegt zu werden. Wer bisher wegen des Aufwands keine CSP hatte, verliert mit dieser Version die beste Ausrede.

Der rote Faden ist derselbe wie bei den letzten Astro-Releases und einer der Gründe, warum ich Astro für Firmen-Websites einsetze: Das Framework nimmt einem die undankbare Arbeit ab, ohne dass man Bestehendes umbauen muss.

Wenn du eine Astro-Seite betreibst und einen sauberen Content-Security-Policy-Header aufsetzen willst, ohne dich durch Hashes zu quälen: Ich bin Eric Menge von EMIT Solution, erreichbar unter info@emit-solution.com und über emit-solution.com. Ich richte solche Sicherheits-Header auf Astro-Projekten ein und schaue mir gern an, wo bei deinem Setup die konkreten Ausnahmen liegen.