Tipps

HTTP Security Header

WordPress-Sicherheit mit HTTP-Security-Header erhöhen

HTTP-Security-Header erhöhen die Sicherheit und den Datenschutz Ihrer WordPress-Website, denn sie können den Schutz gegen Hackerangriffe dramatisch steigern. Leider ist ihr Einsatz unter WordPress-Installationen noch nicht sehr verbreitet. Das liegt zum einen daran, dass diese Sicherheitsmaßnahmen einiges an Fachwissen voraussetzten, zum anderen sind sie nicht sehr einfach umzusetzen. Mit diesem Beitrag helfen wir Ihnen, die Thematik zu verstehen und die Sicherheit Ihrer Website zu erhöhen.

Warum sind HTTP-Security-Header wichtig?

Ein Webbrowser versucht Ihnen nicht nur so einfach und schnell wie möglich Websites anzuzeigen, sondern diese auch denkbar sicher auszuliefern. Moderne Browser erledigen diesen Job auch grundsätzlich sehr gut, aber es gibt Bereiche, bei denen der Browser nicht allein entscheiden kann, was zu tun ist. So sind iframes an sich eine gute Sache, weil sie ermöglichen, Anwendungen anderer Websites in die eigene Internetpräsenz einzubinden. Diese Funktion wird aber auch gern missbraucht, um zum Beispiel Ihren Besuchern ein Formular anzuzeigen, das wertvolle Zugangsdaten auf einem fremden Server speichert. Stellen Sie sich dieses Szenario bei der Website Ihrer Bank vor!

Und hier kommen die ‘HTTP-Security-Header’ ins Spiel. Sie bieten Ihnen Einstellungsmöglichkeiten, um sicherheitsrelevante Entscheidungen für Ihre Website zu treffen, die Ihnen Ihr Browser nicht abnehmen kann. Technisch gesprochen bieten sie eine zusätzliche Sicherheitsebene, indem sie Verhaltensweisen einschränken, die der Browser und der Server sonst zulassen würden, sobald Ihre Website aufgerufen wird. Mithilfe der Website Webbkoll können Sie testen, wie es um die Sicherheit Ihrer Website steht.

Aber woher sollen Sie wissen, welche dieser Sicherheitseinstellungen wichtig sind und wo Sie sie vornehmen können? Dazu haben wir diesen Beitrag verfasst. Lesen Sie einfach weiter.

Hinweis: Bitte kopieren Sie nicht einfach die unten angegebenen Beispiele. Das kann zu großen Problemen auf Ihrer Website führen. Lesen Sie den Beitrag bis zum Ende und nehmen dann – Schritt für Schritt – Ihre eigenen Konfigurationen durch.

Was sind HTTP Security-Header?

Rufen Sie eine Website auf, sendet Ihr Browser eine Anfrage an den entsprechenden Webserver, um von diesem die nötigen Dateien und Daten für das Anzeigen der Website zu erhalten. Browser und Webserver tauschen auch gleich noch ein paar zusätzliche Informationen aus. Der Browser übermittelt beispielsweise Ihrem Server, von welchem Gerät, mit welchem Betriebssystem und Browser die Website aufgerufen wird. Die Website betreffenden Informationen sind im ‚HTTP-Header‘ zusammengefasst. Diese Header-Informationen dienen hauptsächlich der Abstimmung. Es wird sichergestellt, dass der Browser mit den vom Server gelieferten Daten etwas anfangen kann.

Die HTTP-Security-Header gehören zu dem HTTP-Header, um die sicherheitsrelevanten Details anzugeben. Einige HTTP-Header, die indirekt mit Datenschutz und Sicherheit zu tun haben, können ebenfalls den HTTP-Sicherheits-Header zugeordnet werden. Da mittlerweile alle gängigen Browser diese HTTP-Header unterstützen, können Sie durch die Verwendung geeigneter Header die Widerstandsfähigkeit Ihrer WordPress-Website gegen viele gängige Angriffe, wie Cross-Site-Scripting (XSS) und Clickjacking verbessern.

Die wichtigsten HTTP-Security-Header

Lassen Sie uns in eine Übersicht in die gängigsten sicherheitsrelevanten Header eintauchen. Das dient dazu, die jeweilige Funktionsweise und die mögliche Schutzfunktion zu verstehen. Die Reihenfolge ist frei gewählt.

