8 HTTP-Sicherheitsheader, die Sie verwenden müssen, um die Sicherheit zu verbessern
Veröffentlicht: 2022-04-08Der HTTP-Sicherheitsheader ist einer der grundlegendsten und dennoch leistungsfähigsten Teile der Websicherheit. Mit Hilfe dieser Sicherheitsmaßnahmen können Sie die Sicherheit Ihrer Webanwendung auf die nächste Stufe heben. Es verteidigt Ihre Website vor allen Angriffen, denen Ihre Website wahrscheinlich ausgesetzt sein wird.
Diese HTTP-Sicherheitsheader sind so leistungsfähig, dass sie, wenn Sie sie aktivieren, Ihre Website vor einigen gängigen Angriffen wie Clickjacking, Code-Injection, Cross-Site-Scripting und vielem mehr schützen.
In diesem Beitrag erklären wir Ihnen also alles über die Liste der HTTP-Sicherheitsheader, wie sie nützlich sein können und wie Sie sie implementieren können.
Bleiben Sie dran und fangen wir an!
Was ist ein HTTP-Sicherheitsheader?
Grundsätzlich ist ein HTTP-Sicherheitsheader eine Reihe von Befehlen oder Anweisungen, die zwischen Ihrem Webbrowser (oder einem beliebigen Webclient) und einem Webserver ausgetauscht werden, um die sicherheitsbezogenen Details der HTTP-Kommunikation anzugeben. Dieser Austausch oder die gemeinsame Nutzung von Informationen ist Teil des HTTP-Protokolls. Diese Befehle oder Anweisungen teilen Ihrem Browser mit, was für Ihre Website angezeigt werden darf oder was nicht, um deren Sicherheit und keine Malware-Injektion zu gewährleisten.
Diese HTTP-Sicherheits-Header-Befehle tragen dazu bei, sowohl den Webbrowser als auch Ihre Website vor Sicherheitsbedrohungen wie Hackerangriffen oder dem Einschleusen von bösartigem Code zu schützen. Diese Sicherheitsstrategie fungiert also als umfassendes Verteidigungssystem.
Warum müssen Sie den HTTP-Sicherheitsheader implementieren?
Wie Sie bereits bemerkt haben, kursieren im Internet zahlreiche Artikel und Berichte über den Spitzenanstieg von Cyberangriffen und Fällen von Datenschutzverletzungen in den letzten Jahren. Und einer der Hauptschuldigen für all diese Pannen sind schlechte Sicherheitsmaßnahmen und Fehlkonfigurationen.
Diese HTTP-Sicherheitsheader helfen, einige der häufigsten Hackerangriffe, Malware-Injektionen, Clickjacking, böswillige Scrip-Injektion usw. zu stoppen. Sie bieten eine zusätzliche Schutzebene, indem sie einige Aktivitäten zwischen dem Server und dem Webbrowser einschränken, während die Webanwendung dies tut Betrieb.
Obwohl viele HTTP-Header verfügbar sind, kommt es darauf an, welchen Sie implementieren sollten, um einen besseren Schutz zu erhalten. Wie bei jeder Webtechnologie, die sich im Laufe der Zeit ändert, werden je nach Unterstützung des Browsers neue HTTP-Header angezeigt und gelöscht.
Daher ist es wichtig, dass Sie entscheiden, welchen HTTP-Header Sie implementieren sollten und welchen nicht, aber vorerst müssen Sie diese 8 HTTP-Sicherheits-Header-Listen implementieren, damit Sie sich vor einigen der häufigsten Bedrohungen schützen können.
Darüber hinaus kann der HTTP-Sicherheitsheader auch dazu beitragen, den SEO-Score Ihrer Website zu verbessern.
Führen Sie die Überprüfung der Sicherheitsheader aus
Bevor Sie fortfahren, müssen Sie zunächst eine Sicherheitskopfprüfung auf Ihrer Website durchführen. Mit deren Hilfe können Sie leicht erkennen, welche wesentlichen Sicherheitskopfzeilen auf Ihrer Website fehlen.
Dazu müssen Sie die Security Header-Website besuchen und Ihre Website-Adresse eingeben, wie im Bild unten gezeigt:

Wenn Sie Ihre Website-URL eingeben und auf die Schaltfläche Scannen klicken, wird ein umfassender Bericht erstellt, der alle wichtigen fehlenden HTTP-Sicherheitsheader, falls vorhanden, in roter Farbe und eine Bewertung anzeigt, die zeigt, wie sicher Ihre Website ist.

