Kostenlos · kein Konto nötig

Security Headers Checker

Prüfe online die HTTP-Sicherheitsheader einer öffentlichen Website. Gib eine Domain ein und sieh, wie acht wichtige Sicherheitsheader in der finalen Antwort bewertet werden und, wo angezeigt, welcher Wert beobachtet wurde.

Ein kostenloser Check öffentlich zugänglicher Website-Einstellungen. Deine Website wird nicht verändert.

Keine Anmeldung Kein destruktiver Traffic Checks für öffentliche Websites
Header-Referenz

Was jeder Header bewirkt und wie er bewertet wird

Der Checker liest diese Header in einer einzigen Antwort. Die meisten Zeilen sind Präsenzprüfungen: Ein gesendeter Header zählt, und sein Wert wird angezeigt, wo verfügbar, damit du beurteilen kannst, ob er zu deiner Website passt.

HeaderWas er bewirktSo sieht es gut ausSo bewertet dieser Checker
Strict-Transport-SecurityLässt wiederkehrende Browser von sich aus zu HTTPS wechseln, bevor überhaupt eine Anfrage unverschlüsselt über HTTP rausgeht.Ein langes max-age (180 Tage oder mehr), sobald die Einführung abgeschlossen ist; der Leitfaden beschreibt die Stufen.Fehlt bei einem HTTPS-Ziel: mittel. Keine Bewertung, wenn du eine http://-Adresse eingibst.
Content-Security-PolicyGibt dem Browser eine Liste erlaubter Quellen für Code und Inhalte der Seite.Eine Richtlinie aus den Ressourcen, die deine Seiten wirklich nutzen, ohne breite Ausnahmen für Skripte.Fehlt: mittel. Der Wert wird angezeigt, aber nicht inhaltlich geprüft.
X-Frame-Options · frame-ancestorsVerhindert, dass andere Websites deine Seite in einem eigenen Frame anzeigen.frame-ancestors in deiner CSP, mit X-Frame-Options als Rückfall für ältere Browser.Keines von beiden vorhanden: mittel.
X-Content-Type-OptionsLässt den Browser beim angegebenen Inhaltstyp jeder Antwort bleiben.Der einzige Wert nosniff.Fehlt oder anderer Wert: niedrig.
Referrer-PolicyBegrenzt, welchen Teil deiner Seitenadresse andere Websites sehen, wenn Besucher deinen Links folgen.Eine Richtlinie, die mindestens so streng ist wie der aktuelle Browser-Standard.Fehlt: niedrig.
Access-Control-Allow-OriginLegt fest, welche Skripte anderer Websites deine Antworten lesen dürfen.Auf normalen Seiten nicht gesendet, oder mit genau einem vertrauenswürdigen Origin.Eine Wildcard (*): mittel.
Server · X-Powered-ByNennt die Software hinter der Antwort.Entfernt oder auf einen generischen Wert reduziert.Jeder Server- oder X-Powered-By-Header: niedrig, auch ohne Versionsnummer. Angezeigt werden nur erkannte Technologienamen.
Set-CookieSetzt Cookies; ihre Attribute entscheiden, welche Skripte sie lesen können und wann sie gesendet werden.Session-Cookies, die für Skripte unsichtbar sind und nur über HTTPS gesendet werden.Ein Cookie in dieser Antwort ohne HttpOnly oder auf HTTPS ohne Secure: mittel. SameSite wird nicht geprüft, Cookie-Werte werden nie angezeigt.

Permissions-Policy und Cross-Origin-Opener-Policy werden auf dieser Seite nicht bewertet. Der Launch-Readiness-Snapshot zählt sie nur in seiner separaten Härtungsnote.

So behebst du es

So fügst du diese Header auf deinem Server hinzu

Setze jeden Header in genau einer Schicht, die alle Anfragen beantwortet: Webserver, CDN oder Hosting-Plattform. Beginne mit den Werten unten und verschärfe sie schrittweise, während du deine wichtigsten Seiten testest.