HTTP Strict-Transport-Security (HSTS)

Diese Funktion erzwingt die Verwendung von verschlüsselten HTTPS-Verbindungen anstelle der unsicheren (und veralteten) HTTP-Kommunikation. Natürlich muss zunächst mittels SSL-Zertifikat dafür gesorgt werden, dass die Website verschlüsselt kommunizieren kann.

Ein typischer HSTS-Header könnte lauten:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • Strict-Transport-Security’ informiert den Browser, dass die Website nur über HTTPS aufgerufen werden kann.
  • max-age’ teilt dem Browser die Gültigkeit dieser Information in Sekunden mit (hier zwei Jahre).
  • includeSubDomains’ bezieht Subdomains mit ein, was auch weggelassen werden kann.
  • Optional ist auch der ‚preload‘-Befehl, der anzeigt, dass die Site in einer globalen Liste von “HTTPS-only-Sites” enthalten ist. Das Vorladen soll das Laden der Seiten beschleunigen und das Risiko von Man-in-the-Middle-Angriffen beim ersten Besuch einer Site eliminieren.

X-Frame-Options

Mit diesem Befehl können Sie verhindern, dass Ihre Inhalte in fremde Websites eingebettet werden. Der Aufruf Ihrer Website (oder Teile davon) auf Websites Dritter mit den Befehlen < frame >, <i. frame >, < embed > oder < object > werden unterbunden. So wehrt man Clickjacking-Attacken ab.

Es gibt drei Ausprägungen für diesen Befehl: ‚deny‘ unterbindet das Einbetten auf jeglichen Websites, ‚sameorigin‘ erlaubt die Integration auf der eigenen Website und ‚allow-from uri‘ ermöglicht das Einbinden auf der Website mit der Domain ‚uri‘.

X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: "allow-from https://example.com/"

Anmerkungen: Bei einigen Tests hatten wir bei der Einstellung ‚deny‘ Probleme mit den Updates von Plug-ins, die nicht mehr möglich waren. Wählen Sie in diesem Fall ‚sameorigin‘.

X-Content-Type-Options

Ein Medientyp (auch bekannt als Multipurpose Internet Mail Extensions oder MIME-Typ) ist ein Standard, der die Art und das Format einer Datei oder eines Dokuments angibt. Richtig verwendet, sorgt dieser Standard dafür, dass zum Beispiel ein Word-Dokument, das Sie über Ihre Website anbieten, direkt mit der entsprechenden Software geladen wird.

Da viele Daten nicht richtig deklariert sind, versuchen Browser durch “MIME-Sniffing” selbstständig herauszufinden, um welchen MIME-Typ es sich handelt, um eventuell das passende Programm zu laden oder die Daten im richtigen Format anzuzeigen. Die an sich gute Idee könnte allerdings von Hackern so ausgenutzt werden, dass sie schadhaften Programmcode durch eine mögliche Sicherheitslücke bei Ihnen auf den Server laden und tarnen (z. B: Javascript in Bildern), um damit die Rechner der Website-Besucher mit Schadcode zu infizieren.

Durch den Befehl nosniff werden die Browser daran gehindert, herauszufinden, welcher Dateityp sich hinter unbekannten Dateien verbirgt. So können sie nicht fälschlich ausgeführt oder heruntergeladen werden (Drive-by-Download-Attacken).

X-Content-Type-Options: nosniff

X-XSS-Protection

Hinweis: Der X-XSS-Protection-Header wird von modernen Browsern nicht mehr unterstützt. Das bedeutet, dass Sie, wenn Sie ältere Browser nicht unterstützen müssen, stattdessen Content-Security-Policy verwenden sollten, ohne unsafe-inline-Skripte zuzulassen. Das Problem: Der XSS-Schutz kann in einigen Fällen XSS-Schwachstellen in ansonsten sicheren Websites verursachen.

Der X-XSS-Protection-Header ist eine Funktion, die das Laden von Seiten verhindert, wenn sie “reflektierte” Cross-Site-Scripting-Angriffe erkennen. Bei diesem Angriffstyp wird JavaScript- oder HTML-Code an die URL angehängt und so an die Website übergeben, dass er an die Website-Besucher zurückgegeben – also “reflektiert” – wird. So ließen sich dann z.B. Links anhängen, die bösartiges JavaScript im Browser der Nutzer ausführen. Die übliche Syntax ist:

