security.txt für Astro konfigurieren
Schritt-für-Schritt-Anleitung: security.txt unter public/.well-known/ anlegen -- statisch oder dynamisch per API-Route.
security.txt in Astro
security.txt (RFC 9116) ist eine standardisierte Kontaktdatei, die Sicherheitsforschern zeigt, wie sie Schwachstellen melden können. Die Datei liegt unter /.well-known/security.txt und ist mit 2 von 166 Punkten im Wolf-Agents Web Security Check relevant.
In Astro legen Sie die Datei einfach unter public/.well-known/security.txt an. Der public/-Ordner wird 1:1 in den Build kopiert -- die Datei ist in allen Output-Modi (SSR, Hybrid, SSG) verfügbar. Alternativ erstellen Sie eine API-Route für dynamische Inhalte wie ein automatisch berechnetes Expires-Datum. Wolf-Agents stellt eine security.txt unter /.well-known/security.txt bereit.
Obwohl security.txt nur 2 Punkte im Scoring beitraegt, signalisiert die Datei professionellen Umgang mit Sicherheit. Viele Bug-Bounty-Plattformen und Sicherheitsforscher prüfen zuerst, ob eine security.txt existiert, bevor sie Schwachstellen melden.
Die Pflichtfelder gemäß RFC 9116 sind Contact und Expires. Optionale Felder wie Preferred-Languages, Canonical, Policy und Hiring erhöhen die Professionalitaet. Eine PGP-signierte security.txt beweist die Authentizität der Kontaktdaten und verhindert Manipulationen.
security.txt als statische Datei
Erstellen Sie die Datei public/.well-known/security.txt. Die Pflichtfelder sind Contact und Expires. Das Expires-Datum sollte maximal ein Jahr in der Zukunft liegen. Verwenden Sie eine mailto:-Adresse als primären Kontakt.
# public/.well-known/security.txt
# Gemaess RFC 9116 (https://www.rfc-editor.org/rfc/rfc9116)
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
Hiring: https://ihre-domain.de/karriereAlternative: API-Route mit dynamischem Expires (SSR)
Für dynamische Inhalte oder automatisch berechnete Expires-Daten erstellen Sie eine API-Route. Das Expires-Datum wird bei jedem Request auf ein Jahr in der Zukunft gesetzt -- die Datei laeuft nie ab. Diese Variante funktioniert nur im SSR-Modus.
// src/pages/.well-known/security.txt.ts -- API-Route (SSR)
import type { APIRoute } from 'astro';
export const GET: APIRoute = () => {
// Expires automatisch auf 1 Jahr in der Zukunft setzen
const expires = new Date();
expires.setFullYear(expires.getFullYear() + 1);
const body = [
'Contact: mailto:security@ihre-domain.de',
`Expires: ${expires.toISOString()}`,
'Preferred-Languages: de, en',
'Canonical: https://ihre-domain.de/.well-known/security.txt',
'Policy: https://ihre-domain.de/security-policy',
].join('\n');
return new Response(body, {
headers: {
'Content-Type': 'text/plain; charset=utf-8',
'Cache-Control': 'public, max-age=86400',
},
});
};PGP-Signatur hinzufügen
Signieren Sie die security.txt mit PGP, um die Authentizität nachzuweisen. Eine signierte Datei verhindert, dass Angreifer die Kontaktdaten manipulieren und Schwachstellenmeldungen an sich selbst umleiten.
# security.txt mit PGP signieren
gpg --clearsign --output security.txt.signed security.txt
# Signierte Datei nach public/.well-known/ kopieren
mv security.txt.signed public/.well-known/security.txt
# Ergebnis enthält PGP-Signatur:
# -----BEGIN PGP SIGNED MESSAGE-----
# Hash: SHA512
#
# Contact: mailto:security@ihre-domain.de
# ...
# -----BEGIN PGP SIGNATURE-----Erreichbarkeit prüfen
Testen Sie die URL nach dem Deploy. Die Datei muss unter /.well-known/security.txt erreichbar sein und den Content-Type text/plain haben.
# security.txt prüfen
curl -s https://ihre-domain.de/.well-known/security.txt
# Erwartete Ausgabe:
# Contact: mailto:security@ihre-domain.de
# Expires: 2027-03-30T00:00:00.000Z
# Preferred-Languages: de, en
# Content-Type prüfen
curl -sI https://ihre-domain.de/.well-known/security.txt | grep content-type
# Content-Type: text/plain; charset=utf-8Best Practice: Automatisierung und Monitoring
Erstellen Sie einen jährlichen Reminder, um das Expires-Datum zu aktualisieren. Eine abgelaufene security.txt signalisiert Sicherheitsforschern, dass Ihre Organisation keine aktive Vulnerability Disclosure betreibt. Verwenden Sie die API-Route-Variante, um das Expires-Datum automatisch zu berechnen.
Richten Sie ein Monitoring ein, das die Erreichbarkeit von /.well-known/security.txt prüft. Der Wolf-Agents Web Security Check prüft automatisch, ob security.txt vorhanden ist, das korrekte Format hat und ein gültiges Expires-Datum enthält.
Wolf-Agents empfiehlt, die Contact-Adresse auf eine dedizierte Security-Email zu setzen (z.B. security@ihre-domain.de) und diese in Ihrem Incident-Response-Prozess zu integrieren. Schwachstellenmeldungen sollten innerhalb von 48 Stunden bestätigt werden -- das ist in der NIS2-Richtlinie als Best Practice definiert.
Häufige Fehler bei security.txt in Astro
Expires fehlt oder abgelaufen
Expires ist ein Pflichtfeld gemäß RFC 9116. Ein abgelaufenes Datum signalisiert, dass die Datei nicht gepflegt wird. Setzen Sie einen Reminder, um die Datei jährlich zu aktualisieren -- oder verwenden Sie die API-Route mit dynamischem Expires.
Falscher Pfad in Astro
Die Datei muss unter /.well-known/security.txt erreichbar sein. In Astro bedeutet das public/.well-known/security.txt -- nicht public/security.txt und nicht src/pages/.well-known/security.txt (es sei denn, Sie nutzen die API-Route).
API-Route und prerender kollidieren
Wenn Sie export const prerender = true in der API-Route setzen, wird die Datei statisch generiert und das dynamische Expires funktioniert nicht mehr. Lassen Sie die API-Route im SSR-Modus oder verwenden Sie die statische Variante.
Statische Datei und API-Route gleichzeitig
Wenn sowohl public/.well-known/security.txt als auch src/pages/.well-known/security.txt.ts existieren, hat die statische Datei Vorrang. Entfernen Sie eine der beiden Varianten, um Konflikte zu vermeiden.
Kein HTTPS bei security.txt
RFC 9116 empfiehlt, security.txt nur über HTTPS bereitzustellen. Stellen Sie sicher, dass HTTP-Anfragen auf HTTPS umgeleitet werden. Die Canonical-URL sollte immer mit https:// beginnen.
Compliance-Relevanz
security.txt ist ein RFC-Standard (RFC 9116) und wird von NIS2 als Teil der Incident-Response-Bereitschaft empfohlen. Artikel 21 fordert, dass Organisationen einen Prozess für die Meldung von Sicherheitsvorfällen bereitstellen -- security.txt ist die technische Umsetzung dieser Anforderung.
Auch das BSI empfiehlt security.txt als Best Practice für Coordinated Vulnerability Disclosure. Viele große Organisationen wie Google, GitHub und Microsoft setzen security.txt ein. Für Unternehmen, die unter NIS2 fallen, ist eine security.txt ein einfacher erster Schritt zur Compliance. Der Wolf-Agents Web Security Check bewertet security.txt mit bis zu 2 Punkten und prüft sowohl das Vorhandensein als auch die korrekte Formatierung der Pflichtfelder.
Wie steht Ihre Domain bei security.txt?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.