{"id":5661,"date":"2026-10-14T15:18:07","date_gmt":"2026-10-14T13:18:07","guid":{"rendered":"https:\/\/wwwschutz.de\/blog\/?p=5661"},"modified":"2026-10-09T15:43:10","modified_gmt":"2026-10-09T13:43:10","slug":"security-header-einfach-erklaert-csp-und-hsts-verstaendlich-und-praxisnah","status":"publish","type":"post","link":"https:\/\/wwwschutz.de\/blog\/security-header-einfach-erklaert-csp-und-hsts-verstaendlich-und-praxisnah\/","title":{"rendered":"Security Header einfach erkl\u00e4rt: CSP und HSTS verst\u00e4ndlich und praxisnah"},"content":{"rendered":"\n

Eine Website kann technisch einwandfrei funktionieren, gut aussehen und trotzdem angreifbar sein. Viele Sicherheitsl\u00fccken im Web entstehen nicht durch exotische Hackertricks, sondern dadurch, dass Browser nicht genau wissen, was sie tun d\u00fcrfen und was nicht. Genau hier setzen Security Header an: kleine Zusatzinformationen, die Ihr Server mit jeder Antwort an den Browser schickt und die dessen Verhalten gezielt absichern.<\/em><\/p>\n\n\n\n

In diesem Artikel erfahren Sie, was Security-Header sind, wie die beiden wichtigsten Vertreter HSTS<\/strong> und CSP<\/strong> funktionieren und wie Sie beide Schritt f\u00fcr Schritt und ohne b\u00f6se \u00dcberraschungen einf\u00fchren. Dazu gibt es fertige Konfigurationsbeispiele f\u00fcr Nginx und Apache sowie eine Checkliste zum Abhaken.<\/p>\n\n\n\n

Das Wichtigste in K\u00fcrze<\/h2>\n\n\n\n
    \n
  • Security-Header<\/strong> sind HTTP-Antwortzeilen, die dem Browser Sicherheitsregeln f\u00fcr Ihre Seite mitgeben.<\/li>\n\n\n\n
  • HSTS<\/strong> zwingt den Browser dazu, Ihre Seite ausschlie\u00dflich verschl\u00fcsselt per HTTPS aufzurufen.<\/li>\n\n\n\n
  • CSP<\/strong> legt fest, welche Inhalte (Skripte, Bilder, Schriften, Frames) die Seite \u00fcberhaupt laden darf, und ist damit ein starker Schutz gegen Cross-Site-Scripting.<\/li>\n\n\n\n
  • Beide Header lassen sich mit wenigen Zeilen Serverkonfiguration einrichten, sollten aber schrittweise<\/strong> eingef\u00fchrt werden.<\/li>\n\n\n\n
  • Mit kostenlosen Online-Tests pr\u00fcfen Sie in Sekunden, ob Ihre Konfiguration greift.<\/li>\n<\/ul>\n\n\n\n

    Was sind Security Header \u00fcberhaupt?<\/h2>\n\n\n\n

    Wenn Ihr Browser eine Webseite aufruft, schickt der Server nicht nur den eigentlichen Inhalt (HTML, Bilder, Skripte), sondern vorab auch sogenannte HTTP-Header<\/strong>. Das sind Textzeilen mit Metainformationen, zum Beispiel \u00fcber den Inhaltstyp, die Dateigr\u00f6\u00dfe oder die Zwischenspeicherung.<\/p>\n\n\n\n

    Ein Teil dieser Header dient ausschlie\u00dflich der Sicherheit. Sie sind sozusagen die Hausordnung f\u00fcr den Browser:<\/p>\n\n\n\n

      \n
    • Darf diese Seite in einem fremden Rahmen (Frame) eingebettet werden?<\/li>\n\n\n\n
    • Von welchen Servern d\u00fcrfen Skripte nachgeladen werden?<\/li>\n\n\n\n
    • Muss die Verbindung immer verschl\u00fcsselt sein?<\/li>\n<\/ul>\n\n\n\n

      Der Browser h\u00e4lt sich an diese Regeln und blockiert alles, was dagegen verst\u00f6\u00dft. Der gro\u00dfe Vorteil: Sie m\u00fcssen daf\u00fcr keinen Programmcode \u00e4ndern<\/strong>. Die Header werden zentral in der Konfiguration des Webservers (oder eines vorgeschalteten Dienstes) gesetzt und gelten sofort f\u00fcr die gesamte Seite.<\/p>\n\n\n\n

      \"Ablauf:
      Der Server schickt die Security-Header mit jeder Antwort mit, der Browser setzt die enthaltenen Regeln anschlie\u00dfend durch<\/figcaption><\/figure>\n\n\n\n

      Ein Beispiel, wie so eine Antwort aussehen kann:<\/p>\n\n\n\n

      HTTP\/2 200\ncontent-type: text\/html; charset=UTF-8\nstrict-transport-security: max-age=31536000; includeSubDomains\ncontent-security-policy: default-src 'self'\nx-content-type-options: nosniff\n<\/code><\/pre>\n\n\n\n
      Die letzten drei Zeilen sind Security-Header. F\u00fcr den Besucher sind sie unsichtbar, f\u00fcr den Browser aber verbindlich.<\/p>\n\n\n\n
      HSTS: Immer verschl\u00fcsselt, ohne Ausnahme<\/h2>\n\n\n\n
      Das Problem, das HSTS l\u00f6st<\/h3>\n\n\n\n
      Auch wenn Ihre Seite ein g\u00fcltiges HTTPS-Zertifikat besitzt, bleibt eine Schwachstelle: Viele Besucher tippen nur it-logic.de<\/code> in die Adresszeile oder folgen einem alten Link mit http:\/\/<\/code>. Der Browser fragt dann zun\u00e4chst unverschl\u00fcsselt<\/strong> an, und erst die Antwort des Servers leitet auf HTTPS um.<\/p>\n\n\n\n
      In diesem kurzen Moment kann ein Angreifer, etwa in einem \u00f6ffentlichen WLAN, die Verbindung abfangen und manipulieren. Man spricht von einem sogenannten Downgrade-Angriff<\/strong> oder SSL-Stripping<\/strong>. Der Besucher bemerkt davon oft nichts.<\/p>\n\n\n\n
      Die L\u00f6sung: Strict-Transport-Security<\/h3>\n\n\n\n
      Mit dem Header Strict-Transport-Security<\/code> (kurz HSTS<\/strong>) teilt der Server dem Browser mit: \u201eF\u00fcr diese Domain gilt ab sofort ausschlie\u00dflich HTTPS. Merke dir das f\u00fcr eine bestimmte Zeit.\u201c<\/p>\n\n\n\n
      Der Browser speichert diese Information und stellt k\u00fcnftig selbstst\u00e4ndig jede http:\/\/<\/code>-Anfrage auf https:\/\/<\/code> um, noch bevor \u00fcberhaupt ein unverschl\u00fcsseltes Paket das Ger\u00e4t verl\u00e4sst.<\/p>\n\n\n\n
      Ein typischer Header sieht so aus:<\/p>\n\n\n\n
      Strict-Transport-Security: max-age=31536000; includeSubDomains\n<\/code><\/pre>\n\n\n\n
      \"Vergleich:
      Ohne HSTS kann die erste, unverschl\u00fcsselte Anfrage abgefangen werden. Mit HSTS stellt der Browser selbstst\u00e4ndig auf HTTPS um.<\/figcaption><\/figure>\n\n\n\n
      Die Bestandteile im Detail<\/h3>\n\n\n\n
        \n
      • max-age<\/strong> gibt in Sekunden an, wie lange sich der Browser die Regel merken soll. 31536000 Sekunden entsprechen einem Jahr. Bei jedem Seitenaufruf wird die Frist erneuert.<\/li>\n\n\n\n
      • includeSubDomains<\/strong> dehnt die Regel auf alle Subdomains aus, etwa shop.beispiel.de<\/code> oder mail.beispiel.de<\/code>.<\/li>\n\n\n\n
      • preload<\/strong> signalisiert, dass Sie die Domain in die HSTS-Preload-Liste der Browserhersteller aufnehmen lassen m\u00f6chten. Dann kennen Browser die Regel schon vor dem allerersten Besuch.<\/li>\n<\/ul>\n\n\n\n
        Wichtig zu wissen<\/h3>\n\n\n\n
          \n
        • HSTS wird vom Browser nur \u00fcber HTTPS<\/strong> akzeptiert. \u00dcber eine unverschl\u00fcsselte Verbindung gesendet, wird der Header ignoriert.<\/li>\n\n\n\n
        • Beim allerersten Besuch<\/strong> einer Domain kennt der Browser die Regel noch nicht. Dieses Restrisiko schlie\u00dft nur die Preload-Liste.<\/li>\n\n\n\n
        • Die Preload-Aufnahme setzt unter anderem voraus: ein g\u00fcltiges Zertifikat, eine Weiterleitung von HTTP auf HTTPS, includeSubDomains<\/code>, preload<\/code> und eine max-age<\/code> von mindestens einem Jahr. Ein Austrag aus der Liste dauert Monate. Gehen Sie diesen Schritt also nur dann, wenn wirklich alle<\/strong> Subdomains dauerhaft HTTPS-f\u00e4hig sind.<\/li>\n<\/ul>\n\n\n\n
          So f\u00fchren Sie HSTS sicher ein<\/h3>\n\n\n\n
          Ein zu aggressiver HSTS-Start ist einer der h\u00e4ufigsten Fehler. Wenn Sie includeSubDomains<\/code> setzen und eine vergessene Subdomain nur per HTTP erreichbar ist, wird sie f\u00fcr Besucher pl\u00f6tzlich unerreichbar. Gehen Sie deshalb stufenweise vor:<\/p>\n\n\n\n
            \n
          1. Stellen Sie sicher, dass die gesamte Seite inklusive aller Ressourcen \u00fcber HTTPS funktioniert und das Zertifikat automatisch erneuert wird.<\/li>\n\n\n\n
          2. Richten Sie eine dauerhafte Weiterleitung (301) von HTTP auf HTTPS ein.<\/li>\n\n\n\n
          3. Starten Sie mit einer kurzen Laufzeit, zum Beispiel max-age=300<\/code> (f\u00fcnf Minuten), und pr\u00fcfen Sie, ob alles funktioniert.<\/li>\n\n\n\n
          4. Erh\u00f6hen Sie schrittweise auf einen Tag, eine Woche, einen Monat und schlie\u00dflich ein Jahr.<\/li>\n\n\n\n
          5. Erg\u00e4nzen Sie includeSubDomains<\/code> erst, wenn Sie jede Subdomain gepr\u00fcft haben.<\/li>\n\n\n\n
          6. \u00dcberlegen Sie preload<\/code> ganz zuletzt und nur, wenn Sie die Folgen verstanden haben.<\/li>\n<\/ol>\n\n\n\n
            CSP: Die Inhaltsrichtlinie f\u00fcr Ihre Seite<\/h2>\n\n\n\n
            Das Problem, das CSP l\u00f6st<\/h3>\n\n\n\n
            Die h\u00e4ufigste Angriffsart auf Webseiten ist Cross-Site-Scripting (XSS)<\/strong>. Dabei schleust ein Angreifer eigenen JavaScript-Code in Ihre Seite ein, etwa \u00fcber ein Kommentarfeld, ein Suchfeld oder eine verwundbare Erweiterung. Der Browser kann nicht unterscheiden, ob ein Skript von Ihnen stammt oder von einem Angreifer, und f\u00fchrt beides aus.<\/p>\n\n\n\n
            Die Folgen reichen vom Diebstahl von Sitzungsdaten \u00fcber untergeschobene Formulare bis zum Mitschneiden von Eingaben.<\/p>\n\n\n\n
            Die L\u00f6sung: Content-Security-Policy<\/h3>\n\n\n\n
            Mit der Content Security Policy (CSP)<\/strong> erstellen Sie eine Positivliste: Sie legen fest, woher<\/strong> der Browser Inhalte laden und welche Aktionen er ausf\u00fchren darf. Alles, was nicht auf der Liste steht, wird blockiert. Selbst wenn ein Angreifer Code einschleusen kann, verweigert der Browser dessen Ausf\u00fchrung.<\/p>\n\n\n\n
            Ein einfaches Beispiel:<\/p>\n\n\n\n
            Content-Security-Policy: default-src 'self'; img-src 'self' https:\/\/cdn.beispiel.de; script-src 'self'\n<\/code><\/pre>\n\n\n\n
            \u00dcbersetzt hei\u00dft das: Standardm\u00e4\u00dfig darf alles nur von der eigenen Domain kommen. Bilder sind zus\u00e4tzlich vom CDN cdn.beispiel.de<\/code> erlaubt, Skripte ausschlie\u00dflich von der eigenen Domain.<\/p>\n\n\n\n
            \"Vergleich:
            Ohne CSP f\u00fchrt der Browser ein eingeschleustes Fremdskript aus. Mit CSP wird es blockiert, weil die Quelle nicht auf der Positivliste steht.<\/figcaption><\/figure>\n\n\n\n
            Die wichtigsten Direktiven<\/h3>\n\n\n\n
            Eine CSP besteht aus einzelnen Regeln, den Direktiven<\/strong>, getrennt durch Semikolons:<\/p>\n\n\n\n
              \n
            • default-src<\/strong>: die Grundregel f\u00fcr alle Inhaltstypen, f\u00fcr die keine eigene Direktive gesetzt ist.<\/li>\n\n\n\n
            • script-src<\/strong>: erlaubte Quellen f\u00fcr JavaScript. Die wichtigste Direktive f\u00fcr den XSS-Schutz.<\/li>\n\n\n\n
            • style-src<\/strong>: erlaubte Quellen f\u00fcr CSS.<\/li>\n\n\n\n
            • img-src<\/strong>: erlaubte Quellen f\u00fcr Bilder.<\/li>\n\n\n\n
            • font-src<\/strong>: erlaubte Quellen f\u00fcr Schriftarten.<\/li>\n\n\n\n
            • connect-src<\/strong>: erlaubte Ziele f\u00fcr Anfragen per JavaScript (zum Beispiel fetch<\/code> oder XMLHttpRequest<\/code>).<\/li>\n\n\n\n
            • frame-src<\/strong>: Quellen, die als eingebettete Frames erscheinen d\u00fcrfen, etwa ein YouTube-Video oder eine Karte.<\/li>\n\n\n\n
            • frame-ancestors<\/strong>: bestimmt, wer Ihre<\/strong> Seite einbetten darf. Das ist der moderne Ersatz f\u00fcr den \u00e4lteren Header X-Frame-Options<\/code> und sch\u00fctzt vor Clickjacking.<\/li>\n\n\n\n
            • form-action<\/strong>: erlaubte Ziele f\u00fcr Formulare.<\/li>\n\n\n\n
            • base-uri<\/strong>: schr\u00e4nkt das <base><\/code>-Element ein, \u00fcber das Angreifer sonst relative Links umbiegen k\u00f6nnten.<\/li>\n\n\n\n
            • object-src<\/strong>: Plug-in-Inhalte. Hier ist 'none'<\/code> fast immer die richtige Wahl.<\/li>\n\n\n\n
            • upgrade-insecure-requests<\/strong>: weist den Browser an, unsichere Ressourcen automatisch \u00fcber HTTPS anzufordern.<\/li>\n<\/ul>\n\n\n\n
              Gut zu wissen: frame-ancestors<\/code>, base-uri<\/code> und form-action<\/code> erben nicht<\/strong> von default-src<\/code>. Sie m\u00fcssen bei Bedarf immer ausdr\u00fccklich gesetzt werden.<\/p>\n\n\n\n
              Die wichtigsten Quellangaben<\/h3>\n\n\n\n
                \n
              • 'self'<\/code>: die eigene Domain (gleiches Protokoll, gleicher Host, gleicher Port).<\/li>\n\n\n\n
              • 'none'<\/code>: gar keine Quelle erlaubt.<\/li>\n\n\n\n
              • https:\/\/cdn.beispiel.de<\/code>: eine bestimmte Domain.<\/li>\n\n\n\n
              • https:<\/code>: jede beliebige HTTPS-Quelle (sehr gro\u00dfz\u00fcgig, nur im Notfall verwenden).<\/li>\n\n\n\n
              • data:<\/code>: Inhalte, die direkt in die Seite eingebettet sind, etwa kleine Bilder.<\/li>\n\n\n\n
              • 'unsafe-inline'<\/code>: erlaubt Inline-Skripte oder Inline-Styles. Bei script-src<\/code> hebelt das den XSS-Schutz weitgehend aus und sollte vermieden werden.<\/li>\n\n\n\n
              • 'unsafe-eval'<\/code>: erlaubt Code-Ausf\u00fchrung aus Zeichenketten (eval<\/code>). Ebenfalls riskant.<\/li>\n\n\n\n
              • 'nonce-\u2026'<\/code> und 'sha256-\u2026'<\/code>: erlauben gezielt einzelne Inline-Skripte (siehe unten).<\/li>\n<\/ul>\n\n\n\n
                Inline-Skripte sicher erlauben: Nonce und Hash<\/h3>\n\n\n\n
                Viele Seiten enthalten kleine Skripte direkt im HTML. Statt pauschal 'unsafe-inline'<\/code> zu erlauben, gibt es zwei saubere Wege:<\/p>\n\n\n\n
                Nonce:<\/strong> Der Server erzeugt bei jeder Anfrage eine zuf\u00e4llige, einmalig g\u00fcltige Zeichenfolge, tr\u00e4gt sie in den Header und in das erlaubte Skript ein:<\/p>\n\n\n\n
                Content-Security-Policy: script-src 'nonce-r4nd0mW3rt'\n<\/code><\/pre>\n\n\n\n
                <script nonce=\"r4nd0mW3rt\">\n  console.log(\"Dieses Skript ist ausdr\u00fccklich erlaubt\");\n<\/script>\n<\/code><\/pre>\n\n\n\n
                Ein Angreifer kennt den Wert nicht und kann dadurch keine eigenen Skripte ausf\u00fchren lassen. Wichtig: Der Wert muss pro Seitenaufruf neu und nicht erratbar sein.<\/p>\n\n\n\n
                Hash:<\/strong> Sie berechnen den SHA-256-Hash eines unver\u00e4nderlichen Skripts und tragen ihn in den Header ein. Der Browser vergleicht den Hash und f\u00fchrt das Skript nur bei \u00dcbereinstimmung aus. Das eignet sich f\u00fcr statische Seiten.<\/p>\n\n\n\n
                Die goldene Regel: erst beobachten, dann blockieren<\/h3>\n\n\n\n
                Eine CSP, die zu streng startet, kann Ihre Seite lahmlegen: Schriften fehlen, das Kontaktformular tut nichts mehr, eingebettete Karten bleiben leer. Daf\u00fcr gibt es den Report-Only-Modus<\/strong>:<\/p>\n\n\n\n
                Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint\n<\/code><\/pre>\n\n\n\n
                In diesem Modus blockiert der Browser nichts<\/strong>, meldet aber jeden Versto\u00df in der Entwicklerkonsole und optional an einen von Ihnen angegebenen Meldepunkt. So sehen Sie in Ruhe, was Ihre Richtlinie betreffen w\u00fcrde, bevor sie scharf geschaltet wird.<\/p>\n\n\n\n
                \"Kreislauf
                Die CSP-Einf\u00fchrung in f\u00fcnf Schritten. Erst im Report-Only-Modus beobachten, dann scharf schalten und nach jeder \u00c4nderung erneut pr\u00fcfen.<\/figcaption><\/figure>\n\n\n\n
                Schritt f\u00fcr Schritt zur eigenen CSP<\/h3>\n\n\n\n
                  \n
                1. Bestandsaufnahme:<\/strong> \u00d6ffnen Sie Ihre Seite im Browser mit den Entwicklertools (Reiter \u201eNetzwerk\u201c) und notieren Sie, von welchen Domains Skripte, Styles, Bilder, Schriften und Frames geladen werden.<\/li>\n\n\n\n
                2. Report-Only starten:<\/strong> Setzen Sie eine erste Richtlinie als Content-Security-Policy-Report-Only<\/code>.<\/li>\n\n\n\n
                3. Konsole auswerten:<\/strong> Jede Meldung zeigt, welche Quelle fehlt. Entscheiden Sie bewusst, ob diese Quelle wirklich erlaubt sein soll.<\/li>\n\n\n\n
                4. Inline-Code aufr\u00e4umen:<\/strong> Verschieben Sie Skripte und Styles wenn m\u00f6glich in eigene Dateien oder nutzen Sie Nonces.<\/li>\n\n\n\n
                5. Scharf schalten:<\/strong> Wenn die Konsole sauber bleibt, benennen Sie den Header in Content-Security-Policy<\/code> um.<\/li>\n\n\n\n
                6. Dauerhaft pflegen:<\/strong> Pr\u00fcfen Sie die Richtlinie nach jeder \u00c4nderung an Plug-ins, Themes, Trackern oder eingebetteten Diensten.<\/li>\n<\/ol>\n\n\n\n
                  Eine solide Ausgangsbasis f\u00fcr eine statische Seite k\u00f6nnte so aussehen:<\/p>\n\n\n\n
                  Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests\n<\/code><\/pre>\n\n\n\n
                  Besonderheiten bei WordPress<\/h3>\n\n\n\n
                  WordPress macht eine strenge CSP anspruchsvoll, weil Themes und Plug-ins h\u00e4ufig Inline-Skripte und Inline-Styles erzeugen. Praxistipps:<\/p>\n\n\n\n
                    \n
                  • Starten Sie unbedingt im Report-Only-Modus und testen Sie sowohl das Frontend als auch den Administrationsbereich.<\/li>\n\n\n\n
                  • Der Admin-Bereich und der Block-Editor ben\u00f6tigen oft gro\u00dfz\u00fcgigere Regeln als die \u00f6ffentliche Seite. Setzen Sie die CSP daher gegebenenfalls nur f\u00fcr das Frontend.<\/li>\n\n\n\n
                  • Externe Dienste wie Google Fonts, YouTube, Karten oder Statistik-Tools m\u00fcssen einzeln freigegeben werden. Aus Datenschutzsicht lohnt es sich ohnehin, Schriften lokal einzubinden.<\/li>\n\n\n\n
                  • Jedes neue Plug-in kann die Richtlinie wieder brechen. Planen Sie nach Updates einen kurzen Funktionstest ein.<\/li>\n<\/ul>\n\n\n\n
                    Weitere n\u00fctzliche Security Header im \u00dcberblick<\/h2>\n\n\n\n
                    CSP und HSTS sind die Schwergewichte, aber ein paar weitere Header sind mit minimalem Aufwand gesetzt und bringen echten Mehrwert:<\/p>\n\n\n\n
                      \n
                    • X-Content-Type-Options: nosniff<\/strong> verhindert, dass der Browser Dateitypen \u201eerr\u00e4t\u201c und dadurch harmlos wirkende Dateien als Skripte ausf\u00fchrt.<\/li>\n\n\n\n
                    • Referrer-Policy: strict-origin-when-cross-origin<\/strong> begrenzt, wie viel von der besuchten Adresse an externe Seiten weitergegeben wird. Gut f\u00fcr den Datenschutz.<\/li>\n\n\n\n
                    • Permissions-Policy<\/strong> schaltet Browserfunktionen wie Kamera, Mikrofon oder Standort f\u00fcr Ihre Seite ab, falls sie nicht ben\u00f6tigt werden. Beispiel: camera=(), microphone=(), geolocation=()<\/code>.<\/li>\n\n\n\n
                    • X-Frame-Options: SAMEORIGIN<\/strong> sch\u00fctzt vor Clickjacking. Moderne Browser nutzen daf\u00fcr frame-ancestors<\/code> in der CSP, der \u00e4ltere Header schadet aber als Erg\u00e4nzung nicht.<\/li>\n\n\n\n
                    • Cross-Origin-Opener-Policy<\/strong> und verwandte Header trennen Ihre Seite von fremden Fenstern ab. Das ist besonders f\u00fcr anspruchsvolle Anwendungen interessant.<\/li>\n<\/ul>\n\n\n\n
                      Der fr\u00fchere Header X-XSS-Protection<\/code> gilt als veraltet. Moderne Browser ignorieren ihn oder haben den zugeh\u00f6rigen Filter entfernt. Sie k\u00f6nnen ihn weglassen und stattdessen auf eine gute CSP setzen.<\/p>\n\n\n\n
                      Konfigurationsbeispiele<\/h2>\n\n\n\n
                      Nginx<\/h3>\n\n\n\n
                      Tragen Sie die Header im server<\/code>-Block Ihrer Seite ein:<\/p>\n\n\n\n
                      # Security-Header f\u00fcr die gesamte Seite\nadd_header Strict-Transport-Security \"max-age=31536000; includeSubDomains\" always;\nadd_header X-Content-Type-Options \"nosniff\" always;\nadd_header Referrer-Policy \"strict-origin-when-cross-origin\" always;\nadd_header Permissions-Policy \"camera=(), microphone=(), geolocation=()\" always;\nadd_header Content-Security-Policy \"default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'\" always;\n<\/code><\/pre>\n\n\n\n
                      Das Schl\u00fcsselwort always<\/code> sorgt daf\u00fcr, dass die Header auch bei Fehlerseiten (zum Beispiel 404) gesendet werden. Beachten Sie au\u00dferdem: In Nginx werden add_header<\/code>-Anweisungen aus einer h\u00f6heren Ebene nicht<\/strong> \u00fcbernommen, sobald auf einer tieferen Ebene (etwa in einem location<\/code>-Block) eigene add_header<\/code>-Zeilen stehen. Wiederholen Sie die Header dort bei Bedarf.<\/p>\n\n\n\n
                      Apache<\/h3>\n\n\n\n
                      Aktivieren Sie das Modul mod_headers<\/code> und erg\u00e4nzen Sie in der Konfiguration oder in der .htaccess<\/code>:<\/p>\n\n\n\n
                      # Security-Header f\u00fcr die gesamte Seite\nHeader always set Strict-Transport-Security \"max-age=31536000; includeSubDomains\"\nHeader always set X-Content-Type-Options \"nosniff\"\nHeader always set Referrer-Policy \"strict-origin-when-cross-origin\"\nHeader always set Permissions-Policy \"camera=(), microphone=(), geolocation=()\"\nHeader always set Content-Security-Policy \"default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'\"\n<\/code><\/pre>\n\n\n\n
                      Hinter einem Proxy oder CDN<\/h3>\n\n\n\n
                      Setzen Sie die Header m\u00f6glichst an einer<\/strong> Stelle. Wenn sowohl der Ursprungsserver als auch ein vorgeschalteter Dienst Header erg\u00e4nzen, entstehen Dubletten oder widerspr\u00fcchliche Werte. Bei doppelten CSP-Headern gilt zudem: Der Browser wendet alle<\/strong> Richtlinien an, und die jeweils strengere setzt sich durch.<\/p>\n\n\n\n
                      So pr\u00fcfen Sie Ihre Konfiguration<\/h2>\n\n\n\n
                      Nach der Einrichtung sollten Sie das Ergebnis immer kontrollieren:<\/p>\n\n\n\n
                        \n
                      • Kommandozeile:<\/strong> Mit curl -I https:\/\/ihre-domain.de<\/code> sehen Sie alle Antwort-Header auf einen Blick.<\/li>\n\n\n\n
                      • Entwicklertools des Browsers:<\/strong> Im Reiter \u201eNetzwerk\u201c finden Sie die Header der Antwort, in der \u201eKonsole\u201c die Meldungen zu CSP-Verst\u00f6\u00dfen.<\/li>\n\n\n\n
                      • Online-Tests:<\/strong> Dienste wie securityheaders.com<\/em> oder das Mozilla Observatory<\/em> bewerten Ihre Header automatisch und geben konkrete Verbesserungsvorschl\u00e4ge. F\u00fcr HSTS-Preload gibt es zudem eine offizielle Pr\u00fcfseite unter hstspreload.org<\/em>.<\/li>\n<\/ul>\n\n\n\n
                        H\u00e4ufige Fehler und wie Sie sie vermeiden<\/h2>\n\n\n\n
                          \n
                        • HSTS zu fr\u00fch mit langer Laufzeit:<\/strong> Beginnen Sie mit kurzen Zeiten und steigern Sie sich. Ein Fehler l\u00e4sst sich sonst \u00fcber Monate nicht zur\u00fccknehmen.<\/li>\n\n\n\n
                        • 'unsafe-inline'<\/code> bei script-src:<\/strong> Das f\u00fchlt sich bequem an, entwertet den XSS-Schutz der CSP aber stark. Nutzen Sie stattdessen Nonces oder Hashes.<\/li>\n\n\n\n
                        • Zu gro\u00dfz\u00fcgige Platzhalter:<\/strong> Eine Angabe wie https:<\/code> oder *<\/code> erlaubt nahezu alles und sch\u00fctzt kaum noch.<\/li>\n\n\n\n
                        • CSP ungetestet scharf geschaltet:<\/strong> Immer zuerst im Report-Only-Modus beobachten.<\/li>\n\n\n\n
                        • Header nur auf der Startseite:<\/strong> Stellen Sie sicher, dass die Regeln f\u00fcr alle Pfade, Fehlerseiten und Subdomains gelten.<\/li>\n\n\n\n
                        • Vergessene Anpassung nach \u00c4nderungen:<\/strong> Neue Plug-ins, Tracker oder eingebettete Dienste ben\u00f6tigen oft neue Freigaben in der CSP.<\/li>\n<\/ul>\n\n\n\n
                          Checkliste zum Abhaken<\/h2>\n\n\n\n
                            \n
                          • Die gesamte Seite ist \u00fcber HTTPS erreichbar, das Zertifikat erneuert sich automatisch.<\/li>\n\n\n\n
                          • HTTP wird dauerhaft auf HTTPS umgeleitet.<\/li>\n\n\n\n
                          • HSTS ist gesetzt und wurde schrittweise auf mindestens ein Jahr erh\u00f6ht.<\/li>\n\n\n\n
                          • includeSubDomains<\/code> wird nur verwendet, wenn alle Subdomains HTTPS unterst\u00fctzen.<\/li>\n\n\n\n
                          • Eine CSP wurde zuerst im Report-Only-Modus getestet und anschlie\u00dfend aktiviert.<\/li>\n\n\n\n
                          • F\u00fcr Skripte wird kein pauschales 'unsafe-inline'<\/code> verwendet.<\/li>\n\n\n\n
                          • object-src 'none'<\/code>, base-uri<\/code> und frame-ancestors<\/code> sind gesetzt.<\/li>\n\n\n\n
                          • X-Content-Type-Options<\/code>, Referrer-Policy<\/code> und Permissions-Policy<\/code> sind erg\u00e4nzt.<\/li>\n\n\n\n
                          • Das Ergebnis wurde mit curl und einem Online-Test \u00fcberpr\u00fcft.<\/li>\n\n\n\n
                          • Nach jeder gr\u00f6\u00dferen \u00c4nderung an der Seite wird die Konfiguration erneut getestet.<\/li>\n<\/ul>\n\n\n\n
                            H\u00e4ufige Fragen<\/h2>\n\n\n\n
                            Ersetzen Security-Header andere Sicherheitsma\u00dfnahmen?<\/strong> Nein. Sie sind eine zus\u00e4tzliche Schutzschicht. Aktuelle Software, sichere Passw\u00f6rter, saubere Eingabepr\u00fcfung und regelm\u00e4\u00dfige Updates bleiben unverzichtbar. Security-Header begrenzen den Schaden, falls doch einmal etwas durchrutscht.<\/p>\n\n\n\n
                            Verlangsamen Security-Header meine Seite?<\/strong> Nein. Die Header sind nur wenige Bytes gro\u00df und haben praktisch keinen Einfluss auf die Ladezeit. Eine saubere CSP kann sogar helfen, unn\u00f6tige Drittanbieter-Ressourcen aufzudecken.<\/p>\n\n\n\n
                            Brauche ich HSTS, wenn ich bereits auf HTTPS umleite?<\/strong> Ja, es lohnt sich. Die Weiterleitung sch\u00fctzt nur, wenn die erste unverschl\u00fcsselte Anfrage nicht abgefangen wird. HSTS schlie\u00dft genau diese L\u00fccke f\u00fcr wiederkehrende Besucher.<\/p>\n\n\n\n