X-XSS-Protection: 1; mode=block

Obwohl diese Schutzmaßnahmen in modernen Browsern weitgehend unnötig sind, wenn Websites eine entsprechende Content-Security-Policy implementieren (siehe unten), die die Verwendung von Inline-JavaScript deaktiviert (‚unsafe-inline‘), können sie dennoch Schutz für Benutzer älterer Webbrowser bieten, die CSP noch nicht unterstützen.

Referrer-Policy

Über diesen HTTP-Security-Header lässt sich steuern, ob und in welchen Fällen der sog. Referrer-Wert bei ausgehenden Links übergeben werden soll. Die Referer-Informationen geben einer aufgerufenen Website an, von wo der Request ausgelöst wurde. Führt zum Beispiel ein Link Ihrer Website zu einem externen Ziel, so wird der Browser dieser Website Ihre Domain als Ursprung mitteilen, so ein Besucher auf den Link klickt.

Der Referrer lässt sich nicht direkt für Angriffe nutzen, ist aber für den Datenschutz interessant. Über den Wert ‚no-referrer‘ lässt sich eine Übertragung grundsätzlich unterdrücken, womit die Herkunft der Nutzer beim Verlassen Ihrer Website vertuscht wird.

Referrer-Policy: "no-referrer"

Weitere Einstellungsmöglichkeiten sind möglich. Sie finden Sie bei Bedarf hier.

Permissions-Policy

Der Permission Policy-Header (ehemals Feature-Policy) steuert, welche Browser-Funktionen verwendet werden können, die für die Sicherheit oder den Datenschutz Ihrer Besucher relevant sind. Zu diesen Funktionen gehören beispielsweise das Einschalten von Webcam oder Mikrofon, der Abruf des Standorts oder die Aktivierung der Zahlungs-API, die zum Beispiel von ApplePay genutzt wird. Neben der Implementierung dieser Regeln für Ihre eigenen Inhalte kann er auch verhindern, dass externe iframes diese Browser-Funktionen verwenden, was ihn zu einem leistungsstarken Header zur Sicherung Ihrer Website macht.

Über die Permissions-Policy kann man somit den Datenschutz Ihrer Website verbessern, indem Sie Angriffe verhindern, die es auf die Daten Ihrer Website-Besucher abgesehen haben. Als Beispiel kann eine Regel im Permissions-Policy-Header wie folgt angegeben werden:

Permissions-Policy: geolocation=(self "https://beispiel.de"), camera=(), fullscreen=*

Über den Befehl ‚self‘ geben Sie die jeweilige Funktion für die aktuelle Website frei. Geben Sie eine Domain an, gilt die Freigabe für eben diese. Ein Stern ‚*‘ erteilt allen Quellen die Freigabe und ein leerer Eintrag ‚()‘ deaktiviert die Funktion grundsätzlich. In dem oberen Beispiel wird also die folgende Richtlinie definiert: Die Geolocation-Berechtigung gilt für die eigene Website und die Domain ‘beispiel.de’. Der Kamerazugriff ist für alle Dokumente deaktiviert und der Vollbildmodus kann potenziell von jeder Quelle aufgerufen werden.

Die wichtigsten Befehle findem Sie im Folgenden. Eine ausführliche Anleitung der Permission-Policy gibt es bei Github.

Permissions-Policy: geolocation=(), midi=(), camera=(), usb=(), payment=(), vr=(), speaker=(), ambient-light-sensor=(), gyroscope=(), microphone=(), usb=(), interest-cohort=()

Update April 2021: Wir haben die Liste der Permission-Policy-Befehle um den Begriff interest-cohort=() ergänzt, der Googles FLoC auf Ihrer Website verhindert.

Content Security Policy (CSP)

Nun wir es kniffelig, denn die Einstellungen der CSP sind sehr komplex und müssen individuell für Ihre Website ausgewählt, konfiguriert und getestet werden. Lassen Sie im Zweifel diesen Bereich aus. Das ist nicht optimal, aber besser, als keinen oder falsch konfigurierten Schutz.

