Alpine.js CSP Build: Strikte Content Security Policy ohne eval()

1. Warum das Standard-Build von Alpine.js unsafe-eval braucht

Alpine.js wertet Ausdrücke wie x-data="{ open: false }" oder x-on:click="open = !open" zur Laufzeit aus, indem der String als Funktionskörper an new Function() übergeben wird. Das ist der Grund, warum Entwickler beliebige JavaScript-Ausdrücke direkt im HTML-Attribut schreiben können, ohne vorher etwas zu kompilieren. Genau diese Fähigkeit, Strings zu Code zu machen, fällt aber unter unsafe-eval in der Content Security Policy, weil dieselbe Technik auch für Cross-Site-Scripting missbraucht werden kann.

In Umgebungen mit strikter Sicherheitsrichtlinie, etwa Banken, Regierungsseiten, Browser-Erweiterungen oder Electron-Apps, ist unsafe-eval in der Regel komplett verboten, weil es einen der wichtigsten Schutzmechanismen der CSP aushebeln würde. Genau für diesen Fall gibt es das dedizierte Alpine.js CSP Build, das denselben Funktionsumfang ohne new Function() und ohne eval() anbietet.

Der Rest dieses Artikels zeigt, wie das Alpine.js CSP Build intern funktioniert, welche Syntax-Einschränkungen es mitbringt, wie Alpine.data() zur zentralen Lösung wird und wie eine Migration bestehender Projekte auf eine strikte Content Security Policy in der Praxis abläuft.

2. Content Security Policy: script-src und die Rolle von unsafe-eval

Eine Content Security Policy wird über den HTTP-Header Content-Security-Policy oder ein Meta-Tag gesetzt und schränkt ein, welche Skriptquellen ein Browser überhaupt ausführen darf. Die Direktive script-src 'self' erlaubt nur Skripte von der eigenen Domain, blockiert aber standardmäßig auch eval(), new Function() und ähnliche Mechanismen zur dynamischen Codeauswertung, sofern nicht explizit 'unsafe-eval' hinzugefügt wird.

unsafe-eval trägt das Wort unsafe zu Recht im Namen: Wenn ein Angreifer eine Möglichkeit findet, kontrollierbaren String-Input in eine eval-artige Funktion einzuschleusen, etwa über eine unsauber escapte Templating-Variable, kann daraus beliebiger Codeausführung im Kontext der Seite werden. Deshalb verbieten viele Security-Audits und Compliance-Vorgaben, etwa im PCI-DSS-Umfeld, unsafe-eval pauschal. Das Alpine.js CSP Build ist genau die Antwort auf diese Anforderung, ohne auf Alpine als Framework verzichten zu müssen.

3. Das Alpine.js CSP Build einbinden

Statt des Standard-Pakets alpinejs wird für strikte Umgebungen das Paket @alpinejs/csp eingebunden. Es exportiert dieselbe globale Alpine-API, verwendet intern aber einen handgeschriebenen Expression-Parser statt new Function(). Das bedeutet: Der überwiegende Teil bestehender Templates funktioniert unverändert weiter, nur bestimmte fortgeschrittene JavaScript-Konstrukte in Inline-Expressions sind nicht mehr erlaubt.

// package.json — swap the default build for the CSP-compatible one
{
  "dependencies": {
    "@alpinejs/csp": "^3.14.0"
  }
}

// resources/js/app.js
import Alpine from '@alpinejs/csp'

window.Alpine = Alpine
Alpine.start()

// CSP header that would block the default Alpine build entirely
// Content-Security-Policy: script-src 'self'; object-src 'none';
// No 'unsafe-eval' needed with @alpinejs/csp

Wichtig ist, dass das Alpine.js CSP Build keine Kompilierstufe oder einen Build-Schritt erfordert. Es ist ein Drop-in-Ersatz, der zur Laufzeit im Browser läuft, aber intern auf einen Tokenizer und Parser für die begrenzte Alpine-Expression-Grammatik setzt statt auf die generische JavaScript-Auswertung von new Function(). Das erklärt, warum manche Ausdrücke, die im Standard-Build funktionieren, im CSP Build zu einem Parser-Fehler führen.