Aus dem obigen Bild können Sie sehen, dass HTTP-Sicherheitsheader nicht erkannt wurden. die wir im folgenden Abschnitt erläutert und aufgelistet haben.
Liste der wichtigsten HTTP-Sicherheitsheader
Sehen wir uns einige der wichtigsten HTTP-Sicherheitsheader an, die Sie in Ihren Webanwendungen implementieren müssen, um die Sicherheit zu verbessern und eine zusätzliche Schutzebene zu ermöglichen.
1. X-Frame-Optionen
Zum ersten Mal hat Microsoft die X-Frame-Optionen in seinen Microsoft Internet Explorer eingeführt, die zum Schutz vor böswilliger Skriptinjektion oder Cross-Site-Scripting-Angriffen beitragen. Dieser HTTP-Sicherheitsheader schützt Ihre Website-iFrames, indem er Browser anweist, zu fragen, ob iFrame für die Website verarbeitet werden soll oder nicht.
Es schützt hauptsächlich vor allen Clickjacking-Angriffen, bei denen ein Angreifer mehrere Ebenen auf einem Link oder einer Schaltfläche implementiert, um Benutzer auf eine andere Seite umzuleiten und ihre wichtigen Informationen zu stehlen.
Zu befolgende Syntax:
1 2 3 |
X - Frame - Options : DENY X - Frame - Options : SAMEORIGIN X - Frame - Options : ALLOW - FROM < em > URL < / em > |
Anleitung Erläuterung:
DENY : Diese Direktive lässt iFrame nicht rendern
SAMEORIGIN: Diese Direktive erlaubt nur das Rendern von iFrames mit demselben Ursprung.
ALLOW-FROM: Diese Direktive erlaubt das Rendern von iFrame nur von einer bestimmten URL.
2. Strenge Transportsicherheit
Strict-Transport-Security oder HTTPS Strict Transport Security-Header hilft beim Schutz vor MIM-Angriffen und Cookie-Hijacking, wenn aktiviert. Diese Direktive zwingt den Browser, HTTPS statt HTTP-Kommunikation zu verwenden.
Lassen Sie uns verstehen, wie es funktioniert, wenn Sie eine Website auf HTTP ausführen und auf HTTPS darauf migrieren. Ihre alten Besucher werden weiterhin versuchen, mit HTTP auf die alte URL zuzugreifen. Da Sie Ihre Website bereits auf HTTPS migriert haben, wird sie von der alten URL auf die neue umgeleitet.
Aber der Punkt ist, dass Ihre Besucher immer noch auf die unverschlüsselte Version Ihrer Website zugreifen können, bevor sie auf die neue verschlüsselte URL umgeleitet werden. Zwischendurch erhalten die Hacker die Möglichkeit, MIM- oder Man-in-the-Middle-Angriffe durchzuführen.
Aber wenn Sie Strict-Transport-Security aktivieren, erhält der Browser Anweisungen, keine HTTP-Websites zu laden, sondern den Browser zu zwingen, über HTTPS zu kommunizieren.
Zu befolgende Syntax:
1 2 3 |
Strict - Transport - Security : max - age = < expire - time > Strict - Transport - Security : max - age = < expire - time > ; includeSubDomains Strict - Transport - Security : max - age = < expire - time > ; preload |
Anleitung Erklärung
max-age=<expire-time> : Mit dieser Direktive können Sie entscheiden, wie lange (in Sekunden) der Browser über HTTPS darauf zugreifen kann.
max-age=<ablaufzeit>; includeSubDomains : Wenn diese Anweisung erwähnt wird, bedeutet dies, dass die obige Regel auch für alle Subdomains der Website gilt.
max-age=<ablaufzeit>; preload : Diese Anweisung zeigt, dass die Website in der globalen Liste der HTTPS-Sites aufgeführt wurde.
3. Inhaltssicherheitsrichtlinie
Dieser HTTP-Sicherheitsheader weist den Browser an, nur die Inhalte zu laden, die in der Richtlinie erwähnt werden. Das bedeutet, dass Sie die Ressourcen Ihrer Website kontrollieren und Browsern erlauben werden, nur Inhaltsressourcen zu laden, die Sie auf die Whitelist gesetzt haben.
Es hilft Browsern zu entscheiden, woher Inhaltsressourcen wie Skripte, Bilder oder CSS geladen werden sollen. Wenn Sie diesen HTTP-Sicherheitsheader erfolgreich implementieren können, schützt er Ihre Website vor Clickjacking, Cross-Site Scripting (XSS) und jeder schädlichen Code-Injektion.
Obwohl es keinen 100%igen Schutz garantiert, hilft es, mögliche Schäden zu verhindern und zu begrenzen. Sogar die Mehrheit der Browser erkennt dieses ernste Problem jetzt und hat damit begonnen, es zu unterstützen.
Zu befolgende Syntax:
1 |
Content - Security - Policy : < policy - directive > ; < policy - directive > |
Anweisung Erklärung
<policy-directive> : Sie können jede Richtliniendirektive wie script-src(CSS) , img-src (Images) oder style-src (Stylesheet) einschließen und deren Laden zulassen.
4. X-Content-Type-Optionen
Mit dieser Art von Header können Sie das MIME-Typ-Sniffing einschränken oder verhindern, indem Sie dem Browser mitteilen, dass MIME-Typen absichtlich auf dem Server konfiguriert werden. Grundsätzlich bietet das MIME-Sniffing den Angreifern die Möglichkeit, jedes ausführbare bösartige Skript einzuschleusen.
Beispielsweise hat ein Angreifer eine bösartige Ressource injiziert, die die Antwort einer unschuldigen anderen Ressource, z. B. Bilder, geändert hat. Aufgrund von MIME-Sniffing stoppt der Browser das Rendern des Bildinhaltstyps, anstatt mit der Ausführung der eingeschleusten schädlichen Ressourcen zu beginnen.
Wenn Sie diesen Header aktivieren, wird er den Browser anvertrauen und zwingen, nur den MIME-Typen zu folgen, die in Content-Type-Headern angegeben wurden. Auf diese Weise können Sie böswillige Skriptinjektionen oder Cross-Site-Scripting-Angriffe einfach schützen und verhindern.
Zu befolgende Syntax:
1 |
X - Content - Type - Options : nosniff |
Anweisung Erklärung:
Die Direktive nosniff blockiert eine Anfrage sofort, wenn das Ziel der Anfrage vom Typ:
- Stil
- MIME-Typ ist nicht Text/CSS oder Typ Script
- Der MIME-Typ ist kein JavaScript-MIME-Typ
5. Referrer-Richtlinie
Mit dieser Header-Sicherheit können Sie steuern, ob die Referrer-Informationen offengelegt werden sollen. Wenn ja, um wie viel.
Bei anderen Anfragen teilt der Browser jedoch nur Informationen über die Herkunft mit.
Zu befolgende Syntax:
1 2 |
Referrer - Policy : origin - when - cross - origin Referrer - Policy : no - referrer - when - downgrade |
Erklärung der Anleitung:
Origin-When-Cross-Origin: Der Browser gibt vollständige Verweisinformationen für Anfragen gleichen Ursprungs und andere Anfragen weiter, der Browser gibt nur Informationen über den Ursprung weiter.
no-referrer-when-downgrade: Der Browser gibt keine Verweisinformationen weiter, wenn der Referrer
-Header für Anfragen an weniger sichere Ziele gesendet wird.
6. Funktions- oder Berechtigungsrichtlinie
Dieser Sicherheitsheader lässt eine Website entscheiden, ob sie Zugriff auf eine bestimmte Funktion oder API im Browser gewährt oder nicht. Mit Hilfe dieses Headers können Sie die Funktionalität jeder Anwendung in Ihrem Browser leicht steuern, die Ihre Privatsphäre verletzen und nur zulassen kann, wenn Sie es für legitim und notwendig halten.
Wenn Sie beispielsweise nicht möchten, dass die Website auf Ihr Mikrofon, Ihre Webcam oder Ihren Standort zugreift, und deren Funktionalität einschränken möchten, indem Sie die folgende Syntax befolgen:
1 2 3 |
Feature - Policy : microphone 'none' ; camera 'none' Feature - Policy : geolocation 'self' ; vibrate 'none' Permissions - Policy : geolocation = ( self ) , vibrate = ( ) |
folgende Syntax:
1 |
Feature - Policy : < directive > < allowlist > |
Anweisung Erklärung:
Die <Anweisung> kann alles sein, wie z. B. Beschleunigungsmesser, Autoplay, Umgebungslichtsensor, Batterie, Kamera, Mikrofon oder Geolokalisierung.