Sind Sie experimentierfreudig oder mutig (oder beides), dann können Sie mithilfe der CSP definieren, welche Ressourcen wie JavaScript, CSS — oder so ziemlich alles, was der Browser lädt — auf Ihrer Website erlaubt ist und von welcher Quelle sie stammen dürfen, damit sie als vertrauenswürdig gelten und somit ausgeführt werden. So können Sie die schon weiter oben beschriebenen Cross-Site-Scripting-Angriffe verhindern. Sollten Sie keine iframes auf Ihrer Websites nutzen und einen minimalen Schutz gegen diese XSS-Angriffe einrichten wollen, nutzen Sie die folgende (minimale) CSP-Richtlinie:

Header Set Content-Security-Policy: "frame-ancestors 'self'"

Die Herausforderung der Konfiguration von WordPress-Websites ist, dass Medien, Inhalte und Funktionen nicht selten von externen Servern geladen werden. Zum Beispiel werden nicht selten (trotz DSGVO) immer noch häufig Google Fonts von Google-Servern geladen. Diese externen Quellen müssen einzeln akkurat in die CSP übernommen werden, damit die Website weiterhin funktioniert und die höchstmögliche Sicherheit aufweist.

Ein tolles Werkzeug, das zum einen die Komplexität der CSP vermittelt, Sie zum anderen dabei unterstützt die CSP Ihrer Website zu entwickeln, finden Sie unter der Adresse CSP is Awesome.

Und noch ein Tool: Zwar unterstützen so ziemlich alle modernen Browser-Generationen die Content Security Policy, werten wir aber unsere Besucherdaten aus, finden wir immer noch ein recht reges Treiben von Besuchern auf unserer Website mit veralteten Browsern, wie den Internet Explorer von Microsoft. Möchten Sie testen, ob Ihr Webbrowser die CSP-Einstellungen unterstützt, nutzen Sie den CSP Browser Test.

So testen Sie Ihre HTTP-Security-Header-Einstellung

Bevor Sie sich in das Projekt stürzen, Ihre Website weiter abzusichern, sollten Sie zunächst überprüfen, ob auf Ihren Server nicht schon Sicherheitsrichtlinien durch Ihren Hoster eingestellt sind. Dazu bieten sich je nach Geschmack die Dienste von siwecos.de, securityheaders.com und observatory.mozilla.org an.

Natürlich ist es sehr zu empfehlen, dass Sie auch nach der Einrichtung eines HTTP-Security-Header diese Tests durchführen. Aber nicht nur das; Sie sollten auch unbedingt Ihre Website nach Darstellungsfehlern sichten und ausführliche Funktionstests durchführen. Werden zum Beispiel noch externe Schriften geladen, Sind die YouTube-Videos noch aufrufbar, Funktioniert Ihre Hauptnavigation noch, lassen sich Plug-ins noch updaten, um nur ein paar mögliche Fehler zu nennen.

Wo füge ich meinen HTTP-Security-Header in WordPress ein?

Grundsätzlich gibt es Möglichkeiten den HTTP-Security-Header bereits auf der Server-Ebene einzutragen. Auf diese Möglichkeiten gehen wir hier nicht ein. Wir erklären auch nicht, wie man die Sicherheits-Einstellungen direkt im HTML-Code als Meta-Tag definiert. Wir beschränken uns auf die gängigen Optionen in Verbindung mit der WordPress-Sicherheit.

WICHTIG: Bevor Sie die folgenden Dateien bearbeiten tun Sie sich einen Gefallen und legen zuvor Kopien der entsprechenden Dateien an und sichern am besten auch noch die Datenbank.

Und: Kopieren Sie nicht einfach die folgenden Beispiele, sie können funktionieren, müssen es aber nicht. Optimieren Sie die Einstellungen vielmehr Schritt für Schritt nach Ihren Bedürfnissen.

Einfügen der HTTP-Security-Header über die .htaccess-Datei

Wir empfehlen das Einfügen der Sicherheitsregeln über die .htaccess-Datei. Die .htaccess-Datei finden Sie im Hauptverzeichnis Ihrer WordPress-Installation. Sie wird automatisch von WordPress bei der Installation angelegt. Der Code, den Sie möglichst weit zu Beginn der Datei einfügen, könnte wie folgt aussehen:

<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=15768000; preload"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "no-referrer"
Header set Permissions-Policy "accelerometer=(), autoplay=(self), camera=(), encrypted-media=(), fullscreen, geolocation=(self), gyroscope=(), magnetometer=(), microphone=(), midi=(); payment=(), picture-in-picture=('self'), usb=()"
Header Set Content-Security-Policy: "frame-ancestors 'self'"
</IfModule>

