ScrapTrap HTTP-Header Audit-Tool (Security-Header / Performance-Header) - Public Version

Erlaubte Zeichen: abcdefghijklmnopqrstuvwxyz0123456789.-äöü (IDN/Umlaut-Domains werden unterstützt)
Hinweis: Die Eingabe von nicht erlaubten Zeichen kann zu einer Funktionssperrung führen!

Nutzungsbedingungen & Haftungsausschluss:
Ich bestätige, dass ich berechtigt bin, diese Domain zu prüfen. Ich versichere, dieses Tool **nicht** zur Übertragung von Schadcode, zur Vorbereitung rechtswidriger Handlungen oder gegen den Betreiber der Zielseite zu verwenden. Eine gewerbliche Nutzung oder Verwertung der Prüfergebnisse ist ohne ausdrückliche Genehmigung untersagt.

ℹ️ Über den ScrapTrap-Scanner-Pro & Prüfumfang:

Dieses zum Gesamt-Framework ScrapTrap gehörende Tool führt eine technische und datenschutzrechtliche Statusanalyse der angegebenen Domain durch.

Server- & Header-Analyse: Prüfung auf SSL/HTTPS-Verschlüsselung, Sicherheits-Header (CSP, Permissions-Policy, HSTS) sowie Server-Exposition.
DSGVO & TDDDG Check: Erfassung von Tracking-Skripten (z. B. Google Tag Manager) und Drittanbieter-Einbindungen auf Consent-Pflicht.
Struktur- & Sicherheits-Audit: Überprüfung auf ungeschützte Systemdateien (z. B. infophp.php), Canonical-Tags, Spracheinstellungen und OpenGraph-Meta-Daten.

💡 Hinweis: Die Ergebnisse dienen der technischen Orientierung und ersetzen keine individuelle Rechtsberatung.

User-Agent auswählen

ScrapTrap-Standard

ScrapTrap-Scanner-Pro/1.0 ScrapTrap-Audit-Tool-Pro/1.0

Normale Nutzer

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36 Edg/145.0.0.0 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36 Avast/146.0.34394.179

Such-Bots

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) DuckDuckBot/1.1; (+http://duckduckgo.com/duckduckbot.html)

KI-Bots

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot) Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.3; +https://openai.com/searchbot Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Claude-SearchBot/1.0; +searchbot@anthropic.com)

Audit-Ergebnis für: google.com (über: ScrapTrap-Scanner-Pro/1.0)

Status 7: Achtung: Redirect-Kette erkannt via Server (.htaccess/Config)! Ziel: https://www.google.com/(Redirect nur auf www.-Version gültig!)
Verzögerung durch HTTPS-Check: 0.22 Sek.

Header-Array:

Array
(
    [content-type] => text/html; charset=ISO-8859-1
    [date] => Fri, 14 Aug 2026 23:27:03 GMT
    [expires] => -1
    [cache-control] => private, max-age=0
    [content-security-policy-report-only] => object-src 'none';base-uri 'self';script-src 'nonce-QTU9QJ0z5hUG0lgQkgRgCA' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
    [accept-ch] => Sec-CH-Prefers-Color-Scheme
    [p3p] => CP="This is not a P3P policy! See g.co/p3phelp for more info."
    [server] => gws
    [x-xss-protection] => 0
    [x-frame-options] => SAMEORIGIN
    [set-cookie] => __Secure-ENID=35.SE=jgFQ4Wgp-OJBgfvz4P3uQ9Gsdo2hfwp40v-0hpg1P3v4dMpVc6YT595ZVwVmMeYqoxy6oWjWMA64zfwi0VwWZjBAdwpeVikefGYESz8kBqqwTwIuZZEOnqP3IzxdZq7VWWMTAyhwXPY9pl9cO8ydg0kA9c74pAZclShk1Go1dVAzaBU8DXpx6xYENsbBi1BpsTSdMDT0TdzQuLF2lJvD; expires=Tue, 14-Sep-2027 15:45:21 GMT; path=/; domain=.google.com; Secure; HttpOnly; SameSite=lax
    [alt-svc] => h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
    [accept-ranges] => none
    [vary] => Accept-Encoding
    [connection] => close
    [transfer-encoding] => chunked
)

TLS‑Informationen

Protokoll	🟢 TLS (Version unbekannt)
Cipher Suite	🟢 unbekannt
Zertifikat gültig bis	🟢 2026-10-12
Aussteller	🟢 Google Trust Services

Sicherheitsbezogene HTTP-Header - google.com - 15.08.2026 01:27:02

Legende: 🔴 = Sicherheitskritisch - 🟢 = Vorhandensein OK - ☯ = Kontextabhängig - 🟡 = Ungefährlich, aber unnötig - 💀 = Gefährlich! Entfernen! - ℹ️ Seitentyp Info

CONTENT-SECURITY-POLICY (CSP)

Seitentyp	Relevanz	Grund
Privatseite	⬆️⬆️	ℹ️ Privatseite – ⬆️⬆️ Pflicht ℹ️ Auch kleine oder private Webseiten sind anfällig für Cross‑Site‑Scripting (XSS), z. B. durch kompromittierte Widgets, externe Skripte oder manipulierte Browser‑Extensions. Eine CSP begrenzt, welche Skripte, Styles und Medien geladen werden dürfen, und verhindert so, dass Schadcode ausgeführt wird. Selbst statische Seiten profitieren davon, weil Angriffe häufig über externe Ressourcen erfolgen, nicht über die Seite selbst.
Sammlerseite	⬆️⬆️	ℹ️ Sammlerseite – ⬆️⬆️ Pflicht ℹ️ Sammlerseiten binden oft Inhalte aus vielen Quellen ein (Bilder, Videos, Feeds, Social‑Widgets). Jede externe Quelle erhöht die Angriffsfläche. Eine CSP definiert exakt, welche Domains Skripte, Styles, Frames oder Medien liefern dürfen. Ohne CSP können manipulierte Ressourcen Schadcode einschleusen, der Besucher auf Phishing‑Seiten umleitet oder Tracking‑Skripte injiziert.
Online-Shop	⬆️⬆️	ℹ️ Online-Shop – ⬆️⬆️ Pflicht ℹ️ Shops sind ein bevorzugtes Ziel für XSS‑Angriffe, weil Angreifer Zahlungsdaten, Session‑Cookies oder Kundendaten abgreifen wollen. Eine CSP schützt Checkout‑Seiten, Formulare und Payment‑Integrationen, indem sie nur vertrauenswürdige Skript‑Quellen erlaubt. Ohne CSP können manipulierte Produktbilder, externe Skripte oder kompromittierte Werbenetzwerke Kreditkarten‑Skimmer einschleusen.
Landingpage	⬆️⬆️	ℹ️ Landingpage – ⬆️⬆️ Pflicht ℹ️ Landingpages nutzen häufig Tracking‑Pixel, Analyse‑Skripte, A/B‑Testing‑Tools und externe Marketing‑Bibliotheken. Diese Vielzahl externer Ressourcen ist ein typischer Angriffsvektor. Eine CSP verhindert, dass fremde Skripte oder Inline‑Code ausgeführt werden, und schützt Besucher vor unerwünschten Redirects, Malware‑Einbettungen oder manipulierten Werbe‑Skripten.
Blog	⬆️⬆️	ℹ️ Blog – ⬆️⬆️ Pflicht ℹ️ Blogs enthalten oft nutzergenerierte Inhalte (Kommentare, Markdown, eingebettete Medien). Diese sind klassische XSS‑Einfallstore. Eine CSP verhindert, dass manipulierte Beiträge oder kompromittierte Widgets Skripte ausführen. Sie schützt sowohl Autoren als auch Leser vor Angriffen, die über externe Ressourcen, Kommentar‑Injection oder manipulierte Plugins erfolgen.
Forum	⬆️⬆️	ℹ️ Forum – ⬆️⬆️ Pflicht ℹ️ Foren sind besonders gefährdet, weil Nutzer Inhalte posten, die HTML‑ähnlich aussehen oder bewusst Schadcode enthalten. Eine CSP blockiert Skripte in Beiträgen, Signaturen, Profilfeldern und eingebetteten Medien. Ohne CSP kann ein einzelner bösartiger Post alle eingeloggten Nutzer kompromittieren, Session‑Hijacking ermöglichen oder Admin‑Konten angreifen.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Moderne Web‑Apps laden dynamisch Skripte nach, kommunizieren mit APIs und verarbeiten sensible Daten. Eine CSP schützt die gesamte App‑Logik, indem sie nur definierte Skript‑ und Frame‑Quellen erlaubt. Ohne CSP können Angreifer Module austauschen, API‑Requests manipulieren oder Schadcode in dynamische Komponenten einschleusen. Für SPAs ist CSP ein zentraler Bestandteil der App‑Sicherheit.
Intranet	⬆️⬆️	ℹ️ Intranet – ⬆️⬆️ Pflicht ℹ️ Intranets sind besonders anfällig für interne Angriffe, z. B. durch kompromittierte Geräte, infizierte Browser‑Extensions oder manipulierte interne Links. Eine CSP verhindert, dass Schadcode im internen Netzwerk ausgeführt wird und schützt sensible Unternehmensdaten. Ohne CSP kann ein einzelner infizierter Arbeitsplatz Schadcode in interne Anwendungen einschleusen.

🔴 Fehlt!

🔄 Mögliche Folgen:
• Browser können die Seite nicht vollständig isolieren.
• Angriffe über fremde eingebettete Ressourcen werden erleichtert.
• Sicherheitsfeatures wie SharedArrayBuffer werden außer Funktion gesetzt.
• Der Schutz vor Cross‑Origin‑Leaks ist reduziert.
• XSS‑Angriffe werden deutlich einfacher.
• Angreifer können Schadcode im Browser ausführen.
• Cookies und Sitzungsdaten können ausgelesen werden.
• Externe Skripte können unkontrolliert geladen werden.
• Risiko für Session‑Hijacking und Datenverlust.

⚠️ Hinweis:
Anstelle eines echten CSP-Headers wurde hier ["content-security-policy-report-only"] gesetzt.
Dies ist kein brauchbarer Ersatz für einen echten CSP-Header!
Wie der Name content-security-policy-report-only bereits aussagt, werden hier Verstöße nur protokolliert, aber nicht unterbunden.

Empfehlung:
Setzen Sie einen echten CSP-Header (content-security-policy).
Hinweis für ScrapTrap-Anwender: Sie können diesen Header in der Admin unter "Header Management" bearbeiten.

CROSS‑ORIGIN‑EMBEDDER‑POLICY (COEP)

