security.txt für Netlify konfigurieren
Schritt-für-Schritt-Anleitung: security.txt unter .well-known/ auf Netlify bereitstellen — statisch aus dem Publish-Verzeichnis mit Redirect und PGP-Signatur.
security.txt auf Netlify
security.txt ist eine standardisierte Kontaktdatei nach RFC 9116, die unter /.well-known/security.txt bereitgestellt wird. Sie zeigt Sicherheitsforschern, wie sie Schwachstellen verantwortungsvoll melden können — ein unverzichtbarer Baustein für Coordinated Vulnerability Disclosure. security.txt ist mit 2 von 166 Punkten ein kleiner, aber wichtiger Faktor im Wolf-Agents Web Security Check.
Auf Netlify legen Sie die Datei im Publish-Verzeichnis unter public/.well-known/security.txt ab. Netlify serviert statische Dateien aus dem Publish-Verzeichnis automatisch — kein Rewrite oder spezielle Server-Konfiguration nötig. Für maximale Auffindbarkeit richten Sie zusätzlich einen Redirect von /security.txt auf /.well-known/security.txt ein.
Der Wolf-Agents Web Security Check prüft automatisch, ob eine gueltige security.txt vorhanden ist, das Expires-Datum aktuell ist und die Pflichtfelder Contact und Expires enthalten sind.
security.txt im Publish-Verzeichnis erstellen
Erstellen Sie die Datei im Publish-Verzeichnis Ihres Frameworks. Bei Astro, Next.js oder Gatsby ist das public/.well-known/security.txt. Bei Eleventy oder Hugo liegt das Publish-Verzeichnis häufig unter _site/ oder public/ — prüfen Sie Ihre netlify.toml für den korrekten publish-Pfad.
# public/.well-known/security.txt
# RFC 9116 — Kontaktdatei für Sicherheitsforscher
Contact: mailto:security@ihre-domain.de
Expires: 2027-03-30T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://ihre-domain.de/.well-known/security.txt
Policy: https://ihre-domain.de/security-policy
Encryption: https://ihre-domain.de/.well-known/pgp-key.txt# netlify.toml — Redirect und Content-Type für security.txt
# Redirect: /security.txt → /.well-known/security.txt
[[redirects]]
from = "/security.txt"
to = "/.well-known/security.txt"
status = 301
# Korrekter Content-Type für security.txt
[[headers]]
for = "/.well-known/security.txt"
[headers.values]
Content-Type = "text/plain; charset=utf-8"
Cache-Control = "public, max-age=86400"# _headers — Content-Type für security.txt
/.well-known/security.txt
Content-Type: text/plain; charset=utf-8
Cache-Control: public, max-age=86400Contact (mailto: oder https:) und Expires (ISO 8601) sind Pflicht. Ohne gültiges Expires-Datum wird die Datei als veraltet gewertet.
security.txt verifizieren
Nach dem Deploy prüfen Sie, ob die Datei unter beiden Pfaden erreichbar ist und der korrekte Content-Type gesetzt ist. Achten Sie darauf, dass der HTTP-Statuscode 200 (direkt) bzw. 301 (Redirect) zurückgegeben wird.
# Direkt unter .well-known/ prüfen
curl -sI https://ihre-domain.de/.well-known/security.txt
# Erwartete Ausgabe:
# HTTP/2 200
# content-type: text/plain; charset=utf-8
# Redirect prüfen
curl -sI https://ihre-domain.de/security.txt | head -5
# Erwartete Ausgabe:
# HTTP/2 301
# location: /.well-known/security.txt
# Inhalt der Datei anzeigen
curl -s https://ihre-domain.de/.well-known/security.txt
# Expires-Datum prüfen (muss in der Zukunft liegen)
curl -s https://ihre-domain.de/.well-known/security.txt | grep Expiresdeploy-preview-*.netlify.app/.well-known/security.txt. Die Datei sollte auch dort erreichbar sein, da sie statisch im Build-Output liegt. PGP-Signatur hinzufügen (empfohlen)
RFC 9116 empfiehlt eine PGP-Signatur für die security.txt. Die Signatur beweist, dass die Datei tatsaechlich vom Domaineigentuemer stammt und nicht manipuliert wurde. Signieren Sie die Datei lokal vor dem Commit und stellen Sie den oeffentlichen Schlüssel unter /.well-known/pgp-key.txt bereit.
# security.txt signieren (lokal vor dem Commit)
gpg --clearsign public/.well-known/security.txt
# Signierte Datei ersetzen
mv public/.well-known/security.txt.asc public/.well-known/security.txt
# Öffentlichen Schlüssel bereitstellen
gpg --export --armor security@ihre-domain.de > public/.well-known/pgp-key.txt
# Hinweis: Bei jedem Update muss die Datei neu signiert werden.
# Automatisieren Sie dies im CI/CD-Prozess.Automatische Expires-Aktualisierung
Das Expires-Datum muss regelmäßig aktualisiert werden — RFC 9116 fordert ein gültiges Datum. Integrieren Sie die Aktualisierung in Ihren Netlify-Build-Prozess, damit das Datum bei jedem Deploy automatisch auf ein Jahr in der Zukunft gesetzt wird.
# netlify.toml — Build-Command mit Expires-Update
[build]
command = "npm run build && node scripts/update-security-txt.js"
publish = "dist"
# scripts/update-security-txt.js:
# const fs = require('fs');
# const expires = new Date(Date.now() + 365 * 86400000).toISOString();
# let txt = fs.readFileSync('dist/.well-known/security.txt', 'utf8');
# txt = txt.replace(/Expires:.*/, 'Expires: ' + expires);
# fs.writeFileSync('dist/.well-known/security.txt', txt);Häufige Fehler bei security.txt auf Netlify
Datei nicht im Publish-Verzeichnis
Die Datei liegt im Repo-Root statt im Publish-Verzeichnis. Bei Astro, Next.js oder Gatsby muss sie in public/.well-known/ liegen. Prüfen Sie den publish-Pfad in Ihrer netlify.toml.
.well-known wird vom Build-Tool ignoriert
Einige Build-Tools und Bundler ignorieren Ordner mit Punkt-Prefix. Prüfen Sie, ob .well-known/ im Build-Output (dist/ oder build/) enthalten ist. Manche Frameworks erfordern eine explizite Konfiguration.
Expires-Datum abgelaufen
RFC 9116 erfordert ein gültiges Expires-Datum in der Zukunft. Abgelaufene Daten signalisieren Vernachlässigung und führen zu Punktabzug. Automatisieren Sie die Aktualisierung im Build-Prozess.
netlify.toml überschreibt _headers
Wenn Sie Header sowohl in netlify.toml als auch in _headers definieren, hat netlify.toml Vorrang. Verwenden Sie nur eine der beiden Methoden, um Konflikte zu vermeiden.
Compliance-Relevanz
security.txt erleichtert die koordinierte Schwachstellenmeldung (Coordinated Vulnerability Disclosure). NIS2 (Artikel 21) fordert Prozesse für den Umgang mit Sicherheitsvorfällen — eine erreichbare security.txt ist der erste Schritt dazu. ISO 27001 (Annex A.5.5) empfiehlt Kontaktpunkte für Sicherheitsmeldungen. DSGVO (Art. 33) verlangt die Meldung von Datenschutzverletzungen — security.txt stellt sicher, dass externe Finder den richtigen Kontakt erreichen.
Der Wolf-Agents Web Security Check bewertet security.txt mit bis zu 2 Punkten und prüft Erreichbarkeit, Pflichtfelder und Expires-Datum.
Wie steht Ihre Domain bei security.txt?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.