Die Integration der Security Header ist im Grunde genommen die klassische Maßnahme, die bei allen Optimierungen der eigenen Website vergessen wird. Es ist wie immer beim Thema Sicherheit: Bevor nicht etwas passiert ist, wird auch nichts dafür getan. Das solltet ihr unbedingt anders machen.

Ein Schritt in die richtige Richtung sind die sogenannten Security-Header, die mittels .htaccess in die jeweilige Website integriert, oder besser gesagt im Hosting, aktiviert werden können. Dabei handelt es sich um HTTP-Header, die bestimmte Funktionen sperren oder einfach nur dafür sorgen, dass keine unsicheren Quellen mehr zum Einsatz kommen können.

Welche Security Header es gibt und wie ihr diese überprüft, verrät unser heutiger Artikel. Natürliche haben wir euch auch gleich noch jeweils ein Snippet als Beispiel angehängt, welches ihr nach Belieben anpassen könnt. Viel Spaß beim Lesen.

security-header1 1

Welche Security Header gibt es?

Zunächst einmal sollten wir uns ansehen, welche Security Header zurzeit existieren. Davon stehen eine ganze Menge zur Verfügung, wobei nicht alle gleichermaßen wichtig sind oder überhaupt Sinn ergeben. Bestimmte Header spielen eine größere Rolle als andere, doch dazu später mehr. Schauen wir uns zunächst an, welche Security Header es gibt.

Strict-Transport-Security

HTTP Strict Transport Security ist ein Header, der den Browser anweist, ausschließlich HTTPS zu verwenden. Dem Browser wird über diesen Header demnach mitgeteilt, in der übermittelten Antwort immer eine HTTPS-Verbindung zu nutzen. Mit diesem Header können klassische Downgrade-Attacken und das Session Hijacking verhindert werden. Bekannt wurde der Header vor allem, weil Chrome eine eigene HSTS-Preload-Liste führt.

Strict-Transport-Security: max-age=31536000; includeSubDomains
security-header2 2

Content-Security-Policy

Die Content-Security Policy ist nicht einfach zu integrieren, sorgt, sobald sie einmal korrekt eingerichtet wurde, dann aber dafür, dass keine bösartigen Inhalte aus unseriösen Quellen mehr geladen werden können. Die Content-Security-Policy regelt dabei, woher Ressourcen stammen dürfen und ob Inline Scripts und Inline CSS möglich sind. Außerdem ersetzt sie mit dem Eintrag »frame-ancestors« den alten X-Frame-Options Header.

Content-Security-Policy: default-src 'self'
security-header3 3

X-Content-Type-Options

Mit diesem Header kann verhindert werden, dass das sogenannte MIME-Sniffing stattfindet. Wird kein MIME-Typ hinterlegt, versuchen einige Browser selbst einen zu finden. Es wird also probiert, das richtige Format zu erkennen. Problem bei der Sache ist, dass genau dieses Verhalten als Sicherheitslücke ausgenutzt werden kann, um bösartige XSS-Angriffe (Cross Site Scripting) zu senden. Daher sollte das MIME-Sniffing unbedingt deaktiviert werden.

X-Content-Type-Options: nosniff
security-header4 4

Permissions-Policy (früher Feature-Policy)

Aktuell sollte zusätzlich zur brandneuen Permissions-Policy auch die veraltete Feature-Policy integriert werden. Letztere wird von fast allen Browsern unterstützt, während die neue Version noch wenig Support erhält. Doch was macht die Permissions-Policy genau? Sie legt fest, welche Funktionen im Browser aktiv sind und welche APIs verwendet werden können. Also beispielsweise Standortdaten und Mikrofon. Über den Security Header kann festgelegt werden, wer die Daten nutzen darf und welche Funktionen vielleicht gänzlich deaktiviert werden.

Permissions-Policy accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
security-header5 5

Referrer-Policy