Einbinden der HTTP-Security-Header über die functions.php

Falls Sie keinen Zugriff auf die .htaccess-Datei haben sollten, können Sie alternativ die HTTP-Security-Header auch über die functions.php (idealerweise in einem Child-Theme) eintragen. Dazu werden beispielhaft folgende Zeilen am Ende der Datei eingefügt:

/* HTTP-Security-Header */ 
if (!empty($_SERVER['HTTPS'])) {
function en_hsts_header($headers) {
$headers["Strict-Transport-Security"] = "max-age=15768000; preload";
$headers["X-Frame-Options"] = "SAMEORIGIN";
$headers["X-Content-Type-Options"] = "nosniff";
$headers["X-XSS-Protection"] = "1; mode=block";
$headers["Permissions-Policy"] = "accelerometer=(); autoplay=(self), camera=(), encrypted-media=(), fullscreen, geolocation=(self), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(self), usb=()";
$headers["Content-Security-Policy"] = "frame-ancestors 'self'";

return $headers;
}
add_filter('wp_headers', 'en_hsts_header');
}

Einbinden der HTTP-Security-Header über ein Plug-in

Wir vermeiden gerne Plugins und glauben, dass man bei der Konfiguration der Sicherheitseinstellung erfahren genug sein sollte, die Einstellung über die Dateien .htaccess oder wp-config.php direkt vorzunehmen, doch zur Vollständigkeit sei erwähnt, dass es ein Plug-in namens Headers Security Advanced & HSTS WP für das Einbinden der HTTP-Security-Header gibt, das sehr gute Bewertungen vorweisen kann.

Zusammenfassung

Mithilfe der HTTP-Security-Header können Sie die Sicherheit und den Datenschutz Ihrer Website verursacht durch Hackerangriffe dramatisch steigern. Wir haben versucht, das komplexe Thema der HTTP-Security-Header so verständlich wie möglich zu erklären, um es einem breiteren Publikum zu vermitteln. Das sollte aber nicht darüber hinwegtäuschen, dass es sich bei der Konfiguration um eine Aufgabe handelt, die eine gewisse Erfahrung und Verständnis für das Thema erfordert.

turned_in_notDSGVO, Hack/Datenklau

