Andreas Hecht 23. Februar 2016

Mehr Speed, mehr Sicherheit: die optimale .htaccess

Die optimale .htaccess Datei für mehr Speed und Sicherheit

Die Webserver-Konfigurationsdatei .htaccess ist eine der wichtigsten Dateien deiner Website-Installation. Viel kann diese oftmals noch unterschätzte Datei leisten. Sie kann zu einem wahren Performance-Schub einer Website ebenso beitragen, wie zu erhöhter Sicherheit. Beides ist in der heutigen Zeit wichtig. Die Ladegeschwindigkeit ist bereits seit längerem ein Rankingfaktor für die Position der eigenen Website in den Google-Suchergebnissen. Zudem werden immer wieder WordPress-Websites gehackt, weil kein Augenmerk auf die Sicherheit der Website gelegt wird. In diesem Artikel stelle ich meine eigene .htaccess-Datei vor, die ich im Laufe der Zeit immer weiter verfeinert und optimiert habe.

Die optimale .htaccess Datei für mehr Speed und Sicherheit

Eine optimale .htaccess Datei

Eine optimale .htaccess-Datei wird es niemals fertig konfiguriert geben können, da sich viele Punkte individuell auf die eigene Website beziehen werden. Auch die von mir vorgestellte Datei ist nur ein großer Teil dessen, was bei mir aktiv ist. Einiges muss noch auf persönliche Bedürfnisse angepasst werden, doch mit dem folgenden Code hat man bereits sehr viel erreicht. Vor allem ist eine optimale Grundlage für eine wirklich schnelle Website geschaffen worden. Nicht vergessen habe ich dabei den Bereich Sicherheit, der sich zum Teil auf WordPress bezieht.

Die komplette Datei kann bei GitHub heruntergeladen werden.

Teil 1: Browser-Caching

Im Abschnitt Caching wurde an alles gedacht, auch an das Zwischenspeichern der beliebten Webfonts, die dann allerdings auf dem eigenen Server liegen sollten. In der Sektion für die Bildformate findet das neue Grafik-Format WebP Berücksichtigung. Dateien, die sich im Allgemeinen eher selten ändern, zum Beispiel JavaScripts, bekommen einen weit in der Zukunft definierten Cache-Header. Feeds hingegen werden nur eine Stunde gecached, fast alle anderen Dateien hingegen einen Monat. Zu beachten ist, dass in der Datei statische HTML-Seiten für eine schnellere Auslieferung für eine Stunde (3.600 Sekunden) in den Speicher befördert werden. Wer das nicht möchte, setzt stattdessen ein access plus 0 seconds ein.

Der ETag-Header wird durch die .htaccess deaktiviert, da ein Last-Modified-Header gesendet wird. Zudem ist die ETag-Technologie bekannt als langsam, daher nutzen wir sie nicht. Wichtig zu erwähnen ist, dass ein keep-alive-Header gesendet wird. Das erlaubt dem Browser das gleichzeitige Laden mehrerer Dateien und sorgt für einen weiteren Performance-Schub.

Bitte beachten: Da auch das CSS zwischengespeichert wird, sollte man, wenn man öfter etwas daran ändert, entweder die Datei nach einer Änderung umbenennen, oder eine Versionierung implementieren. Ich bevorzuge die zweite Lösung, die ein Teil eines zukünftigen Artikels sein wird.

Ein Klick öffnet die komplette Datei bei GitHub
htaccess-caching

Teil 2: Die komprimierte Auslieferung der Dateien

Viele Vorschläge für .htaccess Dateien, die im Netz zu finden sind, sind nur rudimentär und unvollständig. Alle denkbaren und wichtigen Datei-Formate werden durch meine .htaccess komprimiert ausgeliefert, damit ein wirklicher Geschwindigkeitsvorteil entsteht.

Ein Klick öffnet die komplette Datei bei GitHub
Kompression

Teil 3: Allgemeine Sicherheitseinstellungen

Der Grand­sei­g­neur des Webdesigns – Jeff Starr von Perishable Press – feilt bereits seit Jahren an seiner Blockliste für die .htaccess. Die neueste Version seiner Firewall, die 6G, ist ein Manifest der Sicherheit und wird gerne durch einige WordPress-Security-Plugins kopiert, weil sie so effektiv ist. Sie schützt unter anderem vor Cross-Site-Scripting und Schadcode-Implementierung über die Erweiterungen von URLs. Hackversuche werden trotz des minimalen Codes wirkungsvoll unterbunden und der Code arbeitet sehr effektiv.