4. Alpine.data(): Expressions aus HTML in JavaScript verlagern

Die zentrale Strategie im Alpine.js CSP Build ist, komplexe Logik nicht mehr als Inline-String im HTML-Attribut zu schreiben, sondern in einer benannten Komponente über Alpine.data() zu registrieren, die in einer regulären, von der CSP nicht betroffenen JavaScript-Datei liegt. Das HTML referenziert die Komponente dann nur noch über ihren Namen, etwa x-data="dropdown", ohne dass im Attribut selbst komplexer Code steht.

// resources/js/components/dropdown.js
// Registered once, outside the CSP-restricted inline attribute
document.addEventListener('alpine:init', () => {
    Alpine.data('dropdown', () => ({
        open: false,
        items: [],
        toggle() {
            this.open = !this.open
        },
        select(item) {
            this.selected = item
            this.open = false
        },
    }))
})

<!-- resources/views/dropdown.blade.php -->
<!-- Only a simple identifier reference, no inline JS expression -->
<div x-data="dropdown">
    <button x-on:click="toggle">Menü öffnen</button>
    <ul x-show="open">
        <template x-for="item in items">
            <li x-on:click="select(item)" x-text="item.label"></li>
        </template>
    </ul>
</div>

Diese Verlagerung hat einen wichtigen Nebeneffekt: Methoden wie toggle oder select sind jetzt echte JavaScript-Funktionen in einer regulären Datei, die von Linting, Type-Checking und Tests erfasst werden. Das Alpine.js CSP Build erzwingt damit indirekt eine sauberere Trennung zwischen Markup und Logik, die auch ohne strikte CSP-Anforderung ein Qualitätsgewinn ist.

5. Was im CSP Build nicht mehr funktioniert

Der Expression-Parser des Alpine.js CSP Build unterstützt eine eingeschränkte Teilmenge von JavaScript direkt in HTML-Attributen. Verboten sind beliebige Funktionsdefinitionen als Inline-Ausdruck, etwa x-on:click="() => { doSomething() }", sowie mehrzeilige Statement-Blöcke mit Semikolon-Trennung in komplexeren Formen. Einfache Methodenaufrufe, Property-Zugriffe, ternäre Ausdrücke und Vergleichsoperatoren bleiben erlaubt.

Auch x-init mit komplexem Inline-Code sollte im Alpine.js CSP Build vermieden und stattdessen als init()-Methode innerhalb der Alpine.data()-Definition implementiert werden. Der Parser ist bewusst konservativ, weil jede zusätzliche Sprachfunktion, die er unterstützt, potenziell einen neuen Weg öffnet, um Code einzuschleusen, auch wenn dieser Weg technisch kein eval() mehr ist.

6. Nonce-Strategie für Inline-Skripte kombinieren

Das Alpine.js CSP Build löst nur das Problem der dynamischen Expression-Auswertung, nicht das allgemeine Problem von Inline-<script>-Tags. Wer weiterhin ein Inline-Script für Initialisierungscode braucht, etwa um Alpine.data()-Komponenten direkt im Template zu registrieren, muss dieses Script mit einem serverseitig generierten nonce-Attribut versehen, das mit dem script-src 'nonce-...'-Wert im CSP-Header übereinstimmt.

// Server-side: generate a fresh nonce per request and reuse it in both
// the CSP header and every inline script tag that must run.
// Content-Security-Policy: script-src 'self' 'nonce-r4nd0mVal123';

<script nonce="r4nd0mVal123">
    document.addEventListener('alpine:init', () => {
        Alpine.data('counter', () => ({ count: 0 }))
    })
</script>