22 Kommentare. Wir freuen uns über Ihren Kommentar

  • Danke für diese Hilfestellung! Es ist richtig, dass ihr bei Plugins vorsichtig seid. Doch leider ist es meiner Erfahrung nach nicht praktikabel, ohne Plugin eine wirksame Content Security Policy einzuschalten. Denn WordPress ist voller inline Skripts, die man gemäss best practice mit sogenannten nonces einzeln freischalten muss. Das von euch verlinkte Plugin ist hier keine Hilfe. Dafür gibt es das Plugin no unsafe-inline.

    Antworten
  • Mohammed Alwalid
    1. März 2023 17:51

    Hallo,

    sind diese Header-Security Konfigurationen pflicht? oder Empfehlung?

    VG
    Alwalid

    Antworten
  • Samira Khatib
    10. November 2022 16:47

    Hallo Thorsten,

    toller, hilfreicher Artikel – Danke!
    Ich habe die .htaccess Datei angepasst und beim Check über securityheaders.com wurde alles plötzlich schön grün angezeigt, allerdings bei siwecos.de blieb es ROT, trotz Cache Leerung.
    Ich gehe mal davon aus, dass die Umsetzung trotzdem ok ist!?
    samy-design.de
    Oder muss ich noch etwas ändern?

    Viele Grüße,
    Samira

    Antworten
  • Roland Schmid
    28. September 2022 9:25

    Danke für die Anleitung, die ich als sehr hilfreich empfinde.
    Ich bitte um die Korrektur in den Codemustern:
    Für die htaccess:
    Falsch: Content-Security-Policy: “frame-ancestors ‘self'”
    Richtig: Header Set Content-Security-Policy: “frame-ancestors ‘self'”

    Für die functions.php fehlt am Ende der Zeile usb=()” ein Semikolon:
    Falsch: usb=()”
    Richtig: usb=()”;

    Viele Grüße

    Antworten
  • Hi, vielen Dank für den interessanten und lehrreichen Beitrag.
    Ich habe versucht die funtions.php entsprechend zu modifizieren – allerdings erhalte ich immer den Fehler:
    syntax error, unexpected variable “$headers”
    Habt ihr hier noch einen Tipp, wo es klemmt?

    Antworten
  • Hallo schöner Beitrag,
    aber ich möchte z.b. Iframe einbinden, oder Produkte von meiner anderen Seite in meiner Buddypress Community posten und bekomme die Meldung “wordpress.org hat die Verbindung abgelehnt.” das hat doch auch etwas mit den Header zu tun ? Hast du eine Lösung für mich?
    Vielen Dank
    Oliver

    Antworten
  • Hallo,
    erst Mal danke für den Beitrag. Ich hatte das Snippet für die .htaccess übernommen und nen Error 500 bekommen.

    In der letzten Zeile fehlt ein “Header set”.

    Header set Content-Security-Policy: “frame-ancestors ‘self'”

    Damit funktioniert’s bei mir und Securityheaders.com zeigt ein A+ an.

    Viele Grüße
    Klaus

    Antworten
  • leiter zerschiesst sich die WordPress- Seite. Egal ob über function.php oder htaccess. Somit kann das hier so nicht ganz stimmen.

    Antworten
  • Moin Thorsten,
    danke für den klasse Artikel! Dazu ein paar Fragen:

    1. Das WordPress Snippet nutzt den `wp_headers` filter. Andere nutzen die header() Funktion. Was ist nun richtiger? Ich habe 2 Stackoverflow posts gefunden, bin mir aber immer noch unsicher: https://wordpress.stackexchange.com/q/213988/213014 https://wordpress.stackexchange.com/q/20192/213014

    2. Der Siwecos Scan sagt mir, dass meine Seite 2 DOMXSS Lücken hat, aber nicht wo, weshalb und warum. Wie finde ich das heraus?

    3. In WordPress unter den allgemeinen Einstellungen gibt es eine Option “Force secure connections”, allerdings ist diese nirgendswo dokumentiert, auch der Link ist kaputt. Was hat es damit auf sich? Ich hätte vermutet, dass es HSTS oder so ist, aber das macht mein Webserver schon.

    Liebe Grüße
    Nico

    Antworten
  • Leider funktioniert alles bei mir nicht. Wenn ich meine Webseite vorher/nacher hier Teste https://securityheaders.com/ bleibt alles immer rot.

    Antworten
  • Sehr schöner Artikel. Werde damit mal meine Website checken und sicherer machen. Ihr zeigt aber im Absatz “Einbinden … über ein Plugin” auf ein Plugin, welches von wordpress.org mit dem 03.03.2021 wegen Richtlinienverletzung stillgelegt wurde und auch schon über 2 Jahre nicht mehr upgedatet wurde.

    Antworten
  • Ein klasse Artikel! Ich habe leider das Proble, dass bei meienr WordPress Seite weder die Funktion mit der htaccess-Datei, noch der functions.php oder dem Plugin funktioniert …

    Woran kann das liegen?

    Antworten
  • Torsten Landsiedel
    20. April 2021 20:26

    Sehr schöner Artikel! Aber leider zeigt er häufig die Nachteile nicht auf.

    HSTS-Header erzeugen zum Beispiel massiv Probleme, wenn ein Zertifikat versehentlich abläuft. Dann ist die Site nämlich gar nicht mehr erreichbar, da http ja explizit ausgeschlossen wird.

    X-Frame-Options verhindert auch das WordPress-eigene Embedding. Wer also diesen netten Effekt nutzt, sollte dafür eine Ausnahme bauen.

    Die Referrer-Policy sorgt bei no-referrer (wenn alle es einsetzen würden), dafür, dass die Statistiken der Besucher keine Quellen mehr zeigen. Klar, die Einstellung betrifft nur die anderen, aber wenn es alle machen würden …
    Sofern die URL keine sensitiven Daten enthält ist ein “no-referrer-when-downgrade” ausreichend, denn dann wird nur dann kein Referrer übertragen, wenn es zu einer nicht sicheren Site geht.

    Noch mehr Details und Testmöglichkeiten gibt es bei Scott Helme:
    https://scotthelme.co.uk

    Antworten

Wir freuen uns über Ihren Kommentar!

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Fill out this field
Fill out this field
Bitte geben Sie eine gültige E-Mail-Adresse ein.
You need to agree with the terms to proceed

expand_less
Elbnetz GmbH hat 4,96 von 5 Sternen 50 Bewertungen auf ProvenExpert.com