Ein Klick öffnet die komplette Datei bei GitHub
6G-Firewall-Blacklist

Teil 4: Wichtige Sicherheitseinstellungen für WordPress

Die allgemeine Beliebtheit des Content-Management-Systems WordPress ist leider der Grund dafür, dass es sich immer öfter den Hackversuchen böswilliger Mitmenschen ausgesetzt sieht. Mit einigen Zeilen Code in der .htaccess kann man dem vorbeugen. Kommt dann noch eine Absicherung des Administrator-Zugangs der Website hinzu, kann man die Site als sicher ansehen, wenn man die Basics wie das rechtzeitige Update von WordPress, Theme und Plugins beherrscht.

Wie man den Admin-Zugang einer WordPress-Website per .htaccess und .htpasswd wirkungsvoll absichert, haben wir bereits beschrieben. Ebenfalls wird die potenziell unsichere XML-RPC-Schnittstelle von WordPress mit diesem Code völlig abgeschaltet. Wer die Schnittstelle nutzen möchte, weil er zum Beispiel mit der neuen WordPress-Desktop-App arbeitet, muss den Bereich des Codes auskommentieren. Das geschieht mit einer vorgesetzten Raute (#) pro Code-Zeile. Die Absicherung des Adminbereichs ist bereits vorbereitet, wenn du diese Form der Sicherheit nicht nutzen möchtest, dann kommentiere diesen Bereich aus.

Ein Klick öffnet die komplette Datei bei GitHub
Einstellungen in der htaccess für die Sicherheit von WordPress

Download der kompletten .htaccess Datei

Die komplette .htaccess Datei kann bei GitHub heruntergeladen werden.

Fazit

Mit dieser .htaccess Datei sind wir schon ziemlich nahe am Optimum. Die Datei ist eine hervorragende Grundlage, in der nur noch einige kleine, seitenspezifische Details ergänzt werden müssen (vermutlich). Mir und meiner Website leistet diese Datei sehr gute Dienste, und, ich hoffe stark, dir auch. Die Datei ist zudem so aufgebaut, dass es keine nervigen Probleme mehr bei Google Page Speed Insights gibt. Falls jemand von euch der Meinung ist, es gäbe da noch Verbesserungsbedarf, dann schreibe er/sie bitte einen Kommentar. Auch ich lerne gerne noch dazu :-)

Links zum Thema:

(dpe)

Andreas Hecht

Andreas Hecht

entwickelt WordPress-Websites und bietet dir einen Website Sicherheit Service und einen Performance Service für deine Website. Außerdem ist er Spezialist für Onpage SEO und bringt Deine Website in die Top-Suchergebnisse von Google. Auf seinem Blog schreibt er über WordPress, SEO und Content SEO.
Dr. Webs exklusiver Newsletter
Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.

