WordPress Dashboard Artikelbild Dunkel

HTTP Security Headers für WordPress ohne Plugin einrichten

Ich bin erst seit knapp einem Monat wieder online. Deshalb stecke ich - bildlich gesprochen - mit meinem Kopf noch immer tief unter der Motorhaube meines Blogs und kümmere mich um die Konfiguration meiner Website. Dabei bin ich unter den Aspekten Sicherheit und Datenschutz auf das Thema „HTTP Security Headers“ gestoßen. Wie man diese ohne viel Aufwand und ohne Einsatz eines Plugins für eine WordPress betriebene Seite einrichtet, möchte ich in diesem Artikel kurz vorstellen.

In einem Gast­bei­trag im Blog des IT-Sicher­heits­ex­per­ten Mike Kuketz bin ich auf ein Kapi­tel zur „Daten­schutz-Beur­tei­lung“ gesto­ßen. Dort wird unter ande­rem der Ser­vice von Webb­koll (s.u.) vor­ge­stellt. Ähn­lich wie bei einem Page­s­peed-Test kann man sich dort sei­ne Web­site scan­nen und bewer­ten las­sen, aller­dings nicht in Sachen Geschwin­dig­keit, son­dern hin­sicht­lich Daten­schutz­freund­lich­keit bzw. Daten­schutz­ni­veau. Nach dem Scan bekommt man nicht nur die Aus- sowie Bewer­tung prä­sen­tiert, son­dern auch umfang­rei­che Infor­ma­tio­nen zu den ein­zel­nen Mög­lich­kei­ten und Kon­fi­gu­ra­ti­ons­fak­to­ren sowie Ver­wei­se auf wei­te­re Quellen.

Eine der Mög­lich­kei­ten, sei­ne Web­site siche­rer zu machen und damit auch das Risi­ko eines Daten­miss­brauchs durch Daten­mi­ni­mie­rung, Inte­gri­tät und Ver­trau­lich­keit, daten­schutz­freund­li­che Vor­ein­stel­lun­gen, Sicher­heit der Ver­ar­bei­tung (im Sin­ne der Arti­kel 5.1c, 5.1f, 25 und 32.1–2 der DSGVO) zu ver­mei­den sind die besag­ten HTTP Secu­ri­ty Hea­der. Und um eini­ge die­ser soll es jetzt im Fol­gen­den gehen.

Was sind „HTTP Security Header“ und was bewirken sie?

Mit Hil­fe der HTTP Secu­ri­ty Hea­der las­sen sich zusätz­li­che Schutz­me­cha­nis­men des Brow­sers akti­vie­ren, mit dem Dei­ne Web­site auf­ge­ru­fen bzw. ange­surft wird und die nicht stan­dard­mä­ßig akti­viert sind. David Jar­din spricht in die­sem Zusam­men­hang tref­fend von den „schlum­mern­den Wach­hun­den des Brow­sers“, die man mit Hil­fe der HTTP Secu­ri­ty Hea­der erwe­cken könne.

Die­se „Erwe­ckung“ geschieht durch die Imple­men­tie­rung ent­spre­chen­der Anwei­sun­gen in der .htac­cess-Datei im Root­ver­zeich­nis auf Dei­nem Ser­ver. Dies hat zur Fol­ge, dass der Brow­ser der Besu­che­rin bzw. des Besu­chers die­se Anwei­sun­gen beim Auf­ru­fen Dei­ner Web­site über­mit­telt bekommt und sei­ne „schla­fen­den Wach­hun­de“ akti­viert. Damit sor­gen die HTTP Secu­ri­ty Hea­der dann nicht nur für zusätz­li­che Sicher­heit auf Dei­ner Web­site, son­dern bewir­ken eben­so einen Schutz für Dei­ne Besu­che­rin­nen und Besucher.

Voraussetzung und ein wichtiger Hinweis

Wie ich bereits geschrie­ben habe, möch­te ich in die­sem Arti­kel die Ein­rich­tung der HTTP Secu­ri­ty Hea­der mit Hil­fe der Ein­tra­gung von Anwei­sun­gen in die .htac­cess-Datei erläu­tern. Dies hat zur Vor­aus­set­zung, dass Dir Dein Hosting­an­bie­ter den Zugriff auf und die Bear­bei­tung der .htac­cess-Datei auch gestat­tet. Tut er dies nicht, dann brauchst Du hier nicht wei­ter­zu­le­sen, son­dern müss­test ein Plugin zu Hil­fe neh­men. Geeig­ne­te Plugins fin­dest Du in der Wor­d­Press Repo­si­to­ry. Aller­dings möch­te ich hier kei­ne direk­te Emp­feh­lung aus­spre­chen, da ich kei­ner­lei Erfah­run­gen mit sol­chen Plugins gesam­melt habe. Aus­ge­hend von den Bewer­tun­gen kannst Du Dir mal „Redi­rec­tion“ von John God­ley oder „HTTP Hea­ders“ von Dimitar Iva­nov anschauen.