Sichere Startwerte

  1. 01Strict-Transport-Security: max-age=300Sende ihn nur in HTTPS-Antworten; über unverschlüsseltes HTTP ignorieren Browser ihn. Erhöhe max-age schrittweise, etwa auf eine Woche, einen Monat und dann ein Jahr (31536000), und prüfe deine Website nach jedem Schritt. Füge includeSubDomains erst hinzu, wenn jede Subdomain HTTPS ausliefert, und preload erst nach dem Lesen der Anforderungen auf hstspreload.org, denn das Verlassen der Preload-Liste dauert Monate.
  2. 02Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'Report-Only blockiert nichts: Der Browser meldet, was die Richtlinie blockieren würde, in der Konsole oder an einen Reporting-Endpunkt, wenn du einen angibst. Öffne deine wichtigsten Seiten, ergänze die Quellen, die sie wirklich nutzen, und sende dieselbe Richtlinie dann als Content-Security-Policy. Vermeide 'unsafe-inline' für Skripte; Nonces oder Hashes sind die strengere Wahl.
  3. 03frame-ancestors 'self' · X-Frame-Options: SAMEORIGINframe-ancestors in einer durchgesetzten Content-Security-Policy entscheidet, welche Websites deine Seiten in einem Frame zeigen dürfen. X-Frame-Options deckt ältere Browser ab und blockiert, solange deine CSP noch im Report-Only-Modus läuft. Nutze 'none' und DENY, wenn deine Seiten nie eingebettet werden, halte beide Werte im Gleichschritt und sende frame-ancestors als Header, denn in einem meta-Tag ignorieren Browser die Direktive.
  4. 04X-Content-Type-Options: nosniffSende in jeder Antwort den einzelnen Wert nosniff. Browser lehnen dann Skripte und Stylesheets mit falschem Content-Type ab, prüfe also vorher, ob dein Server JavaScript- und CSS-Dateien korrekt auszeichnet.
  5. 05Referrer-Policy: strict-origin-when-cross-originAndere Websites erhalten nur deinen Origin, nie die vollständige Seitenadresse, und gar nichts, wenn ein Link von HTTPS zu HTTP führt. Aktuelle Browser nutzen das bereits als Standard; der Header sorgt überall für dasselbe Verhalten. Wähle same-origin oder no-referrer, wenn deine URLs private Daten enthalten.
  6. 06Permissions-Policy: camera=(), microphone=(), geolocation=()Eine leere Liste () schaltet eine Funktion für deine Seite und jeden eingebetteten Frame ab. Liste nur Funktionen auf, die deine Website nie nutzt, und teste danach Seiten mit Karten, Videoanrufen oder Zahlungs-Widgets.

Beispiele zum Kopieren nach Plattform

Jedes Beispiel setzt dieselben Startwerte. Hosting-Plattformen senden Strict-Transport-Security womöglich schon selbst, deshalb fehlt der Header in den Beispielen für Vercel, Netlify und Next.js; prüfe die echte Antwort und ergänze ihn nur, wenn er fehlt.

nginx

Setze die Zeilen in den server-Block, der HTTPS ausliefert. Der Parameter always fügt sie auch Fehlerantworten hinzu. Ein location-Block mit eigenen add_header-Zeilen verwirft alle add_header-Zeilen, die er sonst vom server-Block erben würde; wiederhole den Satz dort oder lege ihn in eine einzige include-Datei.

# In the server block that serves HTTPS (listen 443 ssl)
add_header Strict-Transport-Security "max-age=300" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Apache

Aktiviere mod_headers und füge die Zeilen dem Virtual Host für Port 443 hinzu oder einer .htaccess-Datei, wo AllowOverride FileInfo gesetzt ist. Header always set gilt auch für Fehlerantworten und Weiterleitungen.

# <VirtualHost *:443> or .htaccess; needs mod_headers (Debian/Ubuntu: a2enmod headers)
Header always set Strict-Transport-Security "max-age=300"
Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Cloudflare

Lege im Dashboard für deinen Hostnamen eine Response Header Transform Rule an und füge jeden Header mit der Operation Set static hinzu; sie ersetzt einen gleichnamigen Header deines Origins. HSTS hat eine eigene Einstellung unter SSL/TLS, Edge Certificates; nutze diese oder die Regel, nicht beides. Menünamen können je nach Dashboard-Version abweichen.

Rule type   Response Header Transform Rule
When        Hostname equals example.com
Then        Set static, one row per header:
  X-Content-Type-Options               nosniff
  Referrer-Policy                      strict-origin-when-cross-origin
  X-Frame-Options                      SAMEORIGIN
  Permissions-Policy                   camera=(), microphone=(), geolocation=()
  Content-Security-Policy-Report-Only  default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

HSTS        SSL/TLS > Edge Certificates > HTTP Strict Transport Security (HSTS)

Vercel

Füge der Datei vercel.json im Projektstamm einen headers-Eintrag hinzu. Das source-Muster /(.*) passt auf jeden Pfad; grenze es ein, wenn einzelne Routen eine andere Richtlinie brauchen.

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Content-Security-Policy-Report-Only", "value": "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" },
        { "key": "X-Frame-Options", "value": "SAMEORIGIN" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
      ]
    }
  ]
}

Netlify