Seitentyp	Relevanz	Grund
Privatseite	⛔	ℹ️ Privatseite – ⛔ Schädlich ℹ️ COEP blockiert standardmäßig alle externen Ressourcen, die nicht ausdrücklich mit CORP (CROSS‑ORIGIN‑RESOURCE‑POLICY) oder CORS (CROSS-ORIGIN-RESOURCE-SHARING) freigegeben wurden. Privatseiten nutzen häufig einfache Einbettungen wie Bilder, Videos, Social‑Media‑Widgets oder externe Skripte. Da diese Quellen fast nie die erforderlichen Header setzen, würden viele Inhalte nicht mehr angezeigt. Da Privatseiten keine Cross‑Origin‑Isolation benötigen, verursacht COEP hier nur Funktionsverlust ohne Sicherheitsgewinn. COEP, CORP und CORS wirken also zusammen im Verbund, und nur in der Kombination macht das Setzen dieser Header Sinn. Ergibt das Audit, dass z.B. nur einer dieser Header gesetzt ist, so könnte es sinnvoll sein, zu überprüfen, ob dies tatsächlich notwendig ist und nicht eventuell sogar zu Funktionseinschränkungen führt.
Sammlerseite	⛔	ℹ️ Sammlerseite – ⛔ Schädlich ℹ️ Sammlerseiten leben von externen Medienquellen: Bilder, Videos, Feeds, eingebettete Inhalte. COEP blockiert diese Ressourcen vollständig, wenn die fremden Server keine CORP‑ oder CORS‑Header setzen — was bei fremden Quellen praktisch nie der Fall ist. Dadurch würden große Teile der Seite leer bleiben. Da Sammlerseiten keine High‑Security‑APIs benötigen, ist COEP hier kontraproduktiv. COEP, CORP und CORS wirken also zusammen im Verbund, und nur in der Kombination macht das Setzen dieser Header Sinn. Ergibt das Audit, dass z.B. nur einer dieser Header gesetzt ist, so könnte es sinnvoll sein, zu überprüfen, ob dies tatsächlich notwendig ist und nicht eventuell sogar zu Funktionseinschränkungen führt.
Online-Shop	⛔	ℹ️ Online-Shop – ⛔ Schädlich ℹ️ Shops verwenden zahlreiche externe Dienste wie Payment‑Provider, Betrugserkennung, Tracking‑Skripte, Produktbilder aus CDNs oder eingebettete Zahlungsfenster. COEP blockiert diese Inhalte, sofern sie nicht explizit freigegeben wurden. Das kann Checkout‑Prozesse, Zahlungsabwicklungen oder Produktdarstellungen lahmlegen. Da Shops keine Cross‑Origin‑Isolation benötigen, bringt COEP hier keinen Vorteil, sondern gefährdet die Funktionsfähigkeit. COEP, CORP und CORS wirken also zusammen im Verbund, und nur in der Kombination macht das Setzen dieser Header Sinn. Ergibt das Audit, dass z.B. nur einer dieser Header gesetzt ist, so könnte es sinnvoll sein, zu überprüfen, ob dies tatsächlich notwendig ist und nicht eventuell sogar zu Funktionseinschränkungen führt.
Landingpage	⛔	ℹ️ Landingpage – ⛔ Schädlich ℹ️ Landingpages nutzen Marketing‑Skripte, Analyse‑Tools, externe Fonts, Videos und Social‑Widgets. COEP verhindert das Laden dieser Ressourcen, wenn sie nicht korrekt freigegeben sind — was bei Marketing‑Netzwerken eher selten der Fall sein dürfte. Dies führt zu fehlenden Videos, zerstörten Layouts und nicht funktionierenden Tracking‑Mechanismen. Da Landingpages keine Web‑App‑Features benötigen, ist COEP hier ungeeignet. COEP, CORP und CORS wirken also zusammen im Verbund, und nur in der Kombination macht das Setzen dieser Header Sinn. Ergibt das Audit, dass z.B. nur einer dieser Header gesetzt ist, so könnte es sinnvoll sein, zu überprüfen, ob dies tatsächlich notwendig ist und nicht eventuell sogar zu Funktionseinschränkungen führt.
Blog	⛔	ℹ️ Blog – ⛔ Schädlich ℹ️ Blogs binden häufig externe Medien ein wie z.B. YouTube‑Videos, Tweets, Karten, Bilder aus CDNs oder Widgets. COEP blockiert diese Inhalte, wenn die externen Server keine CORP‑ oder CORS‑Header setzen. Dadurch würden viele Beiträge unvollständig oder unbrauchbar. Da Blogs keine Cross‑Origin‑Isolation benötigen, erzeugt COEP hier nur Kompatibilitätsprobleme. COEP, CORP und CORS wirken also zusammen im Verbund, und nur in der Kombination macht das Setzen dieser Header Sinn. Ergibt das Audit, dass z.B. nur einer dieser Header gesetzt ist, so könnte es sinnvoll sein, zu überprüfen, ob dies tatsächlich notwendig ist und nicht eventuell sogar zu Funktionseinschränkungen führt.
Forum	⛔	ℹ️ Forum – ⛔ Schädlich ℹ️ Foren enthalten nutzergenerierte Inhalte, die oft externe Bilder, Videos oder eingebettete Medien enthalten. COEP blockiert diese Ressourcen vollständig, da sie fast nie die erforderlichen Freigabe‑Header besitzen. Das führt zu kaputten Beiträgen und frustrierten Nutzern. Da Foren keine High‑Security‑APIs benötigen, ist COEP hier hinderlich und verursacht Funktionsverlust. COEP, CORP und CORS wirken also zusammen im Verbund, und nur in der Kombination macht das Setzen dieser Header Sinn. Ergibt das Audit, dass z.B. nur einer dieser Header gesetzt ist, so könnte es sinnvoll sein, zu überprüfen, ob dies tatsächlich notwendig ist und nicht eventuell sogar zu Funktionseinschränkungen führt.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Moderne Web‑Apps benötigen Cross‑Origin‑Isolation, um leistungsstarke Browser‑Features nutzen zu können, wie z.B. SharedArrayBuffer, OffscreenCanvas, WebAssembly‑Optimierungen oder präzise Timing‑APIs. COEP ist dafür zwingend erforderlich. Er stellt sicher, dass nur explizit freigegebene Ressourcen eingebettet werden dürfen und schützt die App vor Supply‑Chain‑Angriffen, kompromittierten Skripten und Cross‑Origin‑Leaks. Für SPAs und SaaS‑Plattformen ist COEP ein zentraler Bestandteil moderner Sicherheitsarchitektur. COEP, CORP und CORS wirken also zusammen im Verbund, und nur in der Kombination macht das Setzen dieser Header Sinn. Ergibt das Audit, dass z.B. nur einer dieser Header gesetzt ist, so könnte es sinnvoll sein, zu überprüfen, ob hier nicht eine vermeidbare Sicherheitslücke vorliegt.
Intranet	➡️	ℹ️ Intranet – ➡️ Situativ sinnvoll / kontextabhängig ℹ️ Intranets nutzen häufig interne Anwendungen, Legacy‑Systeme (also technisch eigentlich veraltete Funktionen oder Techniken) oder eingebettete Inhalte ohne moderne Header. COEP kann diese Ressourcen blockieren und interne Workflows stören. Wenn das Intranet jedoch moderne Web‑App‑Funktionen nutzt (z. B. SharedArrayBuffer für Visualisierungen oder komplexe interne Tools), kann COEP sinnvoll sein. In klassischen Intranets ist er eher hinderlich, in modernen Web‑Apps innerhalb des Unternehmens dagegen ein Sicherheitsgewinn. COEP, CORP und CORS wirken also zusammen im Verbund, und nur in der Kombination macht das Setzen dieser Header Sinn. Ergibt das Audit, dass z.B. nur einer dieser Header gesetzt ist, so könnte es sinnvoll sein, zu überprüfen, ob dies tatsächlich notwendig ist und nicht eventuell sogar zu Funktionseinschränkungen führt oder ob hier nicht eine vermeidbare Sicherheitslücke vorliegt.

☯ Nicht gesetzt

☯ Kontextabhängiger Header

🧠 - COEP wird nur benötigt, wenn eine Seite Cross‑Origin‑Isolation erreichen soll. Dies ist vor allem relevant, wenn

• eingebettete Ressourcen (iframes, Bilder, Fonts, Scripts) aus fremden Domains stammen,
• moderne Features wie SharedArrayBuffer, Performance‑APIs oder WebAssembly‑Optimierungen genutzt werden oder
• die Seite in sicherheitskritischen Kontexten läuft (z. B. Passwort‑Tools, Kryptografie, Sandbox‑Umgebungen).

Wenn Ihre Seite keine fremden Ressourcen einbettet, ist das Fehlen von COEP unproblematisch. Wenn doch, kann das Fehlen zu Einschränkungen oder Sicherheitsrisiken führen.

🔄 Mögliche Folgen:
• Browser können Ihre Seite nicht vollständig isolieren.
• Angriffe über fremde eingebettete Ressourcen werden erleichtert.
• Sicherheitsfeatures wie SharedArrayBuffer werden außer Funkton gesetzt.
• Der Schutz vor Cross‑Origin‑Leaks wird stark eingeschränkt.

CROSS-ORIGIN-OPENER-POLICY (COOP)

Seitentyp	Relevanz	Grund
Privatseite	➡️	ℹ️ Privatseite – ➡️ Optional ℹ️ COOP verhindert, dass fremde Seiten über window.opener auf die eigene Seite zugreifen können. Für einfache Privatseiten ohne komplexe Skript‑Interaktionen oder Popup‑Kommunikation bringt das kaum Vorteile. Gleichzeitig kann COOP das Verhalten externer Links verändern, etwa wenn Links in neuen Tabs geöffnet werden. Daher ist COOP hier optional: technisch möglich, aber selten notwendig.
Sammlerseite	➡️	ℹ️ Sammlerseite – ➡️ Optional ℹ️ Sammlerseiten nutzen häufig externe Medien und Links zu Drittseiten. COOP bietet hier nur einen geringen Sicherheitsgewinn, da Sammlerseiten keine Fenster‑ oder Tab‑Kommunikation benötigen. Gleichzeitig kann COOP das Verhalten externer Links beeinflussen und bestimmte Interaktionen unerwartet blockieren. Daher ist COOP optional, aber nicht empfehlenswert, wenn viele externe Quellen eingebunden sind.
Online-Shop	➡️	ℹ️ Online‑Shop – ➡️ Optional (mit Vorsicht) ℹ️ Shops öffnen gelegentlich externe Zahlungsfenster oder Weiterleitungen zu Payment‑Providern. COOP kann diese Abläufe beeinflussen, indem es die Verbindung zwischen Hauptseite und Zahlungsfenster trennt. Das ist sicherheitstechnisch nicht zwingend notwendig und kann sogar zu Problemen bei Zahlungsprozessen führen. COOP ist daher nur optional und sollte nur eingesetzt werden, wenn alle externen Dienste kompatibel sind.
Landingpage	➡️	ℹ️ Landingpage – ➡️ Optional ℹ️ Landingpages nutzen häufig Marketing‑Skripte, Tracking‑Tools und externe Weiterleitungen. COOP bietet hier keinen relevanten Sicherheitsvorteil, da Landingpages keine Fenster‑Kommunikation benötigen. Gleichzeitig kann COOP das Verhalten von Analyse‑Tools oder externen Links beeinflussen. Daher ist COOP optional, aber in der Praxis selten sinnvoll.
Blog	➡️	ℹ️ Blog – ➡️ Optional ℹ️ Blogs öffnen häufig externe Links in neuen Tabs, benötigen aber keine Isolation zwischen Fenstern. COOP verhindert zwar Cross‑Window‑Zugriffe, aber Blogs profitieren davon kaum. Gleichzeitig kann COOP das Verhalten externer Links oder eingebetteter Inhalte beeinflussen. Daher ist COOP optional und sollte nur eingesetzt werden, wenn keine externen Interaktionen beeinträchtigt werden.
Forum	➡️	ℹ️ Forum – ➡️ Optional ℹ️ Foren enthalten viele externe Links und eingebettete Inhalte. COOP schützt zwar vor Cross‑Window‑Angriffen, bietet aber keinen Schutz vor den typischen Risiken von Foren wie XSS (vgl. X-CONTENT-TYPE-OPTIONS) oder manipulierten Beiträgen. Gleichzeitig kann COOP das Verhalten externer Links verändern. Daher ist COOP optional - technisch möglich, aber selten sinnvoll für klassische Foren.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Moderne Web‑Apps benötigen COOP, um Cross‑Origin‑Isolation zu erreichen — insbesondere in Kombination mit COEP. Diese Isolation ist Voraussetzung für leistungsstarke Browser‑Features wie SharedArrayBuffer, OffscreenCanvas, WebAssembly‑Optimierungen oder präzise Timing‑APIs. COOP verhindert außerdem, dass fremde Seiten über window.opener auf die App zugreifen können, was Clickjacking‑ähnliche Angriffe und Datenlecks verhindert. Für SPAs und SaaS‑Plattformen ist COOP ein zentraler Sicherheitsbaustein und praktisch unverzichtbar.
Intranet	⬆️	ℹ️ Intranet – ⬆️ Empfohlen (jedoch abhängig von Legacy‑Systemen) ℹ️ Intranets enthalten oft interne Tools, Legacy‑Anwendungen (meist technisch veraltet, häufig aber noch für bestimmte Funktionen oder Workflows benötigt) oder eingebettete Systeme, die Fenster‑Kommunikation benötigen. COOP kann diese Interaktionen stören. Wenn das Intranet jedoch moderne Web‑Apps enthält oder sensible interne Daten verarbeitet, bietet COOP einen deutlichen Sicherheitsgewinn, indem es Cross‑Window‑Angriffe verhindert und interne Anwendungen isoliert. Daher ist COOP empfohlen, aber nur dann sinnvoll, wenn keine alten Systeme beeinträchtigt werden.

☯ Nicht gesetzt

☯ Kontextabhängiger Header

🧠 - COOP legt fest, ob Ihre Seite in einer eigenen Browsing‑Context‑Gruppe läuft. Dies schützt vor unerwünschten Interaktionen mit fremden Seiten, z. B. über

• window.opener,
• Tab‑ / Fenster‑Manipulation,
• Cross‑Origin‑Leaks zwischen geöffneten Seiten.

COOP ist nur erforderlich, wenn Ihre Seite Cross‑Origin‑Isolation benötigt (COOP + COEP) oder wenn Sie sicherstellen möchten, dass fremde Seiten keine Kontrolle über Ihre Fenster erhalten. Wenn Ihre Seite keine Isolation benötigt, ist das Fehlen von COOP unproblematisch. Falls doch, kann das Fehlen des Headers nachteilig sein.