Bitte lasse Vorsicht walten!

Die .htac­cess-Datei ist ein hoch­sen­si­bler Part Dei­ner Wor­d­Press-Instal­la­ti­on. Nicht jede Wor­d­Press Instal­la­ti­on ist gleich, allein schon nicht mit Blick auf das The­me und die Plugins, die zum Ein­satz kom­men. Des­halb ist es mit „Copy & Pas­te“ der unten vor­ge­stell­ten Ein­tra­gun­gen nicht unbe­dingt getan und es kann auch sein, dass sie bei Dir nicht funk­tio­nie­ren oder Pro­ble­me ver­ur­sa­chen. Das kann sogar so weit gehen, dass Dei­ne Web­site (auch für Dich) nicht mehr erreich­bar ist. Deshalb:

  • erstel­le zuerst ein Back­up Dei­ner Web­site und zusätz­lich eines der .htac­cess-Datei, bevor Du dar­an Hand anlegst;
  • gehe Schritt für Schritt vor, d. h. tra­ge die Hea­der ein­zeln ein und tes­te anschlie­ßend, ob Dei­ne Sei­te noch ein­wand­frei funk­tio­niert (und zwar im Front- wie im Backend!), bevor Du mit dem nächs­ten Hea­der weitermachst.

Soll­te es bei Dir zu Pro­ble­men kom­men, lösche die in der .htac­cess-Datei getä­tig­ten Ein­tra­gun­gen wie­der bzw. spie­le die zuvor gesi­cher­te Ver­si­on der .htac­cess-Datei wie­der ein, wenn alle Stri­cke rei­ßen sollten.

Wenn Du Dir nicht sicher bist, lass’ es lie­ber und wen­de Dich ggf. an eine Fach­frau bzw. einen Fachmann.

Zur Einrichtung der „HTTP Security Header“

Die nach­fol­gen­den fünf vor­ge­stell­ten HTTP Secu­ri­ty Hea­der sind nur eine Aus­wahl. Bei mei­nen Recher­chen kam her­aus, dass es sich bei die­sen um die wich­tigs­ten und die für Wor­d­Press betrie­be­nen Web­sites am ein­fachs­ten ein­zu­rich­ten­den Hea­der sind.

So bleibt bspw. die „Con­tent-Secu­ri­ty-Poli­cy“ hier unbe­rück­sich­tigt. Dabei han­delt es sich zwar um den wohl mäch­tigs­ten Hea­der, aber lei­der auch um einen, der in Con­tent Manage­ment Sys­te­men wie Wor­d­Press die meis­ten Pro­ble­me macht. Die Akti­vie­rung die­ses Hea­ders ist eine ziem­lich kniff­li­ge und auf­wen­di­ge Ange­le­gen­heit. Es müs­sen vie­le Aus­nah­men kor­rekt kon­fi­gu­riert wer­den, damit es nicht zu schwer­wie­gen­den Pro­ble­men bis zur Nicht­er­reich­bar­keit der Web­site kommt. Nicht nur, dass die Mäch­tig­keit die­ses Hea­ders durch die vie­len Aus­nah­men kas­triert wird, so dass die Imple­men­tie­rung mit Blick auf den dann noch ver­blei­ben­den Nut­zen frag­lich wird. Auch weil die Kon­fi­gu­ra­ti­on peni­bel auf die jewei­li­ge Instal­la­ti­on indi­vi­du­ell ange­passt wer­den muss, macht eine ein­ge­hen­de­re Vor­stel­lung hier frag­lich. Aus die­sem Grund ist die­ser Hea­der hier nur der Voll­stän­dig­keit hal­ber erwähnt, aber nicht wei­ter behandelt.

Ich kom­me zu den fünf HTTP Secu­ri­ty Hea­der, bei denen es weni­ger kom­pli­ziert ist und deren Akti­vie­rung bereits für eine gan­ze Men­ge an zusätz­li­cher Sicher­heit sorgt.

HTTP Strict Transport Security

