In einem Gast­bei­trag im Blog des IT-Sicher­heits­exper­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­speed-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 Hos­tin­g­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 Plug­in zu Hil­fe neh­men. Geeig­ne­te Plug­ins fin­dest Du in der Word­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 Plug­ins 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 Word­Press-Instal­la­ti­on. Nicht jede Word­Press Instal­la­ti­on ist gleich, allein schon nicht mit Blick auf das The­me und die Plug­ins, 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 Word­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 Word­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 „https“ umge­stellt hast. Wenn nicht, dann rate ich Dir drin­gend dazu, das nach­zu­ho­len. Wenn Dei­ne Web­site bereits auf „https“ 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 „https“ 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 „https“ 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 „https“ 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 „https“ 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-Jack­ing“ 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 Plug­ins 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:

• »How to add HTTP Secu­ri­ty Hea­ders in Word­Press« auf wpbeginners.com: In die­sem Arti­kel wird kurz beschrie­ben, um was es bei den HTTP Secu­ri­ty Hea­ders geht und wie man sie ein­rich­tet. Das Code Snip­pet für die .htac­cess-Datei, mit dem ich gear­bei­tet und expe­ri­men­tiert habe, kommt aus die­sem Arti­kel. Außer­dem fin­dest Du dort auch Anlei­tung, wie Du HTTP Secu­ri­ty Hea­ders mit Hil­fe eines Plug­ins ein­rich­ten kannst.
• »Ver­ant­wor­tungs­vol­les Mar­ke­ting: Es geht auch ohne Goog­le, Face­book, Xing und Co.«: Der schon erwähn­te Arti­kel auf dem Blog von Mike Kuketz, der mich auf das The­ma der »HTTP Secu­ri­ty Hea­der« auf­merk­sam gemacht und den Stein erst ins Rol­len gebracht hat (sie­he dort Kapi­tel 3.6 »Daten­schutz-Beur­tei­lung«).
• webb­koll: Ein Ser­vice, mit dem Du Dei­ne Web­site tes­ten las­sen kannst, wie es um die Sicher­heit in Sachen Daten­schutz bestellt ist.
• MDN Web Docs moz://a: Sehr umfang­rei­che Infor­ma­tio­nen zu den vie­len HTTP Hea­der fin­dest Du auf den Deve­lo­per­sei­ten von mozilla.org.
• „Word­Press-Sicher­heit mit HTTP-Secu­ri­ty-Hea­der erhö­hen“: Ein inter­es­san­ter Arti­kel zum The­ma von Thors­ten Fal­tings auf elbnetz.com.
• „HTTP-Secu­ri­ty-Hea­der – Web­site-Sicher­heit erhö­hen“: Ein wei­te­rer guter Arti­kel zum The­ma auf codingblatt.de.
• „Secu­ri­ty-Hea­der: So machst du dei­ne Web­site sicher“: Ein sehr umfang­rei­cher und infor­ma­ti­ver Arti­kel zum The­ma von Mar­kus Seyfferth auf drweb.de.
• Last but not least der oben schon erwähn­te und ver­link­te Arti­kel „HTTP Secu­ri­ty-Hea­der – Wie Sie die schlum­mern­den Wach­hun­de des Brow­sers wecken“ von David Jar­din auf hosteurope.de.