🔄 Mögliche Folgen:
• Andere Seiten könnten Ihr Browser-Fenster manipulieren.
• Stark erhöhtes Risiko für Tabnapping‑Angriffe.
• Verringerte Isolation zwischen Browser‑Kontexten.
• Bestimmte moderne Sicherheitsfeatures könnten in ihrer Funktion stark eingeschränkt werden.

CROSS‑ORIGIN‑RESOURCE‑POLICY (CORP)

Seitentyp	Relevanz	Grund
Privatseite	➡️	ℹ️ Privatseite – ➡️ Optional ℹ️ CORP verhindert, dass andere Webseiten Inhalte dieser Seite ohne Erlaubnis einbetten oder auslesen. Für einfache Privatseiten ist das selten relevant, da sie kaum sensible Daten oder APIs bereitstellen. Der Header kann dennoch sinnvoll sein, um das ungewollte Einbetten von Bildern oder Seiteninhalten zu verhindern. Da Privatseiten jedoch meist keine sicherheitskritischen Ressourcen anbieten, ist CORP optional.
Sammlerseite	➡️	ℹ️ Sammlerseite – ➡️ Optional ℹ️ Sammlerseiten stellen häufig nur statische Inhalte bereit und bieten keine APIs oder sensiblen Daten an. CORP kann verhindern, dass fremde Seiten Bilder oder Inhalte ohne Erlaubnis einbetten, ist aber nicht zwingend notwendig. Da Sammlerseiten selbst viele externe Quellen nutzen, aber selten selbst Ziel von Cross‑Origin‑Leaks sind, bleibt CORP hier eine optionale, aber nicht zwingende Maßnahme.
Online-Shop	⬆️	ℹ️ Online‑Shop – ⬆️ Wichtig ℹ️ Shops verarbeiten personenbezogene Daten, Zahlungsinformationen und interne API‑Antworten. CORP verhindert, dass fremde Webseiten Shop‑Ressourcen unbefugt einbetten oder auslesen, was Angriffe wie Cross‑Site‑Leaks erschwert. Besonders bei Checkout‑Seiten, Produkt‑APIs oder personalisierten Bereichen schützt CORP vor Datenabfluss und Missbrauch. Für Shops ist CORP daher eine wichtige Ergänzung zu CSP und CORS.
Landingpage	➡️	ℹ️ Landingpage – ➡️ Optional ℹ️ Landingpages enthalten meist statische Inhalte, Marketing‑Skripte und Tracking‑Pixel, aber keine sensiblen Daten oder APIs. CORP bietet hier nur begrenzten Mehrwert, da Landingpages selten Ziel von Cross‑Origin‑Leaks sind. Er kann dennoch verhindern, dass fremde Seiten Inhalte ungewollt einbetten, ist aber nicht zwingend notwendig. Für klassische Marketing‑Seiten bleibt CORP optional.
Blog	➡️	ℹ️ Blog – ➡️ Optional ℹ️ Blogs veröffentlichen öffentliche Inhalte, die oft bewusst geteilt oder eingebettet werden sollen. CORP kann verhindern, dass fremde Seiten Blog‑Inhalte ohne Erlaubnis einbetten, bietet aber keinen direkten Schutz vor typischen Blog‑Risiken wie XSS oder manipulierten Kommentaren. Da Blogs selten sensible Daten ausliefern, ist CORP hier optional und vor allem ein Schutz gegen unerwünschtes Hotlinking.
Forum	⬆️	ℹ️ Forum – ⬆️ Empfohlen ℹ️ Foren enthalten nutzerspezifische Inhalte, Profilinformationen und oft interne API‑Antworten. CORP verhindert, dass fremde Webseiten diese Ressourcen unbefugt einbetten oder auslesen, was Cross‑Site‑Leaks und Datenabfluss erschwert. Da Foren häufig Ziel von Scraping, Session‑Angriffen und Profil‑Harvesting sind, bietet CORP einen wichtigen zusätzlichen Schutz. Für Foren ist CORP daher empfehlenswert.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Moderne Web‑Apps verarbeiten interne API‑Daten, Nutzerinformationen und dynamische Inhalte. CORP ist ein zentraler Bestandteil der Cross‑Origin‑Isolation und verhindert, dass fremde Seiten App‑Ressourcen unbefugt einbetten oder auslesen. In Kombination mit COOP und COEP schützt CORP vor Cross‑Site‑Leaks, Supply‑Chain‑Angriffen und Datenabfluss. Für SPAs und SaaS‑Plattformen ist CORP unverzichtbar.
Intranet	⬆️	ℹ️ Intranet – ⬆️ Empfohlen ℹ️ Intranets enthalten sensible interne Daten, interne APIs und vertrauliche Dokumente. CORP verhindert, dass externe Webseiten diese Ressourcen unbefugt einbetten oder auslesen können — ein wichtiger Schutz gegen interne Angriffe, kompromittierte Geräte oder bösartige Browser‑Extensions. Da Intranets oft in geschlossenen Netzwerken laufen, ist CORP ein sinnvoller zusätzlicher Sicherheitslayer.

☯ Nicht gesetzt

☯ Kontextabhängiger Header

🧠 - CORP steuert, ob andere Webseiten Ihre Ressourcen einbetten dürfen. Er schützt also Ihre Inhalte, nicht die des Besuchers.
CORP ist sinnvoll, wenn

• Ihre Seite schützenswerte Ressourcen bereitstellt,
• Hotlinking verhindert werden soll,
• Sie Cross‑Origin‑Isolation (COOP + COEP + CORP) anstreben oder
• Sie verhindern möchten, dass fremde Seiten Ihre Skripte, Bilder oder Fonts einbinden.

Wenn Ihre Seite keine sensiblen Ressourcen bereitstellt, ist CORP optional. Falls doch, kann dies nachteilig sein.

🔄 Mögliche Folgen:
• Andere Seiten können Ihre Ressourcen "hotlinken", also z.B. einfach Bilder per <img src=... in Seiten oder Foren einbinden.
• Erhöhtes Risiko für Datenlecks über eingebettete Ressourcen.
• Verringerter Schutz vor Cross‑Origin‑Angriffen.
• Performance‑Probleme durch Fremdnutzung Ihrer Assets bzw. Medieninhalte.
• Möglicherweise erhöhte Server- und damit Hostingkosten durch massenhaften Fremdabruf.

CROSS-ORIGIN-RESOURCE-SHARING (CORS)

Seitentyp	Relevanz	Grund
Privatseite	⛔	ℹ️ Privatseite – ⛔ Nicht sinnvoll ℹ️ CORS erlaubt fremden Webseiten den Zugriff auf Ressourcen dieser Seite. Für Privatseiten ist das unnötig und potenziell riskant, da sie keine APIs oder Cross‑Origin‑Datenflüsse benötigen. Ein falsch konfiguriertes CORS‑Header‑Set kann sogar ungewollt Daten für andere Domains freigeben. Da Privatseiten meist rein statisch sind und keine externe Nutzung ihrer Inhalte benötigen, sollte CORS hier nicht eingesetzt werden. CORS ist einer der am meisten missverstandenen Header überhaupt; vereinfacht kann aber gesagt werden, dass CORS für klassische Webseiten schädlich, für Web‑Apps aber als essentiell angesehen werden kann.
Sammlerseite	⛔	ℹ️ Sammlerseite – ⛔ Nicht sinnvoll ℹ️ Sammlerseiten stellen Inhalte bereit, die von Besuchern konsumiert, aber nicht programmatisch von anderen Domains abgefragt werden sollen. CORS würde fremden Webseiten erlauben, Ressourcen automatisiert auszulesen oder zu spiegeln. Da Sammlerseiten keine APIs anbieten und keine Cross‑Origin‑Kommunikation benötigen, ist CORS hier überflüssig und kann sogar Scraping erleichtern. CORS ist einer der am meisten missverstandenen Header überhaupt; vereinfacht kann aber gesagt werden, dass CORS für klassische Webseiten schädlich, für Web‑Apps aber als essentiell angesehen werden kann.
Online-Shop	➡️	ℹ️ Online‑Shop – ➡️ Situativ sinnvoll ℹ️ Shops nutzen gelegentlich externe Dienste oder Subdomains für Produkt‑APIs, Zahlungsprozesse oder Kundenkonten. In solchen Fällen kann CORS notwendig sein, um gezielt bestimmte Domains freizuschalten. Gleichzeitig ist CORS ein Risiko, wenn es zu weit gefasst ist (z. B. Access-Control-Allow-Origin: *), da dadurch interne API‑Antworten für fremde Seiten zugänglich werden. Für Shops gilt: CORS nur dort einsetzen, wo es technisch zwingend erforderlich ist. CORS ist einer der am meisten missverstandenen Header überhaupt; vereinfacht kann aber gesagt werden, dass CORS für klassische Webseiten schädlich, für Web‑Apps aber als essentiell angesehen werden kann.
Landingpage	⛔	ℹ️ Landingpage – ⛔ Nicht sinnvoll ℹ️ Landingpages liefern statische Inhalte und Marketing‑Skripte, benötigen aber keine Cross‑Origin‑API‑Zugriffe. CORS würde fremden Webseiten erlauben, Inhalte automatisiert auszulesen oder Tracking‑Daten abzufragen. Da Landingpages keine programmatische Nutzung ihrer Ressourcen benötigen, ist CORS hier unnötig und potenziell schädlich. CORS ist einer der am meisten missverstandenen Header überhaupt; vereinfacht kann aber gesagt werden, dass CORS für klassische Webseiten schädlich, für Web‑Apps aber als essentiell angesehen werden kann.
Blog	⛔	ℹ️ Blog – ⛔ Nicht sinnvoll ℹ️ Blogs veröffentlichen öffentliche Inhalte, die zwar gelesen, aber nicht programmatisch von fremden Domains abgefragt werden sollen. CORS kann Scraping erleichtern und bietet keinen Schutz vor typischen Blog‑Risiken wie XSS oder manipulierten Kommentaren. Da Blogs keine APIs bereitstellen, ist CORS hier überflüssig und sollte vermieden werden. CORS ist einer der am meisten missverstandenen Header überhaupt; vereinfacht kann aber gesagt werden, dass CORS für klassische Webseiten schädlich, für Web‑Apps aber als essentiell angesehen werden kann.
Forum	➡️	ℹ️ Forum – ➡️ Situativ sinnvoll ℹ️ Foren nutzen gelegentlich APIs für mobile Apps, externe Clients oder Subdomains (z. B. api.domain.tld). In solchen Fällen kann CORS notwendig sein, um gezielt bestimmte Domains freizuschalten. Gleichzeitig ist ein falsch gesetztes CORS‑Header‑Set ein Risiko, da es fremden Seiten Zugriff auf Profil‑ oder Beitragsdaten ermöglichen kann. Für Foren gilt: CORS nur einsetzen, wenn eine API oder App dies explizit benötigt. CORS ist einer der am meisten missverstandenen Header überhaupt; vereinfacht kann aber gesagt werden, dass CORS für klassische Webseiten schädlich, für Web‑Apps aber als essentiell angesehen werden kann.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Moderne Web‑Apps kommunizieren intensiv mit APIs, oft über mehrere Subdomains oder externe Dienste. CORS ist hier unverzichtbar, um kontrollierte Cross‑Origin‑Zugriffe zu ermöglichen. Ohne korrekt konfiguriertes CORS funktionieren Login‑Flows, API‑Requests, Upload‑Services oder OAuth‑Integrationen nicht. Für SPAs und SaaS‑Plattformen ist CORS ein zentraler Bestandteil der Architektur und zwingend erforderlich. CORS ist einer der am meisten missverstandenen Header überhaupt; vereinfacht kann aber gesagt werden, dass CORS für klassische Webseiten schädlich, für Web‑Apps aber als essentiell angesehen werden kann.
Intranet	⬆️	ℹ️ Intranet – ⬆️ Empfohlen ℹ️ Intranets nutzen häufig interne APIs, Microservices oder Subdomains, die miteinander kommunizieren müssen. CORS ermöglicht diese kontrollierten Zugriffe innerhalb des internen Netzwerks. Gleichzeitig verhindert eine restriktive Konfiguration, dass externe Webseiten auf interne Ressourcen zugreifen können. Für moderne Intranets ist CORS daher sinnvoll, solange es gezielt und nicht zu weit gefasst eingesetzt wird. CORS ist einer der am meisten missverstandenen Header überhaupt; vereinfacht kann aber gesagt werden, dass CORS für klassische Webseiten schädlich, für Web‑Apps aber als essentiell angesehen werden kann.

☯ Nicht gesetzt

☯ Kontextabhängiger Header

🧠 - CORS agiert nicht als einzelner Header, sondern stellt einen Mechanismus dar, der über mehrere Header gesteuert wird (z. B. Access-Control-Allow-Origin). Er wird nur benötigt, wenn externe Clients (andere Webseiten, Apps, APIs) auf Ihre Ressourcen zugreifen sollen. Wenn Ihre Seite keine API bereitstellt und nicht von fremden Domains aus angesprochen werden muss, ist das Fehlen von CORS völlig normal. Falls doch, können aus dem Fehlen des Headers Nachteile entstehen.