Besonders wichtig und nicht mehr wegzudenken ist die Referrer-Policy. Sie gibt an, welche Informationen weitergegeben werden, wenn Nutzer*innen auf eine andere Seite navigieren. Für gewöhnlich ist es so: Jemand kauft auf Amazon ein und geht dann rüber zur Google-Suche. Google sieht als Referrer jetzt Amazon.de und weiß somit genau, wo derjenige zuletzt gewesen ist. Um das zu verhindern, könnte Amazon die Referrer-Policy konfigurieren. Hier gibt es verschiedene Einstellungen, die je nach Bedarf gewählt werden können.

Referrer-Policy: no-referrer
security-header6 6

Sonstige Security Header

Es gibt einige obsolete Security Header. Auch bestehen Header, die nur in bestimmten oder fast gar keinen Fällen notwendig sind. Zu nennen sind hier »Expect-CT« oder »X-XSS-Protection«. Auch der »X-Frame-Options« wird heutzutage nicht mehr genutzt. Wirklich wichtig sind nur die, die wir euch hier auf der Seite genannt haben.

Neu hinzukommen werden »Cross-Origin-Embedder-Policy«, »Cross-Origin-Opener-Policy« sowie »Cross-Origin-Resource-Policy«. Wie oben erwähnt, wird außerdem die »Feature-Policy« von der Permissions-Policy abgelöst. Bei den Security Headern gilt es also aktuell zu bleiben, um keine verwaisten Einträge in seiner .htaccess zu haben.

Wie nutze und teste ich die Security Header?

Das geht über die .htaccess-Datei auf eurem Server. Hier werden die gewünschten Header sauber implementiert. Viel einfacher und praktischer, als diese händisch zu integrieren, geht es dabei mit Online-Tools. Diese sind mitunter auch notwendig, weil einige Security Header wirklich sehr komplex ausfallen können und somit schwierig zu konfigurieren sind.

Mit diesem Online-Tool könnt ihr die für euch wichtigen Security Header erstellen und erhaltet gleich noch passende Erklärungen zu den jeweiligen Werten. Damit sollte es jedem möglich sein, entsprechende Richtlinien in seine Website zu implementieren.

Ob die Security Header erfolgreich und korrekt implementiert wurden, lässt sich ebenfalls über ein Online-Tool herausfinden. Auf der Website securityheaders.com wird die eigene Domain nicht nur ausgiebig analysiert, sondern auch mit detaillierten Ergebnissen und Erklärungen gelistet, sollte ein wichtiger Header fehlen.

Fazit zu den Security Headern

Security Header sind das, was alle erst einmal vergessen, wenn sie ihre Website aufbauen. Egal ob KMU oder Großunternehmen, selbst die jeweiligen Expert*innen übersehen die Security Header nur allzu gerne und widmen sich lieber anderen Dingen. Dabei sind gerade diese Standards wichtig, um für die grundlegende Sicherheit einer Website zu sorgen.

Mit wenig Aufwand lassen sich dann Browser-Features deaktivieren, die nicht gebraucht werden. Was abgeschaltet ist, kann auch nicht mehr durch Sicherheitslücken ausgenutzt werden. Quellen für Ressourcen und Embeds lassen sich strenger kontrollieren und klassische Angriffe können effektiv verhindert werden. Alles mit ein paar Zeilen in der eigenen .htaccess auf dem Server.

Genau deshalb war uns dieser Artikel auch wichtig. Um darauf aufmerksam zu machen, wie einfach und schnell die Header implementiert werden können. Da braucht es nur ein paar Online-Tools und einige Zeilen Code, schon stehen die Regeln zum Einfügen bereit. Wir raten dringend dazu, euch das Thema mal genauer anzusehen und die Security Header auch auf eurem Server zu implementieren. Wie ihr seht, geht das ganz einfach.

by A-DIGITAL one

Unsere Herzen schlagen Digital, unsere Projekte leben Digital, unsere Kunden lieben und schätzen Digital! Die einzigartige digitale Performance die wir seit 1999 an den Tag legen.

Mit unserem Team von über 35 Experten begleiten wir Sie auf Ihrem Weg der digitalen Transformation. Mit klaren Strategien, persönlicher Betreuung und exzellenter Ausführung entwickeln wir, innovativ und individuell, maßgeschneiderte digitale Lösungen, die performen und verkaufen können.