security.txt für Shopware 6
Standardisierte Kontaktdatei für Sicherheitsforscher — direkt im Shopware public/.well-known/ Verzeichnis oder per Plugin.
security.txt in Shopware 6
security.txt (RFC 9116) ist eine standardisierte Textdatei unter /.well-known/security.txt, die Sicherheitsforschern sagt, wie sie Schwachstellen verantwortungsvoll melden können. Ohne eine solche Datei landen Vulnerability Reports häufig bei generischen E-Mail-Adressen wie info@ oder werden gar nicht gemeldet. security.txt ist mit 2 von 166 Punkten im Wolf-Agents Web Security Check bewertet.
In Shopware 6 legen Sie die Datei direkt im public/.well-known/-Verzeichnis ab. Bei Self-Hosted-Installationen wird die Datei vom Webserver (Nginx/Apache) ausgeliefert, ohne dass Shopware involviert ist. Bei Shopware Cloud ist das Dateisystem nicht direkt zugänglich — hier müssen Sie die security.txt über ein Custom Plugin bereitstellen, das auf die Route /.well-known/security.txt reagiert.
Für E-Commerce-Shops ist eine security.txt besonders wichtig: Sicherheitslücken in Zahlungsformularen, XSS-Schwachstellen oder offene API-Endpoints können direkt gemeldet werden, bevor sie ausgenutzt werden. NIS2 Art. 21(e) fordert explizit ein Verfahren zur koordinierten Schwachstellenoffenlegung. Der Wolf-Agents Web Security Scanner prüft automatisch, ob eine gültige security.txt unter der Standard-URL erreichbar ist.
Implementierung
Variante A: Datei direkt im public/.well-known/-Verzeichnis anlegen. Variante B: Nginx-Konfiguration für korrekte Auslieferung. Variante C: Optionale PGP-Signatur für Authentizitätsnachweis.
# public/.well-known/security.txt
# RFC 9116 — Standardisierte Sicherheitskontaktdatei
Contact: mailto:security@ihr-shop.de
Expires: 2027-03-28T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://ihr-shop.de/.well-known/security.txt
# Optional: PGP-Schlüssel für verschlüsselte Meldungen
Encryption: https://ihr-shop.de/.well-known/pgp-key.txt
# Optional: Responsible Disclosure Policy
Policy: https://ihr-shop.de/sicherheitsrichtlinie
# Optional: Hiring-Link für Security-Fachkräfte
# Hiring: https://ihr-shop.de/karriere/security
# Acknowledgments: Danksagung an Sicherheitsforscher
# Acknowledgments: https://ihr-shop.de/hall-of-fame# Nginx — .well-known direkt ausliefern
# WICHTIG: Vor dem Shopware location-Block platzieren
location /.well-known/ {
# Direkt vom Dateisystem, nicht an Shopware weiterleiten
root /var/www/ihr-shop/public;
try_files $uri =404;
# Korrekte Content-Type Header
default_type text/plain;
add_header Content-Type "text/plain; charset=utf-8" always;
add_header X-Content-Type-Options "nosniff" always;
# Cache: 1 Tag (da Expires sich selten ändert)
add_header Cache-Control "public, max-age=86400" always;
}# Optional: PGP-Signatur erstellen
# Beweist, dass die security.txt von Ihnen stammt
# 1. PGP-Schlüsselpaar generieren (falls nicht vorhanden)
gpg --full-generate-key
# 2. security.txt signieren
gpg --clear-sign public/.well-known/security.txt
# 3. Signierte Datei als security.txt verwenden
mv public/.well-known/security.txt.asc public/.well-known/security.txt
# 4. Öffentlichen Schlüssel bereitstellen
gpg --export --armor security@ihr-shop.de > public/.well-known/pgp-key.txtDas Expires-Feld ist Pflicht nach RFC 9116 und muss im ISO 8601-Format stehen. Setzen Sie es maximal 1 Jahr in die Zukunft. Wichtig bei Shopware-Deployments: Die Datei liegt im public/-Verzeichnis und wird bei composer install oder Deployments nicht überschrieben. Tragen Sie die Datei in Ihr Git-Repository ein, damit sie bei jedem Deployment automatisch vorhanden ist.
Verifizierung
Prüfen Sie vier Aspekte: Datei erreichbar über HTTPS, korrekter Content-Type, Expires-Datum nicht abgelaufen und Canonical-URL zeigt auf HTTPS. Testen Sie auch den Zugriff über HTTP — ein Redirect auf HTTPS ist akzeptabel.
# 1. security.txt über HTTPS abrufen
curl -s https://ihr-shop.de/.well-known/security.txt
# Erwartete Ausgabe: Contact: mailto:security@ihr-shop.de
# Expires: 2027-03-28T00:00:00.000Z
# 2. HTTP-Status und Content-Type prüfen
curl -sI https://ihr-shop.de/.well-known/security.txt | head -5
# Erwartete Ausgabe: HTTP/2 200
# Content-Type: text/plain; charset=utf-8
# 3. Expires-Datum validieren (nicht abgelaufen)
curl -s https://ihr-shop.de/.well-known/security.txt | grep Expires
# 4. Canonical-URL prüfen (muss auf HTTPS zeigen)
curl -s https://ihr-shop.de/.well-known/security.txt | grep CanonicalHäufige Fehler
Shopware-Router fängt .well-known ab
In seltenen Fällen kann Shopware Requests an /.well-known/ an den Symfony-Router weiterleiten und eine 404-Seite ausliefern. Lösung: In der Nginx-Konfiguration eine explizite Location für /.well-known/ definieren, die VOR dem Shopware-Block steht und direkt vom Dateisystem ausliefert.
Expires-Datum abgelaufen
Scanner und Sicherheitsforscher werten eine abgelaufene security.txt als ungültig. Das RFC 9116 fordert ein gültiges Expires-Datum. Ein jährlicher Reminder im Kalender oder ein automatisiertes Monitoring (z.B. über Wolf-Agents) verhindert dieses Problem.
Datei im falschen Verzeichnis
Die Datei muss unter public/.well-known/security.txt liegen, nicht im Shopware-Root. Der public/-Ordner ist das Document Root für den Webserver. Eine Datei unter /var/www/ihr-shop/.well-known/ (ohne public) ist nicht erreichbar.
Contact-Feld zeigt auf nicht-überwachtes Postfach
Wenn die Contact-E-Mail-Adresse nicht regelmäßig geprüft wird, gehen Schwachstellenmeldungen verloren. Verwenden Sie eine dedizierte Adresse (z.B. security@) und leiten Sie Mails an das Sicherheitsteam weiter. Eine Response innerhalb von 72 Stunden gilt als Best Practice.
Compliance-Relevanz
Wie steht Ihre Domain bei security.txt?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.