🔄 Mögliche Folgen:
• Externe Clients können nicht auf Ihre Ressourcen zugreifen.
• API‑Aufrufe von anderen Domains schlagen fehl.
• Integrationen (z.B. Apps, externe Tools) schlagen fehl.
• Legitimer Zugriff von anderen Domains wird verhindert.

Insgesamt eher ein Funktions- als ein Sicherheitsproblem, spielt jedoch in diesen Bereich hinein, insbesondere wenn Werte falsch gesetzt sind.

PERMISSIONS-POLICY

Seitentyp	Relevanz	Grund
Privatseite	➡️	ℹ️ Privatseite – ➡️ Optional ℹ️ Privatseiten nutzen in der Regel keine sensiblen Browser‑APIs wie Kamera, Mikrofon oder Geolocation. Eine Permissions‑Policy kann dennoch sinnvoll sein, um ungewollte Funktionen zu blockieren — etwa wenn externe Widgets eingebunden werden, die Zugriff auf Sensoren oder Autoplay benötigen. Da Privatseiten jedoch selten komplexe Interaktionen bieten, ist der Header optional und dient vor allem der Absicherung gegen unerwartete API‑Nutzung.
Sammlerseite	➡️	ℹ️ Sammlerseite – ➡️ Optional ℹ️ Sammlerseiten binden häufig externe Medien, Galerien oder Widgets ein. Eine Permissions‑Policy kann verhindern, dass eingebettete Inhalte unerwartet auf Kamera, Mikrofon, Bewegungssensoren oder andere APIs zugreifen. Da Sammlerseiten selbst keine erweiterten Browser‑Funktionen benötigen, ist der Header optional, aber nützlich, um externe Einbettungen zu kontrollieren und Datenschutzrisiken zu reduzieren.
Online-Shop	⬆️	ℹ️ Online‑Shop – ⬆️ Empfohlen ℹ️ Shops nutzen moderne Browser‑APIs wie Payment‑Request‑API, Autofill‑Mechanismen oder teilweise Geolocation für Versandoptionen. Eine Permissions‑Policy verhindert, dass eingebettete Inhalte oder kompromittierte Skripte unbefugt auf sensible Funktionen zugreifen. Sie schützt Kunden vor Missbrauch von Kamera, Mikrofon, Sensoren oder Payment‑APIs und reduziert das Risiko manipulierter iFrames. Für Shops ist der Header daher ein wichtiger Bestandteil der Sicherheitsarchitektur.
Landingpage	➡️	ℹ️ Landingpage – ➡️ Optional ℹ️ Landingpages verwenden meist nur Tracking‑Skripte, Formulare und Marketing‑Tools, aber keine erweiterten Browser‑APIs. Eine Permissions‑Policy kann verhindern, dass externe Skripte ungewollt Funktionen wie Geolocation, Autoplay oder Sensoren nutzen. Da Landingpages jedoch selten komplexe Interaktionen benötigen, ist der Header optional und dient vor allem der Absicherung gegen übergriffige Marketing‑Bibliotheken.
Blog	➡️	ℹ️ Blog – ➡️ Optional ℹ️ Blogs binden häufig externe Medien wie Videos, Karten oder Social‑Widgets ein. Eine Permissions‑Policy kann verhindern, dass eingebettete Inhalte Zugriff auf Kamera, Mikrofon, Sensoren oder Clipboard erhalten. Da Blogs selbst keine erweiterten Browser‑Funktionen benötigen, ist der Header optional, aber sinnvoll, um die Auswirkungen externer Einbettungen zu begrenzen und Datenschutzrisiken zu minimieren.
Forum	⬆️	ℹ️ Forum – ⬆️ Empfohlen ℹ️ Foren enthalten nutzergenerierte Inhalte, die oft externe Medien, iFrames oder eingebettete Tools beinhalten können. Eine Permissions‑Policy verhindert, dass solche Inhalte unerwartet auf sensible Browser‑APIs zugreifen. Sie schützt Nutzer vor bösartigen Einbettungen, die Kamera, Mikrofon, Sensoren oder Clipboard missbrauchen könnten. Da Foren ein hohes Risiko für Content‑Injection haben, ist der Header hier besonders wichtig.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Moderne Web‑Apps nutzen häufig erweiterte Browser‑APIs: Kamera für Video‑Calls, Mikrofon für Meetings, Geolocation, Clipboard‑Zugriff, Vollbild‑Modus, Payment‑API, Web‑Share oder Sensor‑Daten. Die Permissions‑Policy ist hier unverzichtbar, um granular zu steuern, welche Funktionen die App selbst und eingebettete Inhalte nutzen dürfen. Sie verhindert Missbrauch durch externe Skripte, schützt sensible Daten und ist ein zentraler Bestandteil moderner Web‑App‑Sicherheit.
Intranet	⬆️⬆️	ℹ️ Intranet – ⬆️⬆️ Pflicht ℹ️ Intranets enthalten oft interne Tools, Dashboards, Video‑Konferenz‑Systeme oder Anwendungen, die erweiterte Browser‑APIs nutzen. Gleichzeitig besteht ein erhöhtes Risiko durch kompromittierte Geräte oder interne Angriffe. Die Permissions‑Policy ermöglicht eine präzise Kontrolle darüber, welche Funktionen interne Anwendungen nutzen dürfen und welche blockiert werden. Sie schützt vor Missbrauch sensibler APIs wie Kamera, Mikrofon, Geolocation oder Clipboard und ist daher für moderne Intranets besonders wichtig.

🔴 Fehlt!

🔄 Mögliche Folgen:
Ohne diese Policy hat die Webseite keine explizite Kontrolle darüber, welche Browser-Funktionen (Kamera, Mikrofon, Geolocation, USB-Zugriff) durch Drittanbieter-Skripte aktiviert werden können. Im Falle einer Kompromittierung erhöht dies das Missbrauchspotenzial erheblich. Eingebettete Inhalte könnten mehr Rechte erhalten als beabsichtigt, zudem erhöht sich das Risiko bei kompromittierten Skripten

REFERRER-POLICY

Seitentyp	Relevanz	Grund
Privatseite	⬆️⬆️	ℹ️ Privatseite – ⬆️⬆️ Pflicht ℹ️ Ohne Referrer‑Policy sendet der Browser beim Anklicken externer Links die vollständige URL der Privatseite an fremde Domains. Dadurch können persönliche Inhalte, interne Strukturen oder sensible Parameter offengelegt werden. Eine strikte Referrer‑Policy verhindert diese unbeabsichtigten Datenlecks und schützt die Privatsphäre der Besucher. Selbst kleine Privatseiten profitieren stark von diesem Header.
Sammlerseite	⬆️⬆️	ℹ️ Sammlerseite – ⬆️⬆️ Pflicht ℹ️ Sammlerseiten enthalten oft viele externe Links, Bilder oder eingebettete Inhalte. Ohne Referrer‑Policy würden beim Laden externer Ressourcen vollständige URLs an Drittseiten übertragen, einschließlich Suchbegriffen, Kategorien oder internen Parametern. Das ermöglicht Tracking und Profiling durch externe Anbieter. Eine strikte Referrer‑Policy verhindert diese Datenabflüsse und schützt die Besucher vor unerwünschter Nachverfolgung.
Online-Shop	⬆️⬆️	ℹ️ Online-Shop – ⬆️⬆️ Pflicht ℹ️ Shops enthalten häufig sensible URL‑Parameter wie Produkt‑IDs, Warenkorb‑Informationen, Kampagnen‑Tags oder Session‑Fragmente. Ohne Referrer‑Policy können diese Daten an externe Dienste, Payment‑Provider oder Werbenetzwerke geleakt werden. Das gefährdet Datenschutz, Conversion‑Tracking und teilweise sogar Sicherheit. Eine strikte Referrer‑Policy ist daher für Shops unverzichtbar, um Kundendaten zu schützen und Datenabfluss zu verhindern.
Landingpage	⬆️⬆️	ℹ️ Landingpage – ⬆️⬆️ Pflicht ℹ️ Landingpages nutzen oft Tracking‑Parameter, Kampagnen‑IDs oder A/B‑Testing‑Varianten in der URL. Ohne Referrer‑Policy werden diese Informationen an externe Domains übertragen, sobald ein Besucher auf einen Link klickt oder externe Ressourcen geladen werden. Das führt zu ungewolltem Datenabfluss und kann Marketing‑Analysen verfälschen. Eine strikte Referrer‑Policy schützt Kampagnendaten und verhindert Leaks.
Blog	⬆️⬆️	ℹ️ Blog – ⬆️⬆️ Pflicht ℹ️ Blogs enthalten oft Kategorien, Suchbegriffe oder interne Strukturen in der URL. Ohne Referrer‑Policy werden diese Informationen an externe Seiten übertragen, wenn Besucher Links anklicken oder eingebettete Inhalte geladen werden. Das ermöglicht Tracking durch Drittanbieter und kann sensible Themen offenlegen. Eine strikte Referrer‑Policy schützt Leser und verhindert ungewollte Datenweitergabe.
Forum	⬆️⬆️	ℹ️ Forum – ⬆️⬆️ Pflicht ℹ️ Foren enthalten oft Benutzer‑IDs, Thread‑Titel, Suchbegriffe oder interne Parameter in der URL. Ohne Referrer‑Policy können diese Daten an externe Seiten geleakt werden, wenn Nutzer Links anklicken oder eingebettete Inhalte geladen werden. Das gefährdet die Privatsphäre der Mitglieder und ermöglicht Profiling. Eine strikte Referrer‑Policy ist daher für Foren besonders wichtig.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Web‑Apps enthalten häufig API‑Parameter, Token‑Fragmente, interne Routen oder sensible Daten in der URL. Ohne Referrer‑Policy können diese Informationen an externe Dienste oder eingebettete Ressourcen übertragen werden. Das stellt ein erhebliches Sicherheitsrisiko dar. Eine strikte Referrer‑Policy verhindert Datenlecks, schützt API‑Strukturen und ist ein zentraler Bestandteil moderner Web‑App‑Sicherheit.
Intranet	⬆️⬆️	ℹ️ Intranet – ⬆️⬆️ Pflicht ℹ️ Intranets enthalten vertrauliche Informationen, interne Strukturen, Dokument‑IDs oder personenbezogene Daten in der URL. Ohne Referrer‑Policy können diese Informationen an externe Seiten geleakt werden, wenn Mitarbeiter Links anklicken oder externe Ressourcen geladen werden. Das ist besonders gefährlich in Unternehmensumgebungen. Eine strikte Referrer‑Policy ist daher zwingend erforderlich, um interne Daten zu schützen.

🔴 Fehlt!

🔄 Mögliche Folgen:
• Browser senden vollständige URLs an externe Seiten.
• Risiko für Datenlecks über Query-Parameter.
• Datenschutzrisiken (DSGVO).

STRICT-TRANSPORT-SECURITY (HSTS)