Ich gehe ein­mal davon aus, dass Du Dei­ne Web­site schon längst auf „htt­ps“ umge­stellt hast. Wenn nicht, dann rate ich Dir drin­gend dazu, das nach­zu­ho­len. Wenn Dei­ne Web­site bereits auf „htt­ps“ umge­stellt ist, dann kannst Du mit dem „HTTP Strict Trans­port Secu­ri­ty“ Hea­der dafür sor­gen, dass Dei­ne Web­site aus­schließ­lich nur über die ver­schlüs­sel­te Ver­bin­dung via „htt­ps“ erreich­bar ist und jeg­li­che Anfra­ge bzw. jeder unver­schlüs­sel­te Kom­mu­ni­ka­ti­ons­ver­such über „http“ strikt auf „htt­ps“ umge­lei­tet wird. Damit schützt Du Dei­ne Besu­che­rin­nen und Besu­cher vor mög­li­chen „Man-In-The-Midd­le“ Angrif­fen, indem die ver­schlüs­sel­te Kom­mu­ni­ka­ti­on mit Dei­ner Web­site erzwun­gen wird und die unver­schlüs­sel­te Kom­mu­ni­ka­ti­on gar nicht mehr mög­lich ist. Noch­mal: die­ser Hea­der macht natür­lich nur Sinn, wenn Dei­ne Sei­te auf „htt­ps“ umge­stellt ist.

Der Ein­trag für Dei­ne .htac­cess-Datei sieht wie folgt aus:

<ifModule mod_headers.c>
   Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
</ifModule>

Mit „max-age“ wird die Dau­er defi­niert, wie lan­ge sich der Brow­ser mer­ken soll, dass Dei­ne Web­site aus­schließ­lich via „htt­ps“ erreich­bar ist. Die­se Dau­er muss in Sekun­den ange­ge­ben wer­den. Im obi­gen Bei­spiel ent­spre­chen die 31536000 Sekun­den einem Jahr, was so als Kon­fi­gu­ra­ti­on emp­foh­len wird.

Sofern Du Sub­do­mains nutzt, kannst Du mit Hil­fe eines optio­na­len Zusat­zes den Hea­der ent­spre­chend erwei­tern. Wie das geht und noch eini­ges mehr, erfährst Du unter hier.

X‑XSS Protection

Die­ser Hea­der wird nur vom Inter­net Explo­rer, Chro­me und Safa­ri unter­stützt, wobei Chro­me die Unter­stüt­zung mitt­ler­wei­le auch ein­ge­stellt hat. Trotz­dem kannst Du die­sen Hea­der akti­vie­ren, um alle Dei­ne Besu­che­rin­nen und Besu­cher, die noch mit älte­ren Brow­ser­ver­sio­nen unter­wegs sind, den ent­spre­chen­den Schutz zu gewähr­leis­ten. Der Schutz, den der „X‑XSS Pro­tec­tion“ Hea­der akti­viert, wird mitt­ler­wei­le durch die oben ange­spro­che­ne „Con­tent-Secu­ri­ty-Poli­cy“ bereit­ge­stellt. Aber wie schon gesagt, spa­re ich mir aus den genann­ten Grün­den die Behand­lung der „Con­tent-Secu­ri­ty-Poli­cy“ hier aus.

Woge­gen schützt nun die­ser Hea­der? Die „X‑XSS Pro­tec­tion“ schützt vor soge­nann­ten „Cross-Site-Scrip­ting“ Atta­cken, indem sie in den unter­stüt­zen Brow­sern das Laden von ent­spre­chend kom­pri­mit­tier­ten Sei­ten unterbindet.

Der Ein­trag für Dei­ne .htac­cess-Datei sieht wie folgt aus:

<ifModule mod_headers.c>
   Header set X-XSS-Protection "1; mode=block"
</ifModule>

Wei­te­re Infos fin­dest Du hier.

X‑Content-Type-Options

Der Hea­der „X‑Con­tent-Type-Opti­ons“ kann vor „Dri­ve-By-Down­load“ Atta­cken schüt­zen. Hin­ter­grund ist, dass Brow­ser bei nicht kor­rekt dekla­rier­ten Medi­en­ty­pen so ein­ge­stellt sind, dass sie das Daten­for­mat erra­ten (das soge­nann­te „MIME-Snif­fing“). Das könn­te durch einen poten­zi­el­len Angrei­fer aus­ge­nutzt wer­den. Durch die Akti­vie­rung des „X‑Con­tent-Type-Opti­ons“ Hea­der wird die­ses Erra­ten des Daten­for­mats unterbunden.

Der Ein­trag für Dei­ne .htac­cess-Datei sieht wie folgt aus:

<ifModule mod_headers.c>
   Header set X-Content-Type-Options nosniff
</ifModule>

Wei­te­re Infos fin­dest Du hier.

X‑Frame-Options

Mit dem „X‑Frame-Opti­ons“ Hea­der kannst Du Dich vor „Click-Jacking“ Atta­cken schüt­zen, also davor, dass Dei­ne Web­site oder Tei­le davon auf frem­den Sei­ten mit­tels „frame“, „iframe“, „embed“ oder „objekt“ ein­ge­bun­den wer­den, Du Dich also vor Con­tent-Dieb­stahl schützt.

Aber Ach­tung! Das bringt aller­dings den Nach­teil mit sich, dass auch auf Dei­ner Web­site das Ein­bin­den von bspw. You­Tube-Vide­os, Tweets etc. nicht mehr funktioniert.

Der Ein­trag für Dei­ne .htac­cess-Datei sieht wie folgt aus:

<ifModule mod_headers.c>
   Header set X-Frame-Options DENY
</ifModule>

Eben­so Vor­sicht beim Ein­satz von Page­buil­dern! Mit der Ein­stel­lung »DENY« kann es Pro­ble­me mit dem einen oder ande­ren Page­buil­der geben. Der haus­ei­ge­ne Guten­berg-Edi­tor zeigt mei­nem Wis­sen nach kei­ne Pro­ble­me. Anders sieht es aber z. B. beim belieb­ten und weit ver­brei­te­ten Ele­men­tor Page­buil­der aus. Der funk­tio­niert mit die­ser Ein­stel­lung nicht mehr. Soll­test Du den Ele­men­tor Page­buil­der oder einen ande­ren ver­wen­den, der mit die­ser Ein­stel­lung Pro­ble­me hat, dann ver­wen­de statt „DENY“ die Ein­stel­lung „SAMEORGIN“. Ein etwas auf­wen­di­ger Kom­pro­miss wäre, den Hea­der-Ein­trag für die X‑Frame-Opti­ons jedes mal für die Zeit, wenn Du eine Sei­te oder einen Bei­trag mit einem Page­buil­der baust, aus der .htac­cess-Datei zu löschen und anschlie­ßend wie­der einzufügen.

Ob „DENY“ oder „SAMEORGIN“, mit bei­den Ein­stel­lun­gen wirst Du jedoch fest­stel­len, dass Du im Backend bei den Plugins einen lee­ren Frame zu sehen bekommst, wenn Du auf »Details anse­hen« klickst. Das kannst Du umge­hen, indem Du den Link zu den Details in einem neu­en Tab oder Fens­ter öffnest.

Wei­te­re Infos fin­det Du hier.

Referrer-Policy

Mit die­sem Hea­der schützt Du Dei­ne Web­site nicht direkt vor Angrif­fen, tust aber was für den Schutz der Daten Dei­ner Besu­che­rin­nen und Besu­cher. Ver­linkst Du eine ande­re Web­site und eine Besu­che­rin bzw. ein Besu­cher klickt auf die­sen Link und der Betrei­ber der ver­link­ten Web­site setzt ent­spre­chen­de Ana­ly­se­tools ein, so unter­bin­det der „Refer­rer-Poli­cy“ Hea­der die Über­mitt­lung der Infor­ma­ti­on, das sie bzw. er von Dei­ner Sei­te kommt.

Der Ein­trag für Dei­ne .htac­cess-Datei sieht wie folgt aus:

<ifModule mod_headers.c>
   Header set Referrer-Policy: no-referrer
</ifModule>

Wei­te­re Infos fin­dest Du hier.

Referenzen / Quellen

Da ich alles ande­re als ein Fach­mann bin, habe ich mich über den Sinn und Zweck sowie die Ein­rich­tung der HTTP Secu­ri­ty Hea­der mit­tels einer Recher­che im Inter­net kun­dig gemacht. Mein rudi­men­tä­res Wis­sen basiert auf fol­gen­den Quel­len, die ich Dir abschlie­ßend noch ein­mal ger­ne ans Herz legen möch­te, wenn Du mehr über die HTTP Secu­ri­ty Hea­der erfah­ren möchtest:

Schreibe einen Kommentar

Hinweis zum Datenschutz: Wenn Du auf »Kommentar abschicken« klickst, erklärst Du Dich damit einverstanden, dass Deine hier angegebenen Daten (einschließlich IP-Adresse und Zeitstempel) bis zum Widerruf gespeichert werden. Weitere Informationen hierzu findest Du in meiner Datenschutzerklärung.