wohingegen die <allowlist> eine Liste von Ursprüngen ist, die einen oder mehrere Werte wie 'none', 'self' usw. separat setzen kann. Zu Referenzzwecken können Sie hier die vollständige Liste der Richtlinien und Zulassungslisten einsehen.
7. X-permitted Cross-Domain
Mit Hilfe dieses HTTP-Sicherheitsheaders können Sie dem Browser Anweisungen geben und die Kontrolle über alle Anfragen haben, die von Cross-Domain kommen. Wenn Sie diesen Header aktivieren, beschränken Sie Ihre Website darauf, unnötige Website-Assets zu laden, die von anderen Domains stammen. Damit Website-Ressourcen effizient genutzt werden können.
Dieser Sicherheitsheader ist optional und es ist nicht erforderlich, ihn zu haben, aber es ist gut, ihn zu installieren und zu aktivieren.
Zu befolgende Syntax:
1 |
X - Permitted - Cross - Domain - Policies : "none" |
8. XSS-Schutz
Der XSS-Schutz oder Cross-Site-Scripting-Schutz-Header wird eingeführt, um vor Cross-Site-Scripting-Angriffen zu schützen. Diese Angriffe gelten als sehr verbreitet und effektiv, daher haben die meisten Webbrowser standardmäßig den XSS-Schutz aktiviert.
Wenn ein Angreifer versucht, eine Website zu infizieren, indem er böswilligen Javascript-Code während einer HTTP-Anforderung einfügt, um vertrauliche Informationen wie Transaktionsdaten, persönliche Daten usw. zu stehlen. Wenn Cross-Site-Scripting-Angriffe erkannt werden, wird der XSS-Schutz-Header herausgefiltert und gestoppt sie sofort.
Dieser Filter war jedoch nur in alten Browsern verfügbar und ist jetzt für moderne Browser überflüssig geworden. Vor allem, wenn Sie bereits eine wirklich gute Sicherheitsrichtlinie implementiert haben und es gut ist, einfach weiterzumachen und sie zu haben, falls Ihre Besucher immer noch alte Browser verwenden, die die Inhaltssicherheitsrichtlinie nicht verstehen.
Zu befolgende Syntax:
1 2 3 4 |
X - XSS - Protection : 0 X - XSS - Protection : 1 X - XSS - Protection : 1 ; mode = block X - XSS - Protection : 1 ; report = < reporting - uri > |
Erläuterung:
0 – Dadurch wird der XSS-Schutz deaktiviert
1 – XSS-Schutz aktivieren
1; mode=block – Stoppt Browser, um Webseiten vollständig zu laden, wenn ein Cross-Site-Scripting-Angriff erkannt wird.
1; report=<reporting-uri> – Wenn ein XSS-Angriff erkannt wird, wird der unsichere Teil vom Browser blockiert und gemeldet
Wie kann die Schwachstelle in HTTP-Sicherheitsheadern auf Ihrer Website behoben werden?
Wenn Ihr Webhosting- Dienstleister Ihnen den Zugriff auf eine der beiden Dateien .htaccess oder wp-config.php ermöglicht. Dann kann es einfach sein, eine HTTP-Sicherheits-Header-Schwachstelle auf Ihrer Website zu beheben, indem Sie die HTTP-Sicherheits-Header an beliebiger Stelle hinzufügen.
Bei WPOven stellen Sie einen SSH-Zugang zur Verfügung, über den Sie einfach auf den Dateimanager zugreifen und Ihre .htaccess -Datei bearbeiten können.
Schritt 1 : Zuerst müssen Sie den SSH-Zugriff für die Site aktivieren. Dazu müssen Sie über das WPOven-Dashboard auf die Site zugreifen.