Seitentyp	Relevanz	Grund
Privatseite	⬆️⬆️	ℹ️ Privatseite – ⬆️⬆️ Pflicht ℹ️ HSTS verhindert, dass Besucher versehentlich eine unverschlüsselte HTTP‑Version der Seite aufrufen. Selbst kleine Privatseiten sind anfällig für Downgrade‑Angriffe, z. B. in öffentlichen WLANs. Ohne HSTS kann ein Angreifer den ersten HTTP‑Request abfangen und manipulieren. Mit HSTS erzwingt der Browser dauerhaft HTTPS und schützt Besucher zuverlässig vor Man‑in‑the‑Middle‑Angriffen.
Sammlerseite	⬆️⬆️	ℹ️ Sammlerseite – ⬆️⬆️ Pflicht ℹ️ Sammlerseiten enthalten oft viele externe Ressourcen und werden häufig über Suchmaschinen oder Social‑Media‑Links aufgerufen. HSTS stellt sicher, dass alle Aufrufe verschlüsselt erfolgen und verhindert, dass Angreifer unverschlüsselte Verbindungen abfangen oder manipulieren. Da Sammlerseiten öffentlich zugänglich sind, ist HSTS ein zentraler Schutz gegen Downgrade‑Angriffe.
Online-Shop	⬆️⬆️	ℹ️ Online-Shop – ⬆️⬆️ Pflicht ℹ️ Shops verarbeiten personenbezogene Daten, Logins, Zahlungsinformationen und Bestellungen. Ohne HSTS können Angreifer unverschlüsselte HTTP‑Verbindungen abfangen und manipulieren, bevor der Browser auf HTTPS umschaltet. HSTS verhindert SSL‑Stripping und stellt sicher, dass Kunden immer verschlüsselt kommunizieren. Für Shops ist HSTS unverzichtbar und ein wesentlicher Bestandteil der PCI‑DSS‑Sicherheitsanforderungen.
Landingpage	⬆️⬆️	ℹ️ Landingpage – ⬆️⬆️ Pflicht ℹ️ Landingpages werden häufig über Werbekampagnen, Social‑Media‑Links oder QR‑Codes aufgerufen — oft in unsicheren Netzwerken. Ohne HSTS kann der erste HTTP‑Aufruf abgefangen und manipuliert werden. HSTS erzwingt HTTPS ab dem ersten Besuch und schützt Besucher vor Redirect‑Manipulationen, Tracking‑Injection oder Malware‑Einbettungen. Für Marketing‑Seiten ist HSTS daher Pflicht.
Blog	⬆️⬆️	ℹ️ Blog – ⬆️⬆️ Pflicht ℹ️ Blogs enthalten oft Kommentare, Nutzerkonten oder eingebettete Inhalte. Ohne HSTS können Angreifer unverschlüsselte Verbindungen abfangen und manipulieren, z. B. um Tracking‑Skripte oder schädliche Inhalte einzuschleusen. HSTS verhindert Downgrade‑Angriffe und stellt sicher, dass Leser und Autoren immer verschlüsselt kommunizieren. Für öffentliche Blogs ist HSTS daher zwingend erforderlich.
Forum	⬆️⬆️	ℹ️ Forum – ⬆️⬆️ Pflicht ℹ️ Foren enthalten Logins, private Nachrichten, Profilinformationen und nutzergenerierte Inhalte. Ohne HSTS können Angreifer unverschlüsselte HTTP‑Verbindungen abfangen und Session‑Cookies oder Logins stehlen. HSTS schützt vor SSL‑Stripping und erzwingt dauerhaft HTTPS. Für Foren ist HSTS ein zentraler Schutzmechanismus, um Nutzerkonten und interne Kommunikation zu sichern.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Web‑Apps kommunizieren intensiv mit APIs und verarbeiten sensible Daten. Ohne HSTS kann der erste HTTP‑Request abgefangen und manipuliert werden, bevor die App auf HTTPS umschaltet. Das gefährdet Tokens, Sessions und API‑Kommunikation. HSTS verhindert Downgrade‑Angriffe und stellt sicher, dass die App immer verschlüsselt geladen wird. Für SPAs und SaaS‑Plattformen ist HSTS unverzichtbar.
Intranet	⛔/⬆️	ℹ️ Intranet – ⛔ / ⬆️ (abhängig von der Infrastruktur) ℹ️ HSTS ist für Intranets nur dann sinnvoll, wenn alle internen Systeme gültige, vertrauenswürdige Zertifikate verwenden. In vielen Unternehmen existieren jedoch (veraltete) Legacy‑Systeme, interne Hosts ohne Zertifikate oder selbstsignierte Zertifikate. HSTS würde diese Systeme blockieren und könnte damit ganze Arbeitsabläufe lahmlegen. Wenn das Intranet jedoch vollständig über HTTPS mit gültigen Zertifikaten läuft, ist HSTS ein starker zusätzlicher Schutz gegen interne Man‑in‑the‑Middle‑Angriffe. Daher: Entweder Pflicht oder gefährlich, je nach Infrastruktur.

🔴 Fehlt!

🔄 Mögliche Folgen:
• Ohne HSTS kann ein Angreifer HTTPS‑Downgrade‑Angriffe durchführen.
• Browser können auf HTTP zurückfallen.
• Stark erhöhtes Risiko für Man‑in‑the‑Middle‑Angriffe.
• Cookies können unverschlüsselt übertragen werden.

X-CONTENT-TYPE-OPTIONS

Seitentyp	Relevanz	Grund
Privatseite	⬆️⬆️	ℹ️ Privatseite – ⬆️⬆️ Pflicht ℹ️ Ohne diesen Header kann der Browser versuchen, den Inhaltstyp einer Datei zu erraten. Das ermöglicht Angriffe, bei denen harmlose Dateien wie Bilder oder Textdateien als ausführbares Skript interpretiert werden. Selbst kleine Privatseiten können dadurch kompromittiert werden, etwa wenn ein Angreifer manipulierte Dateien einschleust. Der Header verhindert MIME‑Sniffing zuverlässig und schützt Besucher vor unerwarteter Skriptausführung.
Sammlerseite	⬆️⬆️	ℹ️ Sammlerseite – ⬆️⬆️ Pflicht ℹ️ Sammlerseiten binden häufig viele externe Medien ein. Ohne X‑Content‑Type‑Options kann der Browser versuchen, den MIME‑Typ dieser Ressourcen zu erraten, was Angriffe über manipulierte Bilder, PDFs oder andere Dateien ermöglicht. Der Header erzwingt, dass Dateien nur entsprechend ihres deklarierten Typs verarbeitet werden. Das schützt Besucher vor XSS‑Angriffen über externe Ressourcen.
Online-Shop	⬆️⬆️	ℹ️ Online-Shop – ⬆️⬆️ Pflicht ℹ️ Shops verarbeiten sensible Daten und nutzen zahlreiche Skripte, Stylesheets und Medien. Ohne diesen Header könnten manipulierte Dateien als JavaScript interpretiert werden, was Angreifern ermöglicht, Zahlungsdaten oder Sessions zu stehlen. X‑Content‑Type‑Options verhindert MIME‑Sniffing und stellt sicher, dass nur korrekt deklarierte Ressourcen ausgeführt werden. Für Shops ist dieser Header ein unverzichtbarer Sicherheitsbaustein.
Landingpage	⬆️⬆️	ℹ️ Landingpage – ⬆️⬆️ Pflicht ℹ️ Landingpages nutzen oft externe Tracking‑Skripte, Fonts oder Medien. Ohne den Header kann der Browser versuchen, den Inhaltstyp dieser Ressourcen zu erraten, was Angriffe über manipulierte Dateien ermöglicht. X‑Content‑Type‑Options verhindert, dass externe Inhalte als Skript ausgeführt werden, und schützt so vor Drive‑By‑Exploits und XSS‑Angriffen. Für Marketing‑Seiten ist dieser Schutz essenziell.
Blog	⬆️⬆️	ℹ️ Blog – ⬆️⬆️ Pflicht ℹ️ Blogs enthalten häufig nutzergenerierte Inhalte, eingebettete Medien und externe Ressourcen. Ohne den Header kann der Browser MIME‑Sniffing betreiben und Dateien falsch interpretieren, was XSS‑Angriffe über manipulierte Bilder, PDFs oder Uploads ermöglicht. X‑Content‑Type‑Options verhindert diese Fehlinterpretationen und schützt Leser und Autoren vor unerwarteter Skriptausführung.
Forum	⬆️⬆️	ℹ️ Forum – ⬆️⬆️ Pflicht ℹ️ Foren sind besonders anfällig für Angriffe über Dateiuploads oder eingebettete Medien. Ohne den Header kann der Browser versuchen, den MIME‑Typ hochgeladener Dateien zu erraten, was Angreifern ermöglicht, Schadcode in harmlos wirkenden Dateien zu verstecken. X‑Content‑Type‑Options verhindert MIME‑Sniffing und schützt Nutzer vor XSS‑Angriffen über manipulierte Uploads oder externe Ressourcen.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Pflicht ℹ️ Web‑Apps laden dynamisch Skripte, Module und API‑Antworten. Ohne den Header kann der Browser MIME‑Sniffing betreiben und Dateien falsch interpretieren, was die App‑Logik gefährdet und Angriffe über manipulierte Ressourcen ermöglicht. X‑Content‑Type‑Options stellt sicher, dass nur korrekt deklarierte Skripte ausgeführt werden und schützt die App vor XSS‑ und Supply‑Chain‑Angriffen. Für SPAs ist dieser Header unverzichtbar.
Intranet	⬆️⬆️	ℹ️ Intranet – ⬆️⬆️ Pflicht ℹ️ Intranets enthalten oft interne Tools, Dateiuploads und sensible Dokumente. Ohne den Header kann der Browser interne Dateien falsch interpretieren und Schadcode ausführen, der sich innerhalb des Netzwerks ausbreitet. X‑Content‑Type‑Options verhindert MIME‑Sniffing und schützt interne Anwendungen vor Angriffen über manipulierte Dateien oder kompromittierte Uploads. Für Unternehmensumgebungen ist dieser Header zwingend erforderlich.

🔴 Fehlt!

🔄 Mögliche Folgen:
• Browser können MIME‑Sniffing durchführen.
• Angreifer können Dateien als andere Dateitypen tarnen.
• Risiko für Cross-Site-Scripting (XSS) über manipulierte Dateien.

X-FRAME-OPTIONS

Seitentyp	Relevanz	Grund
Privatseite	⬆️⬆️	ℹ️ Privatseite – ⬆️⬆️ Pflicht ℹ️ X‑Frame‑Options verhindert, dass die Seite in fremden iFrames angezeigt wird. Ohne diesen Schutz können Angreifer die Seite in ein unsichtbares Overlay einbetten und Besucher dazu bringen, ungewollte Aktionen auszuführen (Clickjacking). Auch kleine Privatseiten sind davon betroffen, da Angreifer keine spezifischen Ziele benötigen. Der Header schützt zuverlässig vor UI‑Manipulationen und ist daher Pflicht.
Sammlerseite	⬆️⬆️	ℹ️ Sammlerseite – ⬆️⬆️ Pflicht ℹ️ Sammlerseiten enthalten oft viele externe Links und Medien. Ohne X‑Frame‑Options können Angreifer die Seite in ein manipuliertes Frame‑Layout einbetten und Besucher zu Klicks verleiten, die sie nicht beabsichtigen. Das kann zu Phishing, Malware‑Downloads oder unerwünschten Weiterleitungen führen. Da Sammlerseiten keine legitime Einbettung benötigen, ist der Header hier zwingend erforderlich.
Online-Shop	⬆️	ℹ️ Online‑Shop – ⬆️ Empfohlen (aber mit Vorsicht) ℹ️ Shops sind ein klassisches Ziel für Clickjacking‑Angriffe, bei denen Angreifer Kauf‑ oder Login‑Buttons überlagern. X‑Frame‑Options schützt zuverlässig davor. Gleichzeitig nutzen manche Payment‑Provider oder externe Dienste iFrames für Checkout‑Prozesse. Daher muss der Header sorgfältig konfiguriert werden, um legitime Einbettungen nicht zu blockieren. Für Shops ist er wichtig, aber erfordert eine abgestimmte Implementierung.
Landingpage	⬆️⬆️	ℹ️ Landingpage – ⬆️⬆️ Pflicht ℹ️ Landingpages werden häufig für Marketing‑Kampagnen genutzt und sind ein beliebtes Ziel für Clickjacking‑Angriffe, die Besucher zu unerwünschten Aktionen verleiten. Da Landingpages keine legitime Einbettung in fremde Frames benötigen, schützt X‑Frame‑Options zuverlässig vor Missbrauch durch Drittseiten, Werbenetzwerke oder manipulierte Weiterleitungen. Für Marketing‑Seiten ist der Header daher Pflicht.
Blog	⬆️⬆️	ℹ️ Blog – ⬆️⬆️ Pflicht ℹ️ Blogs enthalten oft Kommentare, externe Widgets und eingebettete Inhalte. Ohne X‑Frame‑Options können Angreifer die Seite in ein manipuliertes Frame‑Layout einbetten und Leser zu ungewollten Klicks verleiten. Das ist besonders gefährlich bei Login‑Bereichen oder Admin‑Panels. Da Blogs keine legitime Einbettung benötigen, ist der Header ein wichtiger Schutz gegen Clickjacking.
Forum	⬆️⬆️	ℹ️ Forum – ⬆️⬆️ Pflicht ℹ️ Foren enthalten Logins, private Nachrichten und nutzergenerierte Inhalte — ideale Ziele für Clickjacking‑Angriffe. Ohne X‑Frame‑Options können Angreifer die Seite in ein unsichtbares Frame einbetten und Nutzeraktionen manipulieren. Da Foren keine legitime Einbettung in fremde Frames benötigen, ist der Header ein zentraler Schutzmechanismus und sollte immer aktiviert sein.
Web‑App / SaaS / Single‑Page‑App	⛔	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⛔ Schädlich ℹ️ Moderne Web‑Apps nutzen häufig iFrames für OAuth‑Flows, externe Widgets, Payment‑Integrationen oder interne Komponenten. X‑Frame‑Options blockiert diese Einbettungen vollständig und kann die App funktionsunfähig machen. Für SPAs und SaaS‑Plattformen ist der Header daher ungeeignet. Stattdessen sollten moderne Alternativen wie Frame‑Ancestors in der CSP verwendet werden, die granularer steuerbar sind.
Intranet	⬆️⬆️	ℹ️ Intranet – ⬆️⬆️ Pflicht ℹ️ Intranets enthalten sensible interne Daten, Admin‑Oberflächen und interne Tools. Ohne X‑Frame‑Options können Angreifer über manipulierte interne Links oder kompromittierte Geräte Clickjacking‑Angriffe durchführen. Da Intranets selten legitime Frame‑Einbettungen benötigen, schützt der Header zuverlässig vor UI‑Manipulationen und ist ein wichtiger Bestandteil der internen Sicherheit.