Wichtig ist, dass der Nonce-Wert bei jedem Request neu generiert wird und niemals hartcodiert im Template steht, sonst verliert er seinen Sicherheitswert vollständig. In den meisten Frameworks, etwa Laravel oder Symfony, gibt es dafür Middleware-Pakete, die den Nonce automatisch generieren und sowohl in den Response-Header als auch in eine Template-Variable einfügen. Das Alpine.js CSP Build und die Nonce-Strategie ergänzen sich, weil beide unabhängig voneinander verschiedene Angriffsflächen schließen.

7. Bestehende Komponenten schrittweise migrieren

Eine Migration eines gewachsenen Projekts vom Standard-Build auf das Alpine.js CSP Build gelingt am besten schrittweise statt in einem großen Umbau. Zuerst wird das CSP Build parallel im Entwicklungs-Environment mit aktivierter, aber noch nicht erzwungener CSP getestet, etwa über den Content-Security-Policy-Report-Only-Header, der Verstöße nur protokolliert, ohne sie zu blockieren.

Jede Komponente, die einen Parser-Fehler auslöst, wird identifiziert und auf Alpine.data() umgestellt. In der Praxis betrifft das meist einen kleinen Anteil komplexer Komponenten mit verschachtelten Callbacks, während einfache x-show- und x-model-Bindungen unverändert weiterlaufen. Erst wenn der Report-Only-Modus keine Verstöße mehr meldet, wird die CSP im nächsten Schritt tatsächlich erzwungen.

8. Typische Fehler beim Umstieg auf das CSP Build

Der häufigste Fehler ist, weiterhin komplexe Inline-Arrow-Functions in x-on-Attributen zu verwenden und sich zu wundern, warum die Konsole einen Parser-Fehler meldet, den es im Standard-Build nie gab. Der zweite häufige Fehler ist, das CSP Build zu importieren, aber gleichzeitig unsafe-eval aus Gewohnheit im CSP-Header zu behalten, wodurch der eigentliche Sicherheitsgewinn verpufft, weil andere Skripte auf der Seite weiterhin eval nutzen dürfen.

// WRONG: complex inline arrow function — fails in the CSP build's parser
<button x-on:click="() => { fetch('/api/like').then(r => r.json()) }">
    Like
</button>

// RIGHT: named method on an Alpine.data() component
document.addEventListener('alpine:init', () => {
    Alpine.data('likeButton', () => ({
        async like() {
            const response = await fetch('/api/like')
            this.liked = await response.json()
        },
    }))
})

<button x-data="likeButton" x-on:click="like">Like</button>

// WRONG: importing @alpinejs/csp but keeping unsafe-eval in the CSP header
// Content-Security-Policy: script-src 'self' 'unsafe-eval';  ← defeats the purpose

// RIGHT: drop unsafe-eval entirely once migration is complete
// Content-Security-Policy: script-src 'self' 'nonce-r4nd0mVal123';

9. Standard-Build vs. CSP Build im Vergleich

Die Entscheidung zwischen Standard-Build und Alpine.js CSP Build hängt von den Sicherheitsanforderungen des Projekts ab. Die folgende Tabelle stellt beide Varianten gegenüber.

10. Zusammenfassung

Das Alpine.js CSP Build macht reaktive Alpine-Komponenten auch unter einer strikten Content Security Policy ohne unsafe-eval möglich, indem es new Function() durch einen eigenen Expression-Parser ersetzt. Komplexe Inline-Logik muss dafür in Alpine.data()-Komponenten verlagert werden, was gleichzeitig die Code-Organisation verbessert. Nonce-basierte Inline-Skripte ergänzen das CSP Build für die verbleibenden notwendigen Script-Tags.

Für Projekte ohne strikte Compliance-Vorgaben bleibt das Standard-Build die bequemere Wahl. Sobald aber ein Security-Audit, eine Behörde oder eine Branchenvorgabe unsafe-eval ausschließt, ist das Alpine.js CSP Build der direkte Weg, Alpine ohne Framework-Wechsel weiterzuverwenden. Die schrittweise Migration mit Report-Only-Header minimiert dabei das Risiko unerwarteter Breakages in Produktion.

11. FAQ: Alpine.js CSP Build