Navigieren Sie zum Abschnitt „Tools“ .

Dann müssen Sie im Abschnitt „Tools“ unten auf der Seite auf die Schaltfläche „SSH-Zugriff aktivieren“ klicken.

Schritt 2 : Sobald der SSH-Zugriff für die Site aktiviert ist, können Sie sich über Anwendungen von Drittanbietern wie Putty oder PenguiNet mit den SFTP-Anmeldedaten Ihrer Site anmelden
Sie können jedoch auch direkt über einen FTP-Client, der allgemein als File Zilla bekannt ist, auf Ihre .htaccess- oder wp-config.php-Datei zugreifen.
Alles, was Sie tun müssen, ist einfach die folgenden Schritte zu befolgen:
- Zuerst müssen Sie sich mit einem FTP-Client mit Ihrer WordPress-Website verbinden. Dadurch können Sie Ihre .htaccess-Datei bearbeiten. Diese Datei befindet sich im Stammverzeichnis Ihrer WordPress-Website.
- Falls die .htaccess-Datei nicht sichtbar ist, sollten Sie die versteckten Dateien einchecken.
- Es ist kein spezieller Editor erforderlich, Sie können den Code in einem beliebigen Texteditor wie Notepad schreiben.
- Sie müssen diesen Code schreiben und in die .htaccess-Datei einfügen. Es wird empfohlen, es am Ende der .htaccess-Datei hinzuzufügen.
- Wenn Sie die Website gefunden haben, laden Sie sie auf Ihr lokales Laufwerk herunter und öffnen Sie sie dann in einem beliebigen Texteditor. Die einfachste Option ist ein Standard-Notepad. Fügen Sie den folgenden Code am Ende der Datei hinzu:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
X - Frame - Options : DENY X - Frame - Options : SAMEORIGIN X - Frame - Options : ALLOW - FROM URL Strict - Transport - Security : max - age = < expire - time > Strict - Transport - Security : max - age = < expire - time > ; includeSubDomains Strict - Transport - Security : max - age = < expire - time > ; preload Content - Security - Policy : < policy - directive > ; < policy - directive > X - Content - Type - Options : nosniff Referrer - Policy : origin - when - cross - origin Referrer - Policy : no - referrer - when - downgrade Feature - Policy : < directive > < allowlist > X - Permitted - Cross - Domain - Policies : "none" X - XSS - Protection : 0 X - XSS - Protection : 1 X - XSS - Protection : 1 ; mode = block X - XSS - Protection : 1 ; report = < reporting - uri > |
Ändern Sie die Attribute, Anweisungen und Werte nach Bedarf, speichern Sie sie und laden Sie sie hoch.
Alternativ können Sie auch auf Ihre Webserver-Konfigurationsdateien zugreifen und diese Sicherheitsheader anwenden. Wenn Sie jedoch keine Änderungen selbst vornehmen möchten und ein WPOven-Kunde sind, können Sie ein Support-Ticket eröffnen und wir können das schnell für Sie erledigen.
Zusammenfassung
Aus dem obigen Beitrag können Sie ersehen, wie wichtig es ist, einen HTTP-Sicherheitsheader auf Ihrer Website zu aktivieren. Und inwieweit sie eine Website-Sicherheitshärtung bieten. Diese Sicherheiten wurden jedoch standardmäßig in den neuesten und fortschrittlichsten verfügbaren Browsern implementiert. Trotzdem gibt es keinen Grund, warum ich sie nicht verwenden sollte.
Falls Sie keinen Zugriff auf Ihre Website-Server haben, haben Sie es schwierig. Es ist immer besser, professionelle Hilfe in Anspruch zu nehmen. Es ist besser, Sie wenden sich an Ihren Webhosting-Anbieter und bitten ihn, HTTP-Sicherheitsheader auf Ihrer Website zu implementieren.
Häufig gestellte Fragen
Sind HTTP-Header sicher?
Ja, HTTP-Sicherheitsheader sind eine der wichtigsten Richtlinien zur Härtung der Cybersicherheit. Die gesamten Informationen in den HTTP-Headern sind verschlüsselt.
Welche Header bieten Sicherheit?
Einige der Header, die die Sicherheit der Website erhöhen, sind:
1. X-Frame-Optionen
2. Strenge Transportsicherheit
3. Inhaltssicherheitsrichtlinie
4. X-Content-Type-Optionen
5. Referrer-Richtlinie
6. Funktions- oder Berechtigungsrichtlinie
7. X-permitted Cross-Domain
8. XSS-Schutz
Was ist ein CSP-Header?
Der CSP- oder Content Security Policy-Header weist den Browser an, nur die Inhalte zu laden, die in der Richtlinie erwähnt werden. Das bedeutet, dass Sie die Ressourcen Ihrer Website kontrollieren und Browsern erlauben werden, nur Inhaltsressourcen zu laden, die Sie auf die Whitelist gesetzt haben.