🟢 Vorhanden

🛠️ Werte:
SAMEORIGIN

🧠 Erläuterung:
Schutz vor Clickjacking durch Verhinderung des Einbettens der Seite in Iframes.
- Deny: Restriktivste Einstellung, erlaubt das Einbetten in Iframes auch auf der eigenen Seite nicht.
- Sameorigin: Erlaubt das Einbetten in Iframes auf der eigenen Seite.
- Allow-From [URI]: Veraltet; früher zur Erlaubnis spezifischer Ursprünge genutzt.

💡 Tipp:
Die Aufgabe des Headers X-FRAME-OPTIONS kann mittels des Werts frame-ancestors ('none', 'self', URL1 URL2 ...) in den Header CONTENT-SECURITY-POLICY (CSP) verlagert werden. Die Verwendung dieses Headers wird dringend empfohlen (siehe oben).

🔴 Header CONTENT-SECURITY-POLICY (CSP) wird nicht gesendet.

X-XSS-PROTECTION

Seitentyp	Relevanz	Grund
Privatseite	⛔	ℹ️ Privatseite – ⛔ Überflüssig bis schädlich ℹ️ Der Header wird von modernen Browsern ignoriert und kann in Safari legitime Inhalte blockieren. Für Privatseiten bringt er keinen Sicherheitsvorteil und kann sogar Fehlverhalten verursachen. Stattdessen sollte eine moderne Content‑Security‑Policy genutzt werden.
Sammlerseite	⛔	ℹ️ Sammlerseite – ⛔ Überflüssig bis schädlich ℹ️ Sammlerseiten binden häufig externe Medien ein. X‑XSS‑Protection kann in Safari harmlose Inhalte blockieren oder Fehlalarme auslösen. Da der Header in modernen Browsern keine Wirkung mehr hat, erzeugt er nur unnötige Risiken und sollte entfernt werden.
Online-Shop	⛔	ℹ️ Online-Shop – ⛔ Überflüssig bis gefährlich ℹ️ Shops benötigen zuverlässige Sicherheitsmechanismen. X‑XSS‑Protection ist veraltet und kann in Safari legitime Skripte blockieren, was Checkout‑Prozesse oder Tracking‑Mechanismen stören kann. Da der Header keine echte XSS‑Sicherheit bietet, ist er für Shops ungeeignet und sollte durch CSP ersetzt werden.
Landingpage	⛔	ℹ️ Landingpage – ⛔ Überflüssig ℹ️ Landingpages nutzen häufig externe Skripte und Tracking‑Tools. X‑XSS‑Protection wird von modernen Browsern ignoriert und kann in Safari zu unerwarteten Blockaden führen. Der Header bietet keinen Schutz und sollte nicht verwendet werden.
Blog	⛔	ℹ️ Blog – ⛔ Überflüssig ℹ️ Blogs enthalten oft eingebettete Medien und externe Widgets. X‑XSS‑Protection kann in Safari legitime Inhalte blockieren und erzeugt Fehlverhalten, ohne irgendeinen Sicherheitsvorteil zu bieten. Moderne Blogs sollten ausschließlich auf CSP setzen.
Forum	⛔	ℹ️ Forum – ⛔ Überflüssig bis schädlich ℹ️ Foren sind anfällig für XSS, aber X‑XSS‑Protection bietet keinen Schutz mehr. In Safari kann der Header sogar harmlose Beiträge blockieren oder die Darstellung stören. Da moderne Browser den Header ignorieren, ist er für Foren ungeeignet und sollte entfernt werden.
Web‑App / SaaS / Single‑Page‑App	⛔	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⛔ Überflüssig bis schädlich ℹ️ Moderne Web‑Apps nutzen dynamische Skripte, Module und Frameworks. X‑XSS‑Protection kann in Safari legitime App‑Funktionen blockieren und Debugging erschweren. Da der Header in modernen Browsern keine Wirkung mehr hat, ist er für Web‑Apps kontraproduktiv und sollte entfernt werden.
Intranet	⛔	ℹ️ Intranet – ⛔ Überflüssig ℹ️ Intranets nutzen oft Legacy‑Systeme und interne Tools. X‑XSS‑Protection kann in Safari legitime Inhalte blockieren und Fehlverhalten verursachen. Da der Header keine echte Sicherheitswirkung mehr hat, sollte er auch in internen Umgebungen vollständig entfernt werden.

💀 Vorhanden

🛠️ Werte:
0

🧠 Erläuterung:
Der Header X-XSS-Protection stammt aus alten Internet-Explorer-Versionen und wird von modernen Browsern vollständig ignoriert. In einigen Fällen kann er sogar neue XSS-Schwachstellen erzeugen, da der veraltete Filter HTML-Inhalte verändert und damit Angriffsflächen schafft.

🚨 Kritische Warnung:
Dieser Header ist veraltet und potenziell gefährlich. Er bietet keinen Schutz und kann in Legacy-Browsern unsicheres Verhalten auslösen. Dies gilt insbesondere für den Wert 1; mode=block

Mögliche Folgen:
• Aktivierung eines unsicheren Legacy-XSS-Filters in alten Browsern.
• Risiko für neue XSS-Schwachstellen durch HTML-Manipulation.
• Moderne Browser ignorieren den Header vollständig (Scheinsicherheit).
• Entwickler wiegen sich in falscher Sicherheit, obwohl kein Schutz besteht.

💡 Tipp:
Entfernen Sie diesen Header vollständig. Nutzen Sie stattdessen eine starke Content-Security-Policy (CSP), um XSS zuverlässig zu verhindern.
Sollten Sie diesen Header verwenden, weil Ihre Logfunktionen User zeigen, die laut User Agent den Internet Explorer verwenden: Dabei handelt es sich zu 99,999% um Bots. Sie können den Header also bedenklos entfernen.

SERVER

Seitentyp	Relevanz	Grund
Privatseite	⛔	ℹ️ Privatseite – ⛔ Überflüssig ℹ️ Der SERVER‑Header verrät unnötig, welche Software und Version die Seite nutzt. Für Privatseiten bietet das keinerlei Vorteil, erhöht aber die Angriffsfläche, da Angreifer gezielt nach Schwachstellen dieser Version suchen können. Der Header sollte entfernt oder anonymisiert werden.
Sammlerseite	⛔	ℹ️ Sammlerseite – ⛔ Überflüssig ℹ️ Sammlerseiten benötigen keine Offenlegung der Server‑Software. Der Header erleichtert Angreifern das Fingerprinting und ermöglicht gezielte Exploit‑Suche. Da er keinerlei funktionalen Nutzen bietet, sollte er vollständig entfernt werden.
Online-Shop	⛔	ℹ️ Online-Shop – ⛔ Überflüssig bis schädlich ℹ️ Shops sind ein attraktives Ziel für Angreifer. Der SERVER‑Header verrät exakte Software‑Versionen und erleichtert gezielte Angriffe auf bekannte Schwachstellen. Da der Header keinen Vorteil für den Shopbetrieb bietet, sollte er aus Sicherheitsgründen entfernt oder anonymisiert werden.
Landingpage	⛔	ℹ️ Landingpage – ⛔ Überflüssig ℹ️ Landingpages benötigen keine Offenlegung der Server‑Software. Der Header bietet keinerlei funktionalen Mehrwert, erhöht aber die Angriffsfläche durch unnötige Informationen über die Infrastruktur. Er sollte entfernt werden, um Fingerprinting zu vermeiden.
Blog	⛔	ℹ️ Blog – ⛔ Überflüssig ℹ️ Blogs nutzen oft Standard‑Hosting oder CMS‑Systeme. Der SERVER‑Header verrät zusätzliche Details über die Infrastruktur und erleichtert Angreifern die Suche nach passenden Exploits. Da der Header keinen Nutzen hat, sollte er entfernt oder anonymisiert werden.
Forum	⛔	ℹ️ Forum – ⛔ Überflüssig ℹ️ Foren sind anfällig für Angriffe auf Login‑ und Session‑Mechanismen. Der SERVER‑Header verrät exakte Software‑Versionen und erleichtert gezielte Angriffe. Da er keinerlei funktionalen Nutzen bietet, sollte er vollständig entfernt werden.
Web‑App / SaaS / Single‑Page‑App	⛔	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⛔ Überflüssig bis gefährlich ℹ️ Moderne Web‑Apps nutzen komplexe Infrastrukturen, Load‑Balancer und Microservices. Der SERVER‑Header verrät unnötige Details über die Plattform und kann Angreifern helfen, spezifische Schwachstellen zu identifizieren. Da der Header keinerlei Vorteil bietet, sollte er entfernt oder durch neutrale Werte ersetzt werden.
Intranet	⛔	ℹ️ Intranet – ⛔ Überflüssig bis gefährlich ℹ️ Auch in internen Netzwerken ist der SERVER‑Header unnötig. Er verrät Details über interne Systeme, die bei kompromittierten Geräten oder Insider‑Angriffen ausgenutzt werden können. Da der Header keinen funktionalen Nutzen hat, sollte er auch im Intranet entfernt werden.

🟢 Vorhanden

🛠️ Werte:
gws

🟢 Der Header enthält einen benutzerdefinierten Wert, der keinen Rückschluss auf die Technik zulässt. Diese "Security durch Obscurity" ist eine sinnvolle Härtungsmaßnahme, um automatisierte Scans ins Leere laufen zu lassen. ✔️

Ende Sicherheitsheader (12 Header überprüft - Anzahl kann variieren)

Performancebezogene HTTP-Header - google.com - 15.08.2026 01:27:02

  ⚠️ Bitte beachten: Die Legende zu den performancebezogenen HTTP-Headern weicht teilweise von der Legende der sicherheitsbezogenen HTTP-Headern ab!
  Legende: 🔴 = Fehlt - 🟢 = Vorhandensein OK - ☯ = Kontextabhängig - 🟡 = Veraltet / fehlkonfiguriert - ℹ️ Seitentyp Info

  Expires-Header-Inhalt: -1

HTTP/3

🟢 Vorhanden

🛠️ Werte:
h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

🧠 Erläuterung:
HTTP/3 ist die dritte, moderne Hauptversion des Hypertext Transfer Protocol (HTTP), die das Internet durch die Nutzung des QUIC-Protokolls (über UDP statt TCP) schneller, sicherer und zuverlässiger macht. Es behebt Latenzprobleme (Head-of-Line-Blocking) von HTTP/2, bietet integriertes TLS 1.3 und ist besonders für mobile Verbindungen optimiert.

VARY

