Security-Header auf Vercel und Netlify setzen

Welche Header

Die Quellen nennen als Beispiele X-Frame-Options (DENY) und X-Content-Type-Options (nosniff) sowie die Content-Security-Policy, die erlaubte Quellen für Skripte, Bilder und Styles festlegt und Angriffe über eingeschleusten Code erschwert. Sie ist nach Vercels Doku eine zweite Verteidigungslinie, kein Ersatz für saubere Eingabeprüfung.

Vercel: headers in der vercel.json

In der vercel.json steht eine Liste headers. Jeder Eintrag hat ein source (der Pfad, z. B. /(.*)) und eine Liste headers mit key und value, zum Beispiel X-Frame-Options mit DENY.

Netlify: _headers oder netlify.toml

Auf Netlify legt ihr eine Datei _headers im Publish-Ordner an (Pfad, darunter eingerückt die Header) oder nutzt [[headers]] in der netlify.toml mit for = "/*" und einem Block headers.values.

Die Doku nennt eine Einschränkung: Eigene Header gelten nur für Inhalte, die Netlify selbst ausliefert, nicht für Proxy-Ziele, Serverless Functions, Edge Functions oder SSR-Seiten. Dort muss der Dienst bzw. die Funktion die Header selbst zurückgeben.

Content-Security-Policy: erst Report-Only

Vercel empfiehlt, zuerst den Header Content-Security-Policy-Report-Only zu setzen. So seht ihr mögliche Verstöße, ohne dass etwas blockiert wird, und wechselt erst auf die erzwungene Variante, wenn nichts bricht.

Außerdem rät die Doku, unsafe-inline und unsafe-eval zu vermeiden und für Inline-Skripte und -Styles Nonces oder Hashes zu verwenden, die Quellen möglichst genau zu nennen und die Regeln mit der App zu pflegen.

Danach prüfen

Testet die Seite in mehreren Browsern. Der kostenlose Check prüft auf der Startseite von außen, ob wichtige Security-Header fehlen.

Typische Fehler

Diese Fehler ergeben sich aus den Doku-Seiten von Vercel und Netlify:

• Die Content-Security-Policy sofort erzwingen. Vercel rät, zuerst Content-Security-Policy-Report-Only zu setzen und erst zu erzwingen, wenn nichts bricht.
• unsafe-inline und unsafe-eval als Abkürzung eintragen. Die Doku rät davon ab und empfiehlt Nonces oder Hashes.
• Quellen zu grob erlauben, etwa mit * oder allen Subdomains. Nennt die konkreten Quellen.
• Die Policy nicht pflegen. Ändern sich die Quellen, von denen eure App lädt, muss die Policy mitziehen.
• Auf Netlify erwarten, dass eigene Header auch für Functions, Edge Functions, SSR-Seiten und Proxy-Ziele gelten. Dort gelten sie laut Doku nicht.
• Auf Netlify Header wie Location oder Set-Cookie in _headers setzen. Die Doku führt Header auf, die Netlify selbst setzt und die deshalb üblicherweise ignoriert werden; für Weiterleitungen gibt es eigene Regeln.
• Auf Netlify vergessen, dass Header aus _headers oder netlify.toml für alle Builds und Branches gelten.

Beispiel: vercel.json

Nach dem Muster der Vercel-Doku, hier mit zwei Headern für alle Pfade:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" }
      ]
    }
  ]
}

Beispiel: _headers und netlify.toml

Die Datei _headers liegt im Publish-Ordner. Der Pfad steht allein in einer Zeile, die Header sind darunter eingerückt:

Dasselbe in der netlify.toml:

# _headers
/*
  X-Frame-Options: DENY

# netlify.toml
[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"

Beispiel: Content-Security-Policy im Testbetrieb

Die Beispiel-Policy aus der Vercel-Doku erlaubt Inhalte standardmäßig nur von der eigenen Herkunft, Skripte zusätzlich von cdn.example.com, Bilder von img.example.com. Zum Testen setzt ihr sie unter dem Namen Content-Security-Policy-Report-Only, damit nichts blockiert wird:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' cdn.example.com; img-src 'self' img.example.com; style-src 'self';

Häufige Fragen