Lege im Publish-Verzeichnis, dem Ordner, den Netlify ausliefert, eine Datei namens _headers an. Auf jede Pfadzeile wie /* folgen eingerückte Zeilen im Format Name: Wert. Dieselben Regeln können auch in netlify.toml unter [[headers]] stehen.

/*
  Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

Next.js

Gib die Header in next.config.js aus der Funktion async headers() zurück; source '/:path*' deckt jede Route ab. Bei einem statischen Export (output: 'export') läuft headers() nicht, setze die Header dann auf dem Host, der die exportierten Dateien ausliefert.

// next.config.js
const securityHeaders = [
  { key: 'Content-Security-Policy-Report-Only', value: "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" },
  { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
];

module.exports = {
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }];
  },
};

Führe den Checker nach dem Deployment erneut aus: Er liest die finale Antwort und zeigt daher, was dein CDN oder deine Plattform wirklich sendet. Öffne danach eine Fehlerseite und eine statische Datei in den Entwicklertools deines Browsers, denn Header werden oft nur für einen Teil der Antworten gesetzt.

Ergebnis lesen

So liest du jeden Status.

  1. 01BestandenDer Header wurde gefunden und erfüllt die Präsenzprüfung.
  2. 02Niedrig · Mittel · HochEtwas fehlt oder ist so gesetzt, dass diese Prüfung es meldet. Die Stufe ist dieselbe wie im vollständigen Snapshot.
  3. 03BeobachtetEin Wert wurde erfasst, aber die Prüfung ergab weder ein Bestanden noch einen Befund.
  4. 04Nichts beobachtetDie Prüfung lief, aber es gab nichts zu erfassen, zum Beispiel kein Cookie in der Antwort.
  5. 05Nicht zutreffendDie Prüfung trifft nicht zu, zum Beispiel HSTS, wenn du eine http://-Adresse eingibst.
  6. 06Nicht gemessenEs kam keine verwertbare Antwort, daher zählt die Prüfung nicht als bestanden.
Umfang

Was dieser Checker nicht tut.

  1. 01Er fragt nur die Startseite des eingegebenen Origins ab. Pfade und Query-Strings werden verworfen, keine andere Seite wird angefragt.
  2. 02Er prüft vor allem, ob ein Header vorhanden ist, nicht ob sein Wert zu deiner Website passt.
  3. 03Die Weiterleitung von HTTP auf HTTPS testet er nur, wenn du die http://-Adresse eingibst; dieser Lauf überspringt TLS und meldet kein fehlendes HSTS.
  4. 04Er ist kein Schwachstellenscan und kein Penetrationstest und sendet keinen Angriffsverkehr.
  5. 05Das Ergebnis ist eine Momentaufnahme einer Antwort; eine CDN-Regel oder eine andere Seite kann andere Header senden.
FAQ

Fragen zur Header-Prüfung.

Warum wird Server: nginx ohne Version markiert?

Jeder Server- oder X-Powered-By-Header wird als niedrig bewertet, weil schon der Name Besuchern verrät, welche Software die Website betreibt. Entferne den Header oder reduziere ihn auf einen generischen Wert, wenn deine Plattform das erlaubt.

Warum weicht das Ergebnis von meiner Serverkonfiguration ab?

Der Checker liest die Antwort, die er nach bis zu fünf Weiterleitungen erhält. Es zählen die Header, die ein CDN, ein Proxy oder die Hosting-Plattform hinzufügt oder entfernt, und Regeln für CDN, Proxy oder Bot-Schutz können Browsern anders antworten als dem Checker.

Kann ich eine Website prüfen, die mir nicht gehört?

Ja. Die Header-Prüfung liest eine gewöhnliche Antwort, die die Website ohnehin jedem Besucher sendet; der vollständige Lauf sendet einige weitere gewöhnliche Anfragen für die anderen Checks. Geschützte Module und vollständige Audits brauchen ein verifiziertes Ziel oder ausdrückliche Autorisierung.

Ist das ein Schwachstellenscan?

Nein. Es ist eine passive Prüfung der Antwort-Header, kein Schwachstellenscan und kein Penetrationstest, und sie beweist nicht, dass eine Website sicher ist.

Warum fehlen meine Header in manchen Antworten?

Header werden oft nur für eine Route, einen Dateityp oder einen Statuscode gesetzt. In nginx überspringt add_header ohne always Fehlerantworten, und ein location-Block mit eigenen add_header-Zeilen verwirft die des server-Blocks. Auch statische Dateien, API-Routen und Seiten, die ein anderer Dienst ausliefert, können an der Regel vorbeilaufen, die die Header setzt.

Kann ich denselben Header in der Anwendung und im CDN setzen?

Setze jeden Header in nur einer Schicht. Fügen ihn zwei Schichten hinzu, kann der Browser zwei Werte erhalten: Bei Content-Security-Policy gilt jede gesendete Richtlinie, das Ergebnis ist also strenger als jede einzelne, und bei Strict-Transport-Security wird nur der erste Header verwendet.

Sollte ich meine Domain für die HSTS-Preload-Liste anmelden?

Nur wenn jede heutige und künftige Subdomain HTTPS ausliefern kann. Die Liste verlangt ein max-age von mindestens einem Jahr mit includeSubDomains und preload; Browser nutzen für die Domain dann schon vor dem ersten Besuch HTTPS, und eine Entfernung von der Liste kann Monate brauchen, bis sie bei den Nutzern ankommt. Ein langes max-age ohne preload deckt wiederkehrende Besucher bereits ab.

Nächster Schritt

Mache aus Befunden einen klaren Plan zur Behebung.