Seitentyp	Relevanz	Grund
Privatseite	➡️	ℹ️ Privatseite – ➡️ Optional empfohlen ℹ️ Auch Privatseiten profitieren von schnelleren Ladezeiten durch Komprimierung (Gzip/Brotli). Ein einfacher 'Vary: Accept-Encoding' stellt sicher, dass moderne Browser die komprimierte und alte Browser die unkomprimierte Version aus dem Cache erhalten. Komplexe Werte sind hier meist überflüssig.
Sammlerseite	⬆️⬆️	ℹ️ Sammlerseite – ⬆️⬆️ Empfohlen ℹ️ Sammlerseiten liefern oft große Mengen an Bildern und Daten. Wenn der Server je nach Browser-Support moderne Formate wie WebP/AVIF über dieselbe URL ausliefert, ist 'Vary: Accept' vorteilhaft. Andernfalls könnten ältere Browser fälschlicherweise unlesbare Bilddaten aus dem Cache erhalten.
Online-Shop	➡️	ℹ️ Online-Shop – ➡️ Bedingt empfohlen ℹ️ Shops nutzen oft dynamische Inhalte wie Währungen, Warenkörbe oder Sprachen. Wird hier unsachgemäß gecacht, sieht ein Kunde eventuell den Warenkorb eines Fremden. Ein 'Vary: Cookie' schützt davor, hebelt aber häufig das CDN-Caching aus. Der Header muss hier extrem präzise konfiguriert sein.
Landingpage	⬆️⬆️	ℹ️ Landingpage – ⬆️⬆️ Empfohlen ℹ️ Landingpages müssen extrem schnell laden. Damit das CDN komprimierte Daten (Brotli/Gzip) sicher cachen und blitzschnell ausliefern kann, muss 'Vary: Accept-Encoding' gesetzt sein. Fehler führen dazu, dass das CDN wertlose unkomprimierte Daten ausliefert oder den Cache umgeht. Wer sich um seinen Google Lighthouse Score Sorgen macht, sollte Vary nutzen.
Blog	⬆️⬆️	ℹ️ Blog – ⬆️⬆️ Empfohlen ℹ️ Blogs nutzen häufig Caching-Plugins. Wenn der Blog für Mobilgeräte ein anderes Layout erzeugt als für Desktop-PCs (ohne Responsive Design), sollte 'Vary: User-Agent' genutzt werden. ALlerdings: Dies kann den Cache extrem aufblähen und den Server unter Last setzen.
Forum	⬆️⬆️	ℹ️ Forum – ⬆️⬆️ Empfohlen ℹ️ In Foren unterscheidet sich die Ansicht für eingeloggte Mitglieder im Normalfall stark von der für Gäste (z.B. Admin-Buttons, private Foren). Ohne exakte Vary-Steuerung bezüglich des Login-Status (oder 'Cache-Control: private') könnten Gäste gecachte Seiten von angemeldeten Nutzern sehen.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Empfohlen ℹ️ SaaS-Apps laden Daten dynamisch via API, oft basierend auf Headern wie 'Accept-Language' oder benutzerdefinierten Tokens. Fehlt das entsprechende 'Vary' in der API-Antwort, liefert der Proxy-Cache die falschen Sprach- oder Benutzerdaten aus. Ein fehlerhafter Vary-Header zerstört hier die App-Logik.
Intranet	⬆️⬆️	ℹ️ Intranet – ⬆️⬆️ Empfohlen ℹ️ Im Intranet greifen Mitarbeiter mit unterschiedlichsten Rechten auf dieselben URLs zu. Caching ist hier nicht ungefährlich. Der Vary-Header muss (falls überhaupt Caching erlaubt ist) penibelst gesteuert werden, damit keine sensiblen Gehalts- oder Projektdaten im Browser- oder Proxy-Cache des falschen Kollegen landen.

🟢 Vorhanden

🛠️ Werte:
Accept-Encoding

🧠 Erläuterung:
Der VARY-Header teilt Proxies und Caching-Servern (CDNs, Browsern) mit, welche HTTP-Header berücksichtigt werden müssen, um zu entscheiden, ob eine gespeicherte Version der Seite ausgeliefert werden darf. Ein Wert wie Vary: Accept-Encoding stellt sicher, dass komprimierte Inhalte (wie Brotli oder ZSTD) nicht versehentlich an alte Browser gesendet werden, die diese nicht unterstützen.

✅ Optimal (Best Practice):
Der Header ist für maximale Performance konfiguriert (Vary: Accept-Encoding).

₂

💡 Hinweis für dynamische Bereiche:
Achten Sie lediglich darauf, dass Seiten mit sensiblen Personendaten (z. B. Konto-Bereich oder Warenkorb) serverseitig via PHP mit Cache-Control: private, no-store versehen sind, damit diese nicht fälschlicherweise im Edge-Cache landen.

CACHE-CONTROL

Seitentyp	Relevanz	Grund
Privatseite	⬆️⬆️	ℹ️ Privatseite – ⬆️⬆️ Empfohlen ℹ️ Statische oder selten geänderte Inhalte von Privatseiten profitieren von moderate Caching-Zeiten (z. B. public, max-age=86400). Dies entlastet den Server und beschleunigt den Seitenaufruf für wiederkehrende Besucher spürbar.
Sammlerseite	⬆️⬆️	ℹ️ Sammlerseite – ⬆️⬆️ Empfohlen ℹ️ Da Bildinhalte, Kataloge und Dokumentationsseiten meist statisch sind, eignet sich hier eine Kombination aus public, max-age=604800 für Medien und no-cache mit Revalidierung (ETag) für Katalogseiten, um bei Datenaktualisierungen sofort die neueste Version auszuliefern. ⚠️ Hinweis: Im Rahmen dieses Header-Audits konnte kein ETag-Header gefunden werden.
Online-Shop	⬆️⬆️	ℹ️ Online-Shop – ⬆️⬆️ Empfohlen bis notwendig ℹ️ Produktseiten können öffentlich gecacht werden (public, max-age=3600), solange Preise und Verfügbarkeiten aktuell bleiben. ⚠️ Hinweis: Warenkorb-, Checkout- und Kundenkonto-Seiten müssen zwingend mit no-store, private versehen werden, um das Zwischenspeichern sensibler Kundendaten auf Zwischenstationen (CDNs / Shared Proxies) zu verhindern.
Landingpage	⬆️⬆️	ℹ️ Landingpage – ⬆️⬆️ Empfohlen ℹ️ Landingpages sind im Normalfall auf maximale Ladezeit-Optimierung ausgelegt. Ein aggressiver Caching-Header (z. B. public, max-age=86400, stale-while-revalidate=3600) sorgt dafür, dass die Seite extrem schnell aus dem Browser-Cache oder Edge-CDN geladen wird und Absprungraten minimiert werden.
Blog	⬆️⬆️	ℹ️ Blog – ⬆️⬆️ Empfohlen ℹ️ Blogbeiträge ändern sich nach der Veröffentlichung selten. Hier wird public, max-age=43200 (12 Stunden) empfohlen. Bei aktivierter Kommentarfunktion sollte zusätzlich no-cache genutzt werden, damit neue Kommentare nach einer Server-Revalidierung sofort sichtbar sind. ⚠️ Hinweis: Im Rahmen dieses Header-Audits konnte kein ETag-Header gefunden werden.
Forum	⬆️⬆️	ℹ️ Forum – ⬆️⬆️ Empfohlen ℹ️ Da Inhalte durch neue Beiträge ständig dynamisch wachsen, sollte für Themenlisten und Threads no-cache (oder kurze max-age-Zeiten mit must-revalidate) genutzt werden. Dadurch prüft der Browser vor der Anzeige beim Server, ob neue Antworten vorliegen. ⚠️ Hinweis: Im Rahmen dieses Header-Audits konnte kein ETag-Header gefunden werden.
Web‑App / SaaS / Single‑Page‑App	⬆️⬆️	ℹ️ Web‑App / SaaS / Single‑Page‑App – ⬆️⬆️ Empfohlen ℹ️ Bei dynamischen Anwendungsdaten, Dashboards und API-Schnittstellen ist no-store, private Pflicht, damit persönliche Benutzerdaten nicht versehentlich gecacht werden. Eine HTML-Einstiegsdatei (index.html) sollte ebenfalls mit no-cache belegt werden, damit App-Updates sofort bei den Nutzern ankommen. ⚠️ Hinweis: Im Rahmen dieses Header-Audits konnte kein ETag-Header gefunden werden.
Intranet	⬆️⬆️	ℹ️ Intranet – ⬆️⬆️ Sicherheitsrelevant ℹ️ Vertrauliche Unternehmensdaten dürfen unter keinen Umständen in externen Zwischenspeichern landen. Hier ist ein strenges no-store, private zwingend erforderlich, damit nach dem Abmelden oder an geteilten Arbeitsplätzen keine sensiblen Seiten aus dem lokalen Cache wiederhergestellt werden können.

🟢 Vorhanden

🛠️ Werte:
private, max-age=0

🧠 Erläuterung:
Der Cache-Control-Header legt fest, ob, wo (im Browser oder auf CDNs/Shared-Proxies) und wie lange (in Sekunden) eine Antwort gespeichert werden darf. Er steuert zudem, ob veraltete Inhalte vor der erneuten Anzeige beim Server revalidiert werden müssen.

ℹ️ Cache‑Control‑Direktiven im Detail

no-store
Verbietet jegliches Speichern (weder im Browser noch auf Proxies / CDNs). Wird oft mit no-cache verwechselt. Wer wirklich kein Caching will, muss no-store nutzen.

no-cache
Erlaubt das Speichern, zwingt den Browser aber dazu, vor der Wiederverwendung beim Server nachzufragen (wozu ETag, mindestens aber Last-Modified benötigt wird). Der Wert meint also keineswegs "nicht speichern", sondern "vor Verwendung revalidieren".

public
Die Antwort darf von allen Zwischenspeichern (Browser, CDN, Varnish) gecacht werden - selbst wenn Auth-Header vorliegen, erlaubt public das Caching dennoch.

private
Darf nur im Endnutzer-Browser gecacht werden, nicht auf Shared-Caches (CDNs / Proxies). Standard für benutzerbezogene Daten, kann aber bei generischer PHPSESSID problematisch sein.

max-age=n
Gibt die maximale Lebensdauer im Cache in Sekunden an (relativ zum Abruf). Dieser Wert überschreibt den veralteten Expires-Header in modernen Browsern.

s-maxage=n
Wie max-age, gilt allerdings nur für Shared-Caches (CDNs, Reverse Proxies). Wird von normalen Browser-Caches ignoriert und übersteuert max-age auf Proxy-Ebene.

must-revalidate
Zwingt den Cache, abgelaufene Ressourcen unter keinen Umständen ohne Revalidierung zu nutzen (z.B. bei Netzwerkausfall). Wenn die Ressource noch nicht abgelaufen ist, bewirkt dieser Wert: genau nichts. Setzt zur sinnvollen Verwendung einen ETag-Header oder zumindest einen Last-Modified-Header voraus.

proxy-revalidate
Wie must-revalidate, gilt jedoch ausschließlich für Shared-Caches. Wird von privaten Browser-Caches ignoriert.

immutable
Signaliert, dass sich die Datei niemals ändert (z.B. ein feststehendes JavaScript). Der Browser fragt deshalb bei Reloads gar nicht erst nach. immutable verhindert unnötige 304 Not Modified-Revalidierungs-Requests bei F5.

stale-while-revalidate=n
Liefert kurzzeitig veralteten Cache-Inhalt sofort aus, während im Hintergrund die neue Version vom Server geladen wird. Performancesteigernd.

stale-if-error=n
Erlaubt die Auslieferung veralteter Daten, falls der Ursprungsserver einen 5xx-Fehler zurückgibt - insofern ein nützlicher Fallback für CDNs bei Serverausfällen.

post-check=0 & pre-check=0
Obwohl völlig veraltete Internet Explorer-Spezifika aus den 2000er Jahren finden sich diese Werte in Header-Checks noch erstaunlich häufig. Sie sind in modernen Web-Standards wirkungslos und können ersatzlos gestrichen werden, um den Header-Payload zu bereinigen. Zudem weisen diese Header auf Systeme hin, die schon relativ lang im Einsatz sind und sicherheitstechnisch möglicherweise evaluiert werden sollten.

⚠️ Hinweis:
Im Rahmen dieses Header-Audits konnte kein ETag-Header gefunden werden.

⚠️ Hinweis:
Im Rahmen dieses Header-Audits konnte kein Last-Modified-Header gefunden werden.

Ergebnis Dateizugriff - google.com - 15.08.2026 01:27:02

index.html (google.com)