34 Kommentare

  1. Sehr Cool, vielen Dank!

    #Full Path Disclosure abschalten – unterdrueckt die Anzeige des vollstaendigen Fehlerpfads
    php_flag display_errors Off

    Erzeugt bei mir einen Server Internal Error, nutze 1und1 WordPress

    • Hallo Sven,

      Full Path Disclosure scheint nicht bei jedem Hoster zu funktionieren. Lösche den Teil einfach heraus.

      • done, hat nur eine weile gedauert bis ich es gefunden habe xD.
        Ein kleines Problem habe ich noch, die .htpasswd erstellung hat wunderbar geklappt.
        allerdings ist die zusätzliche abfrage ein wenig wunderlich.
        Es kommt nur noch die Zusatzabfrage und dann bleibt der Browser weiß, und auch nur wenn ich wp-login.php eingebe ohne php kommt nicht mal die abfrage.
        Wenn ich die Seite dann neu lade bin ich bereits Eingeloggt *confused*
        Dazu vielleicht noch eine Idee ?
        Beste Grüße
        Sven

      • Hi Sven,

        dann stimmt irgendetwas mit der Konfiguration der Dateien oder Deinem WP nicht.

  2. Hallo,

    wenn meine WordPressinstallation in einem Unterverzeichnis liegt, z.B. /wp, lege ich die .htaccess dann dort rein oder hier hin: / (und dann zusätzlich auch nochmal in /wp?)

    Ich habe noch eine andere Software installiert, z.B. /forumetc und frage hier nach, ob die .htaccess Probleme macht, wenn sie im / liegt.

    Und kann ich irgendwie testen, ob die .htaccess auch funktioniert?

    lieben dank euch

    • Hallo Marc,

      die .htaccess muss immer in das Rootverzeichnis der WordPress-Installation. Also dahin, wo die Ordner wp-content, wp-admin, wp-includes liegen. Wenn eine Ebene höher dann ein weiterer Ordner /forumtec mit einer anderen .htaccess liegt, hat das keine Auswirkungen.

  3. Hallo Andreas,

    besten Dank für die ausführliche Anleitung. Ich kann mich dem Tenor nur anschließen. Insbesondere durch Komprimierung habe ich bereits sehr gute Ergebnisse erreicht. Großartig finde ich die Tipps zur Sicherheit, da ich es bislang vermieden habe, irgendwelche ominösen Plugins hierfür zu installieren.

    Bei der Aufstellung der „common files“ fehlt das Format .svg

    LG Arne

  4. Erst einmal vielen Dank für diese super Hilfe! Wenn ich alles so einbinde (inklusive den Verbesserungen von Daniel) dann bekomme ich auf meinem Startseiten-Verzeichnis den Fehler „Forbidden 403 Error, Apache Server at (www.meinedomain.de) Port 80“.

    Ich musste heute auch in meinem Router (Easybox 803A) Ports freigeben für die PS4 Verbindung. Darunter war auch der Port 80. Hängt das zufällig miteinander zusammen?

    Über eine Antwort wäre ich sehr dankbar! =)

    (Sorry für den Doppelpost – hatte die Email-Benachrichtigung nicht angehakt. Erster Post kann gelöscht werden.)

  5. Vielen Dank für diesen tollen Tipp!
    GoogleSpeedCheck von 72 auf !!!92!!!
    Habe nur ein Problem: Meine Site ist über https erreichbar. Bin ich auf der Site und gebe http ein, dann wird die auch unter http geladen und klicke ich auf Aktualisieren, wird die Seite mit http und ohne Bilder geladen.
    Wie erzwinge ich https?

  6. Hallo, vielen Dank für die Datei!

    Funktioniert bei mir bis auf ein kleines Problem sehr gut.

    Vor allem beim „Chrome“ Browser ist mir aufgefallen, dass aktualisierte Seiten tagelang nur aus dem Browsercache angezeigt werden. Nur nach manuellem neuladen wird die Seite aktualisiert. Das ist für Seiten die täglich geändert werden natürlich nicht sinnvoll.
    In der Firebugkonsole ist mir aufgefallen, dass bei „Last-Modified“ als Datum „Thu, 01 Jan 1970 00:00:00 GMT“ steht.
    Gibt es eine Lösung mit der das richtige Änderungsdatum ausgelesen und vom Browser für die Seitenanzeige genutzt wird?

    Als Laie finde ich keine Lösung, und ich weiss auch nicht, ob es mit der .htaccess Datei zusammenhängt oder andere Gründe hat.

    Für Tipps wäre ich dankbar.

    Mit freundlichen Grüßen
    Eugen

  7. Hallo,

    ich bin relativer WordPress Anfänger und technisch nicht wirklich versiert :-). Deshalb meine Fragen:
    1. Kann ich wirklich eins zu eins den Code deiner htaccess kopieren und meine aktuelle Datei damit ersetzen und alles funktioniert sofort einwandfrei? Oder ist das als Anfänger eventuell zu gefährlich?
    2. Kommt sich diese htaccess mit irgendeinem Cache Plugin in die Quere? (WP Rocket, Super Cache) oder kann man problemlos z.B. neben WP Rocket diese htaccess Datei benutzen?
    3. Würde mir diese htaccess im Punkto Pagespeed überhaupt nochmal einen Schub nach vorne bringen, wenn ich bereits ein Caching Plugin benutze?

    Gruß
    Julian

    • Du musst in Zeile 301 den Pfad zur Passwortdatei eingeben und in Zeile 311 Deine Domain.
      Sichere Diene Site und Deine Datenbank, dann probiere die htaccess einfach aus. Bei mir hat sie mich bei GoogleSpeedCheck von 72 auf 92 gebracht.

  8. Ein Fehler ist mir aufgefallen, Zeile 137:
    Header append Vary User-Agent env=!dont-vary

    Da sollte besser so aussehen:

    Header append Vary User-Agent env=!dont-vary

    Außerdem hab ich beim Rewrite in Zeile 311 nicht nur meine Domain eingesetzt, sondern aus https:// auch https?:// gemacht, damit die Seite auch ohne SSL funktioniert (je nach Bedarf sollte man hier prüfen, was Sinn macht – wenn https immer verfügbar ist, macht es natürlich Sinn, das auch zu erzwingen).

    Zudem hab ich es mir für Apache 2.4 und die neuen Zugriffsbeschränkungen angepasst. Das geht in den -Direktiven jeweils, indem
    Order Deny,Allow
    Deny from all
    ersetzt wird durch
    Require all denied
    (SatisfyAll entfällt, wo es vorher vorhanden war).

    Etwas lästiger dagegen ist es mit den Firewall-Regeln, da ja die beiden letzten – 6G:[USER AGENTS] und 6G:[BAD IPS] – beide jeweils Einschränkungen enthalten. Mehrere Requires innerhalb desselben Gültigkeitsbereichs führen aber leider dazu, dass implizit ein außen herum gestellt wird, so dass es bereits genügt, nur eine der beiden Regeln zu bestehen (was im Falle der Bad IPs fast immer der Fall ist). Daher muss man beide in einem zusammenfassen:

    # 6G:[USER AGENTS]

    SetEnvIfNoCase User-Agent ([a-z0-9]{2000}) bad_bot
    SetEnvIfNoCase User-Agent (archive.org|binlar|casper|checkpriv|choppy|clshttp|cmsworld|diavol|dotbot|extract|feedfinder|flicky|g00g1e|harvest|heritrix|httrack|kmccrew|loader|miner|nikto|nutch|planetwork|postrank|purebot|pycurl|python|seekerspider|siclab|skygrid|sqlmap|sucker|turnit|vikspider|winhttp|xxxyy|youda|zmeu|zune) bad_bot

    Require not env bad_bot

    # 6G:[BAD IPS]

    # uncomment/edit/repeat next line to block IPs
    # Require not ip 123.456.789

    Require all granted

    Zu guter Letzt: Nicht angepasst habe ich den Schutz des Admin-Bereichs, das dürfte aber vermutlich ohne Anpassung weiterhin funktionieren (auch ohne mod_access_compat).

    • Sorry, da alles in HTML-Tags automatisch rausgefiltert wird, macht meine Antwort so wenig Sinn…
      Hab meine angepasste Datei nun hier hochgeladen:
      https://gist.github.com/anonymous/d1afc3513997233c168b

      Zeile 137 ist bei mir 137-139, d.h. ich hab die Bedingung außen herum eingefügt.
      Die angepassten 6G-Regeln finden sich ab Zeile 218.
      Die angepassten Zugriffsbeschränkungen innerhalb der Files-Direktiven (deny auf verschiedene Dateien) sind entsprechend auch drin.

  9. Netter Artikel – leider nicht zu Ende geführt.
    Eine Verlinkung auf die Datei hätte so wohl auch genügt.. :(.
    Ich hätte mir da lieber genauere Erklärungen gewünscht, Zeile für Zeile.
    Manche Sachen erkennt man ja auf Anhieb, aber bevor ich blind links „irgendeine“ htaccess aktiviere,
    würde ich doch gerne wissen was die einzelnen RegEx Matches z.B. wirklich matches – ohne dass ich und andere jetzt jeder einzeln die Zeilen nachforschen.

  10. Hi, erstmal danke das du diese super arbeit mit uns teilst ;-)

    Ich musste folgende Einstellung deaktivieren das die Webseite richtig dargestellt wird:

    # 6G:[REQUEST STRINGS]

    RedirectMatch 403 (?i)([a-z0-9]{2000})
    RedirectMatch 403 (?i)(https?|ftp|php):/
    RedirectMatch 403 (?i)(base64_encode)(.*)(\()
    RedirectMatch 403 (?i)(=\\\’|=\\%27|/\\\’/?)\.
    RedirectMatch 403 (?i)/(\$(\&)?|\*|\“|\.|,|&|&?)/?$
    RedirectMatch 403 (?i)(\{0\}|\(/\(|\.\.\.|\+\+\+|\\\“\\\“)
    # RedirectMatch 403 (?i)(~|`||:|;|,|%|\\|\s|\{|\}|\[|\]|\|) <—

  11. Hallo,
    ist diese .htaccess für alle Webseiten nutzbar oder ist diese hier speziell auf WordPress abgestimmt?
    Mit freundlichen Grüßen
    André Wiedemann

    • Hallo André,

      die Datei kann auch für andere Websites genutzt werden, den Teil mit WordPress musst du dann löschen. Da die Datei gut kommentiert ist, solltest du ersehen können, was für WP ist und was nicht.

  12. Schöne Zusammenstellung. Auch bei reinen HTML-Projekten stellenweise sehr nützlich.

  13. Hallo Andreas,
    leider habe ich einen Server mit Nginx, da greift die normale .htaccess nicht, und die Einträge müssen verändert werden.
    Es wäre toll, wenn es Deine .htaccess für Nginx angepasst gäbe…

    • Hi Regina,

      sorry, ich habe von Nginx noch keine Ahnung. Allerdings werde ich mich in den Bereich nochmal irgendwann einarbeiten. Ich bitte also um Geduld.

  14. Einige schöne Sache bei, vor allem der Abschnitt von Jeff Starr.
    Stimmt schon, der Server rennt natürlich wie verrückt, wenn man das alles noch einmal aus der .htaccess raus und in die vHost config einträgt. Aber das ist bei dem ganzen shared webhosting Kram nicht möglich.

  15. Wer seine Webseite in Bezug auf Sicherheit überprüfen möchte, kann das hier tuen:

    https://securityheaders.io

    Erschreckend wieviele Seiten, gerade auch bekannte, Hüstel, abschneiden. ;-))

    • Danke dir für den Link, den kannte ich noch nicht. Die Ergebnisse sind allerdings nicht wirklich alle so ganz korrekt. Die .htaccess scheint keinerlei Berücksichtigung zu finden…

      • Doch wird sie, ich habe mit der .htaccess auf einigen Seiten rumgespielt und mit https://securityheaders.io gecheckt. Das funktioniert hervorragend.

        Sehr gut sind auch die Erklärungen und eigentlich, wenn man das alles befolgt, in ein paar Minuten gegessen, wenn man nichts besonderes einstellen will/möchte/braucht.

  16. Klasse, die werde ich gleich mal einbauen!

  17. Danke für diese Mega-htaccess-Datei!
    Es sollte aber jedem bewusst sein, dass der Apache mit jedem Aufruf diese Datei parst. Ist es hier nicht besser (sofern man die Möglichkeit hat), die Einstellungen direkt in die Apache-Konfiguration zu schreiben?
    Bei einem Test mit den Daten hat mir ModPageSpeed einen Strich durch dir Rechnung gemacht. Sobald es aktiv ist, zerschießt es das ganze Layout. Ich habe jetzt nicht weiter nach gesehen, wollte nur mal meckern! 8-D

    • Nun, es kann nie schaden, wenn man einige Einstellungen in die Apache-Konfiguration zu schreiben. Da muss aber getestet werden, was dort läuft und was nicht. Die Firewall würde ich in der .htaccess drin lassen. Abgesehen davon, dass die vorgestellte .htaccess Datei immer noch ein Leichtgewicht ist und daher ruhig jedesmal aufgerufen werden kann. Das wird sie bei mir auch. Problematisch im Sinne des Layouts kann eigentlich nur der Hotlinking-Bereich sein. Wie in meinem ersten Kommenatar bereits geschrieben, muss man die eigene Domain dort eintragen. Dann werden auch Bilder angezeigt.

  18. Toller Artikel! Hatte schon einige der Snippets in place, aber doch noch Neues in deinem Artikel gefunden – herzlichen Dank dafür!

  19. Danke für diesen Artikel!

  20. Hey Andreas, das ist eine tolle .htaccess, eine meiner Seiten hat direkt einen Boost von 72 auf 94 Page Speed Score erhalten. Allerdings habe ich jetzt das Problem, dass nach dem Refresh sämtliche Bilder nicht angezeigt werden, weisst du da vielleicht Rat?

    • Danke Dir für die Rückmeldung! Da hat sich ein Fehler eingeschlichen. Im Bereich Hotlinking verbieten (der dritte Block von unten) musst Du Deine Domain eintragen, es steht noch meine drin. Danach sollte alles wieder perfekt laufen! Sorry…

Schreibe einen Kommentar

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

Kennst du schon unseren Newsletter?

Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.