HTTP-Sicherheits-Header analysieren mit SecurityHeaders

Was macht SecurityHeaders?

SecurityHeaders ist ein kostenloses Online-Tool zur schnellen Bewertung der HTTP-Sicherheits-Header einer Website. Es analysiert die vom Server gesendeten Response-Header, die bestimmen, wie Browser Inhalte laden und mit externen Ressourcen umgehen.

• Analyse der HTTP-Header: Automatische Prüfung aller sicherheitsrelevanten Header.
• Bewertungssystem: Vergibt eine Note von A+ bis F (Indikator, kein vollständiger Sicherheits-Audit).
  • A+ = sehr gut abgesichert
  • A–F = abhängig von Anzahl und Qualität der gesetzten Header
  • R = Redirect erkannt
• Warnungen & Empfehlungen: Hinweise zu fehlenden oder unsicheren Konfigurationen (z. B. unsafe-inline in CSP) inklusive Optimierungsvorschlägen.

Welche HTTP-Sicherheits-Header werden geprüft?

SecurityHeaders bewertet moderne Sicherheits-Header, die vor Angriffen wie XSS, Clickjacking oder Datenlecks schützen. Dazu gehören:

• Strict-Transport-Security (HSTS): Erzwingt HTTPS und verhindert Downgrade-Angriffe.
• Content-Security-Policy (CSP): Kontrolliert erlaubte Quellen für Skripte, Styles, Bilder und weitere Ressourcen.
• X-Frame-Options (XFO): Schutz vor Clickjacking durch Framing-Einschränkungen.
  Hinweis: XFO wird zunehmend durch frame-ancestors in der CSP ersetzt, bleibt aber relevant.
• X-Content-Type-Options: Verhindert MIME-Sniffing (nosniff).
• Referrer-Policy: Steuert, welche Referrer-Daten beim Navigieren übertragen werden.
• Permissions-Policy: Regelt den Zugriff auf Browser-APIs (z. B. Kamera, Mikrofon, Geolocation).
• Cross-Origin-Opener-Policy (COOP): Stärkt die Isolation zwischen Fenstern und Tabs.
• Cross-Origin-Resource-Policy (CORP): Bestimmt, wer Ressourcen laden darf.
• Cross-Origin-Embedder-Policy (COEP): Verhindert das Einbetten nicht freigegebener Ressourcen.

Ziel der Plattform

• Sensibilisierung: Verdeutlicht die Bedeutung von Sicherheits-Headern.
• Verbesserung: Liefert konkrete Empfehlungen zur Optimierung der Header-Konfiguration.
• Standardisierung: Unterstützt die Verbreitung sicherer Default-Header im Web.

Typische Anwendungsfälle

• Website-Audit: Schnell prüfen, ob essenzielle Sicherheits-Header gesetzt sind.
• Vergleich: Sicherheitsniveau anderer Websites analysieren.
• Optimierung: Empfehlungen nutzen, um ein A+-Rating zu erreichen.
• Monitoring: Regelmäßig scannen, damit Updates oder Plugins keine Header entfernen.

Für wen ist SecurityHeaders geeignet?

SecurityHeaders eignet sich für alle, die die Sicherheit ihrer Website schnell und zuverlässig überprüfen möchten. Das Tool ist besonders hilfreich für:

• Website-Betreiber: Schnelle Einschätzung, ob grundlegende Sicherheits-Header korrekt gesetzt sind.
• Entwickler und Administratoren: Technische Analyse der Header-Konfiguration und Identifikation von Optimierungspotenzial.
• Agenturen und Freelancer: Bestandteil von Website-Audits, Launch-Checks und Sicherheitsbewertungen.
• Sicherheitsverantwortliche: Ergänzendes Werkzeug zur Überprüfung von Richtlinien und Compliance-Anforderungen.

Da SecurityHeaders ausschließlich die HTTP-Header bewertet, ersetzt es keinen vollständigen Sicherheits-Audit, liefert aber eine schnelle und verlässliche Grundlage für weitere Maßnahmen.

Wie meine Website optimiert ist

Um die Sicherheit meiner Website zu verbessern, habe ich alle relevanten HTTP-Sicherheits-Header serverseitig ergänzt und optimiert. Dazu gehören unter anderem Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy sowie eine umfassende Content-Security-Policy (CSP). Diese Header werden direkt auf Serverebene gesetzt, damit sie unabhängig vom eingesetzten CMS zuverlässig greifen.

Der aktuelle SecurityHeaders-Report bestätigt die Umsetzung: Die Seite erreicht ein A-Rating und erfüllt alle wesentlichen Sicherheitsanforderungen. Die Bewertung wird lediglich durch die CSP begrenzt, da WordPress – wie viele moderne CMS – technisch bedingt auf 'unsafe-inline' und 'unsafe-eval' angewiesen ist. Diese Vorgaben stammen nicht aus individuellen Fehlkonfigurationen, sondern aus der Architektur des Systems.

Warum WordPress hier technische Grenzen hat