<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="de"><head><meta content="text/html; charset=UTF-8" http-equiv="Content-Type"><meta content="/images/branding/googleg/1x/googleg_standard_color_128dp.png" itemprop="image"><title>Google</title><script nonce="_903W3RTNt13QxKMxU73Hg">(function(){var _g={kEI:'R6R_apXoCMeni-gP58bggAY',kEXPI:'0,4334963,201864,142932,5532800,846,158,5991270,30819294,5057639,20171042,152377,65174,138340,145454,41099,47848,3973,3705,42634,32561,16179,2646,24246,15888,4,1514,3355,12011,8,17406,5089,3027,16,779,32368,4255,5337,2892,1,1,8,14,28232,5,964,2,147,15171,19486,2,6335,14329,3,4991,10,13517,6293,23428,11427,1930,9282,1928,9,3,1024,10,7177,3933,21017371,4,2960,3,10055,3,17968,3,6512194,6,8232,68,5580,7024,3,996,571,3189,1514,149,3595752,13631607,1885665,1,105686,345805,5,1100566,1073,2,1246,3667,3584,7,7,7,16845,10,1237,1109,4895,5930,4388,5,15,3,1685,13832,178,5899,5555,5,5108,735,1527,484,4,4066,922,5,4032,4,6832,7936,3396,1864,821,4,571,5765,2462,3094,4,4585,911,4329,1505,6157,2864,6248,1327,4,4818,271,2466,2172,4,16524,8358,1199,4,1484,4498,1594,2235,4099,4573,4,26,278,57,5,6,1,688,5,58,4,3315,27,2210,5,382,6,794,161,1082,4,3626,5,265,1565,1,2603,1,689,221,5,1136,4445,5,1484,131,4,20,51,4525,281,374,4,167,2168,8,562,2352,1,2,1,1,5,14,1,2175,1,1568,5,304,1,2,335,2068,1186,890,1251,13,252,2553,968,6,4,131,4,480,4,1472,4,1379,4,2002,101,2,453,5,312,375,7483,4,3996,4,933,4,69,5,2618,3596,1637,1734,1145,5,1253,5,653,4,1124,4,2669,276,4,660,3024,5,3090,1,563,5,1293,5,329,11222,5,8,2315,1722,3522,1070,5,1472,539,4,735,4,1566,2060,746,4,225,1712,2,242,39,4,27,645,1375,4,70,2223,4,183,1804,4,913,4,1347,454,161,4,1409,3943,5,153,1149,774,5,58,2529,7,143,3259,873,704,413,1289,4,546,1,24,181,55,501,5,13,565,4,2,2,2,380,4,2,2,2,5,2,4,4215,10,1848,3,1398,4,2,328,4,1207,2,4,2,2,2,1479,2,1,1,1,2,402,521,4,2676,7,6,2380,2,953,5095,2,4,2,2,2,246,5,914,4,2,2,2,42,83,4,295,1641,479,1448,890,651,3279,1848,2420,277,4,2,496,4,512

(2000 Zeichen, gekürzt) 8e2a692ca86f1106206ef25e89c577cd2e5ce2b7c49cc1de6efb3d2468210a2e

• index.html: Kein Canonical-Tag gefunden (sollte korrigiert werden!).
• index.html: Charset UTF-8.

Robots.txt - google.com - 15.08.2026 01:27:02

User-agent: *
User-agent: Yandex
Disallow: /search
Allow: /search/about
Allow: /search/howsearchworks
Disallow: /sdch
Disallow: /groups
Disallow: /index.html?
Disallow: /?
Disallow: /goto?
Allow: /?hl=
Disallow: /?hl=*&
Allow: /?hl=*&gws_rd=ssl$
Disallow: /?hl=*&*&gws_rd=ssl
Allow: /?gws_rd=ssl$
Allow: /?pt1=true$
Disallow: /imgres
Disallow: /u/
Disallow: /setprefs
Disallow: /m?
Disallow: /m/
Allow:    /m/finance
Disallow: /wml?
Disallow: /wml/?
Disallow: /wml/search?
Disallow: /xhtml?
Disallow: /xhtml/?
Disallow: /xhtml/search?
Disallow: /xml?
Disallow: /imode?
Disallow: /imode/?
Disallow: /imode/search?
Disallow: /jsky?
Disallow: /jsky/?
Disallow: /jsky/search?
Disallow: /pda?
Disallow: /pda/?
Disallow: /pda/search?
Disallow: /local?
Disallow: /local_url
Disallow: /products?
Disallow: /product_
Disallow: /products_
Disallow: /products;
Disallow: /print
Disallow: /books/
Disallow: /bkshp?*dq=
Disallow: /bkshp?*q=
Disallow: /books?*dq=
Disallow: /books?*q=
Disallow: /books?*qtid=
Disallow: /books?*output=
Disallow: /books?*pg=
Disallow: /books?*jtp=
Disallow: /books?*jscmd=
Disallow: /books?*buy=
Disallow: /books?*zoom=
Allow: /books/about
Allow: /books?*zoom=1
Allow: /books?*zoom=5
Allow: /books/content?*zoom=1
Allow: /books/content?*zoom=5
Disallow: /patents?
Disallow: /patents/download/
Disallow: /patents/pdf/
Disallow: /patents/related/
Disallow: /scholar
Disallow: /citations?
Allow: /citations?user=
Allow: /citations?view_op=new_profile
Allow: /citations?view_op=top_venues
Allow: /scholar_share
Disallow: /s?
Disallow: /maps?
Allow: /maps?daddr=
Allow: /maps?entry=wc
Allow: /maps?f=
Allow: /maps?hl=
Allow: /maps?q=
Allow: /maps?saddr=
Allow: /maps?sid=
Allow: /maps?*output=classic
Allow: /maps?*file=
Disallow: /mapslt?
Disallow: /maphp?
Disallow: /maps/
Allow: /maps/$
Allow: /maps/@
Allow: /maps/?daddr=
Allow: /maps/?entry=wc
Allow: /maps/?f=
Allow: /maps/?hl=
Allow: /maps/?q=
Allow: /maps/?saddr=
Allow: /maps/?sid=
Allow: /maps/api/staticmap?
Allow: /maps/search/
Allow: /maps/sitemap.xml
Allow: /maps/sitemaps/
Allow: /maps/dir/
Allow: /maps/d/
Allow: /maps/reserve
Allow: /maps/about
Allow: /maps/contrib/
Allow: /maps/match
Allow: /maps/ms?
Allow: /maps/place/
Allow: /maps/_/
Allow: /search?*tbm=map
Allow: /maps/vt?
Allow: /maps/preview
Disallow: /maps/api/js/
Allow: /maps/api/js
Disallow: /mld?
Disallow: /staticmap?
Disallow: /help/maps/streetview/partners/welcome/
Disallow: /help/maps/indoormaps/partners/
Disallow: /lochp?
Disallow: /ie?
Disallow: /uds/
Disallow: /transit?
Disallow: /trends?
Disallow: /trends/music?
Disallow: /trends/hottrends?
Disallow: /trends/viz?
Disallow: /trends/embed.js?
Disallow: /trends/fetchComponent?
Disallow: /trends/beta
Disallow: /trends/topics
Disallow: /trends/explore?
Disallow: /trends/api
Disallow: /musica
Disallow: /musicl
Disallow: /musics
Disallow: /urchin_test/
Disallow: /movies?
Disallow: /wapsearch?
Disallow: /reviews/search?
Disallow: /cbk
Disallow: /profiles/me
Disallow: /s2/profiles/me
Allow: /s2/profiles
Allow: /s2/oz
Allow: /s2/photos
Allow: /s2/search/social
Allow: /s2/static
Disallow: /s2
Disallow: /transconsole/portal/
Disallow: /aclk
Disallow: /tbproxy/
Disallow: /support/forum/search?
Disallow: /reviews/polls/
Disallow: /hosted/images/
Disallow: /accounts/ClientLogin
Disallow: /accounts/ClientAuth
Disallow: /accounts/o8
Allow: /accounts/o8/id
Disallow: /quality_form?
Disallow: /labs/popgadget/search
Disallow: /compressiontest/
Disallow: /analytics/feeds/
Disallow: /analytics/partners/comments/
Disallow: /analytics/portal/
Disallow: /analytics/uploads/
Allow: /alerts/manage
Allow: /alerts/remove
Disallow: /alerts/
Allow: /alerts/$
Disallow: /phone/compare/?
Disallow: /travel/clk
Disallow: /travel/lodging/clk
Disallow: /travel/entity
Disallow: /travel/search
Disallow: /travel/flights/booking
Disallow: /travel/flights/s/
Disallow: /travel/flights/search
Disallow: /travel/hotels/stories
Disallow: /travel/hotels/*/stories
Disallow: /travel/story
Disallow: /hotelfinder/rpc
Disallow: /hotels/rpc
Disallow: /evaluation/
Disallow: /forms/perks/
Disallow: /shopping/suppliers/search
Disallow: /edu/cs4hs/
Disallow: /trustedstores/s/
Disallow: /trustedstores/tm2
Disallow: /trustedstores/verify
Disallow: /shopping?
Disallow: /shopping/product/
Disallow: /shopping/seller
Disallow: /shopping/ratings/account/metrics
Disallow: /shopping/ratings/merchant/immersivedetails
Disallow: /shopping/reviewer
Disallow: /shopping/search
Disallow: /shopping/deals
Allow: /shopping?udm=28$
Disallow: /storefront
Disallow: /storepicker
Disallow: /about/careers/applications/candidate-prep
Disallow: /about/careers/applications/connect-with-a-googler
Disallow: /about/careers/applications/jobs/results?page=
Disallow: /about/careers/applications/jobs/results/?page=
Disallow: /about/careers/applications/jobs/results?*&page=
Disallow: /about/careers/applications/jobs/results/?*&page=
Disallow: /landing/signout.html
Disallow: /gallery/
Disallow: /landing/now/ontap/
Allow: /maps/reserve
Allow: /maps/reserve/partners
Disallow: /maps/reserve/api/
Disallow: /maps/reserve/search
Disallow: /maps/reserve/bookings
Disallow: /maps/reserve/settings
Disallow: /maps/reserve/manage
Disallow: /maps/reserve/payment
Disallow: /maps/reserve/receipt
Disallow: /maps/reserve/sellersignup
Disallow: /maps/reserve/feedback
Disallow: /maps/reserve/terms
Disallow: /maps/reserve/m/
Disallow: /maps/reserve/b/
Disallow: /maps/reserve/partner-dashboard
Disallow: /local/cars
Disallow: /local/dealership/
Disallow: /local/dining/
Disallow: /local/place/products/
Disallow: /local/place/reviews/
Disallow: /local/place/rap/
Disallow: /local/tab/
Disallow: /localservices/
Allow: /localservices/coupon/
Disallow: /nonprofits/account/
Disallow: /uviewer
Disallow: /landing/cmsnext-root/

# AdsBot
User-agent: AdsBot-Google
Disallow: /maps/api/js/
Allow: /maps/api/js
Disallow: /maps/api/place/js/
Disallow: /maps/api/staticmap
Disallow: /maps/api/streetview

# New user agent groups must also have a user agent reference in the global (*)
# group. See "Order of precedence" section in
# https://goo.gle/rep#order-of-precedence-for-user-agents
User-agent: Yandex
Disallow: /about/careers/applications/jobs/results
Disallow: /about/careers/applications-a/jobs/results

# Crawlers of certain social media sites are allowed to access page markup when
# google.com/imgres* links are shared. To learn more, please contact
# images-robots-allowlist@google.com.
User-agent: facebookexternalhit
User-agent: Twitterbot
Allow: /imgres
Allow: /search
Disallow: /groups
Disallow: /hosted/images/
Disallow: /m/

Sitemap: https://www.google.com/sitemap.xml

⚠️ Mindestens 12080 unzulässige Zeichen erkannt.

Einschätzung: Kritisch - beschädigt!

🧨 Die ausgelieferte Datei ist beschädigt oder enthält ungültige Zeichen oder eine ungültige Regelstruktur, so dass das ScrapTrap HTTP-Header Audit-Tool den Inhalt nicht als gültigen Text interpretieren konnte.
Dies könnte auf einen Server-, Proxy- oder einen Fehler auf Anwendungsebene hindeuten.

Details

Die Datei enthält ungültige Byte‑Sequenzen oder
Encoding war nicht erkennbar, oder
der MIME‑Type ist falsch bzw. widersprüchlich.
Der Datei-Inhalt entspricht somit keinem gültigen robots.txt‑Format.

Konsequenz

Suchmaschinen können die Datei nicht lesen und entsprechend die vorgesehenen Regeln nicht befolgen.
Andere Crawler interpretieren die Datei als defekt.
Die Wepräsenz weist somit eventuell eine strukturelle Fehlkonfiguration auf.

Empfehlung

Überprüfen Sie die Datei auf dem Server, sofern Sie FTP-Zugriff haben oder in der Admin über einen Robots.txt-Editor verfügen.
Korrigieren Sie ggfs. das Encoding.
Sollte die Datei auf dem Server korrekt sein, sollten Sie auf eventuelle Proxy‑Ketten prüfen, da der ausgelieferte Inhalt hierbei beschädigt werden könnte.
Sollte die Datei auf dem Server tatsächlich beschädigt sein, ersetzen Sie dies durch eine neue robots.txt.

Einschätzung: Kritisch!

Verzeichnisse:

Parameter:

/bkshp?*dq=
/bkshp?*q=
/books?*dq=
/books?*q=

muss

Ganz im Gegenteil unterstützen Sie diese noch dabei!

💡 Empfehlung:

Geben Sie keinesfalls sensible Parameter an! Dies verrät Angreifern, welche GET-Parameter das Backend verarbeitet; diese Angaben können für SQL-Injections, Reflected XSS, Session‑Hijacking, Token‑Manipulationen, Debug‑Mode‑Abuse oder Parameter-Tampering verwendet werden.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.google.com/schemas/sitemap/0.84">
  <sitemap>
    <loc>https://www.google.com/gmail/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/forms/sitemaps.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/slides/sitemaps.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/sheets/sitemaps.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/drive/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/docs/sitemaps.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/get/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/travel/flights/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/admob/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/partners/about/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/adwords/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/adsense/start/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/chromebook/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/chrome/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/calendar/about/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/photos/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/nonprofits/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/finance/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/shopping/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/grants/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/maps/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/ads/publisher/sitemap.xml</loc>
  </sitemap>
</sitemapindex>