WordPress setzt intern zahlreiche Inline-Skripte, dynamische JavaScript-Snippets und Inline-Styles ein. Diese werden von Core-Funktionen, Themes und Plugins generiert und lassen sich nicht vollständig entfernen, ohne die Funktionsfähigkeit der Seite zu beeinträchtigen. Aus diesem Grund akzeptiert WordPress keine vollständig restriktive CSP wie script-src 'self' ohne Ausnahmen.

Die Folge: Eine sichere, aber nicht maximal strenge CSP ist der realistische Kompromiss. 'unsafe-inline' und 'unsafe-eval' sind in WordPress-Umgebungen technisch kaum vermeidbar, solange das System auf Inline-Mechanismen setzt. Dadurch wird die Sicherheitsbewertung bei SecurityHeaders automatisch auf A begrenzt – unabhängig davon, wie gut die übrigen Header konfiguriert sind.

Was ich konkret optimiert habe

• HSTS mit includeSubDomains und preload für maximale HTTPS-Durchsetzung
• X-Frame-Options: SAMEORIGIN zum Schutz vor Clickjacking
• X-Content-Type-Options: nosniff gegen MIME-Sniffing
• Referrer-Policy: strict-origin-when-cross-origin für datensparsame Weiterleitungen
• Permissions-Policy zur Deaktivierung unnötiger Browser-APIs
• Cross-Origin-Opener-Policy (COOP), Cross-Origin-Resource-Policy (CORP) und Cross-Origin-Embedder-Policy (COEP) für moderne Cross-Origin-Isolation
• Content-Security-Policy (CSP) mit restriktiven Vorgaben für Skripte, Styles, Medien, Frames und Formulare

Die Seite ist technisch so sicher wie unter WordPress realistisch möglich. Alle relevanten Sicherheits-Header sind gesetzt, und die CSP ist so restriktiv wie mit dem CMS vereinbar. Die verbleibenden Warnungen im Report sind systembedingt und betreffen ausschließlich WordPress-Mechanismen, nicht die Qualität der Konfiguration. Damit erreicht die Seite ein sehr gutes Sicherheitsniveau und schützt wirksam vor typischen Angriffsvektoren wie XSS, Clickjacking und Datenlecks.

Optional: CSP-Reporting mit Report URI

Für eine noch detailliertere Analyse von Content-Security-Policy-Verstößen kann die Plattform Report URI genutzt werden. Sie sammelt automatisch CSP-Reports, wenn Browser Verstöße melden, und hilft dabei, fehlerhafte Skripte, blockierte Ressourcen oder potenzielle Angriffsversuche frühzeitig zu erkennen.

Dies ist besonders hilfreich, wenn eine CSP schrittweise verschärft wird oder wenn komplexe Websites viele externe Ressourcen einbinden.

Mehr über Report URI erfahren

HSTS‑Preload‑Status meiner Domain

Die Domain seotologie.de erfüllt alle Anforderungen für die Aufnahme in die offizielle HSTS‑Preload‑Liste moderner Browser. Dadurch wird HTTPS bereits vor dem ersten Request erzwungen, was Angriffe wie SSL‑Stripping effektiv verhindert und die Sicherheit weiter erhöht.

Den aktuellen Status kannst du hier einsehen: HSTS Preload Check für seotologie.de

Abschließende Gesamtbewertung

SecurityHeaders ist ein kompaktes, wirkungsvolles Tool zur schnellen Bewertung der HTTP-Sicherheits-Header einer Website. Die vergebenen Noten und Empfehlungen helfen, gezielt Maßnahmen gegen Angriffe wie XSS, Clickjacking und Datenlecks umzusetzen.

Jetzt Website kostenlos mit SecurityHeaders prüfen

Häufige Fragen (FAQ)

Ersetzt SecurityHeaders einen vollständigen Sicherheits-Audit?

Nein. SecurityHeaders bewertet ausschließlich HTTP-Sicherheits-Header. Es ist ein hilfreicher Indikator, ersetzt aber keine umfassende Sicherheitsanalyse.

Warum erhalte ich trotz guter Header-Konfiguration kein A+?

Viele CMS – insbesondere WordPress – nutzen Inline-Skripte und dynamische JavaScript-Funktionen. Dadurch sind 'unsafe-inline' oder 'unsafe-eval' oft unvermeidbar, was die Bewertung technisch begrenzt.

Wie oft sollte ich meine Website mit SecurityHeaders prüfen?

Empfohlen wird eine regelmäßige Prüfung, insbesondere nach Updates, Plugin-Änderungen oder Serveranpassungen.

Kann ich die CSP vollständig ohne unsafe-inline konfigurieren?

In WordPress-Umgebungen ist das realistisch kaum möglich. Viele Core-Funktionen und Plugins setzen Inline-Skripte voraus.

Warum ist HSTS Preload wichtig?

HSTS Preload erzwingt HTTPS bereits vor dem ersten Request und verhindert Angriffe wie SSL-Stripping. Es ist ein starkes Sicherheitsmerkmal moderner Websites.