// stack · security
siteway liefert jede Seite über TLS aus und setzt einen festen Satz HTTP Security Header — Content-Security-Policy, HSTS, X-Content-Type-Options. Dazu bauen wir trackingfrei: lokale Schriften, lokale Assets, kein Fremd-CDN beim Seitenaufruf. So entsteht Absicherung, die zugleich Datenschutz ist. Die Prüfung liegt daneben — als Security-Audit und Datenschutz-Audit.
// definition
HTTP Security Header sind Anweisungen, die der Webserver bei jedem Seitenaufruf
im Antwort-Header an den Browser mitschickt. Sie schalten Schutzfunktionen scharf, die der Browser
von sich aus nicht nutzt. Eine Content-Security-Policy legt fest, welche Quellen laden dürfen,
HSTS erzwingt HTTPS, X-Content-Type-Options: nosniff stoppt das MIME-Raten.
Der Punkt ist die Richtung: Nicht der Server wird geschützt, sondern der Browser des Besuchers wird angewiesen, sich defensiv zu verhalten. Fehlt der Header, bleibt die Funktion aus — mit ihm wehrt der Browser Cross-Site-Scripting, Clickjacking oder eine erschlichene HTTP-Verbindung selbst ab. Header kosten kein Kilobyte Ladezeit und sind trotzdem eine der wirksamsten Zeilen, die eine Seite ausliefern kann.
// praxis
default an, nicht nachgerüstet
Absicherung ist bei uns kein Punkt auf einer Checkliste am Ende, sondern eine Weichenstellung am Anfang. Jedes Projekt startet mit demselben Grundstock: TLS erzwungen, ein fester Satz Security Header, und eine Auslieferung, die keine fremden Hosts kennt. Das ist kein Extra, das man dazubucht — es ist die Standardeinstellung, von der wir nur mit gutem Grund abweichen.
Die entscheidende Architektur-Entscheidung fällt bei den Assets. Weil wir ohne
Fremd-CDN bauen — Schriften, Icons, Skripte und Bilder liegen lokal auf deiner Domain —, bleibt die
Content-Security-Policy eng. Statt einer offenen Regel, die halb offene Türen
lässt, reicht oft default-src 'self' als Basis. Eine enge CSP ist
nicht nur sicherer, sie ist auch wartbar: Es gibt keine wandernde Liste externer Dienste, die man pflegen
und im Blick behalten müsste.
Ausgerollt werden die Header über die Deployment-Pipeline, versioniert im Git — nicht von Hand am Server nachgezogen. So ist dokumentiert, welche Regel warum gilt, und Staging und Live tragen denselben Schutz. Bei TYPO3, WordPress und Statamic setzen wir die Header auf Server- und Anwendungsebene, damit auch dynamische Antworten sie tragen.
// header · 6 bausteine
jeder wehrt einen angriff
Sechs Zeilen, sechs Schutzwirkungen. Jeder Header adressiert eine konkrete Angriffsfläche — und greift nur, weil die Seite ohnehin schlank und ohne fremde Hosts gebaut ist.
// h-01verschlüsselung
Jede Verbindung verschlüsselt, TLS 1.3 als Ziel. HTTP-Aufrufe werden umgeleitet, damit nichts unverschlüsselt über die Leitung geht — die Grundlage, auf der alle anderen Header überhaupt Sinn ergeben.
gegen: mitlesen · mitm
// h-02quellen-whitelist
Die Whitelist erlaubter Quellen für Skripte, Styles, Bilder und Schriften. Was nicht auf der Liste steht, blockiert der Browser. Bei uns bleibt sie eng, weil keine Fremd-Hosts nötig sind.
gegen: xss · injection
// h-03https-zwang
HSTS weist den Browser an, die Domain nur noch über HTTPS aufzurufen — auch bei getipptem http:// oder altem Link. Auf Wunsch mit Anmeldung zur Preload-Liste, damit der Schutz schon vor dem ersten Kontakt greift.
gegen: ssl-stripping
// h-04mime-raten
Mit nosniff hört der Browser auf, den Dateityp selbst zu erraten. Eine als Bild getarnte Skript-Datei wird dann nicht doch als Code ausgeführt — eine Zeile, die eine ganze Angriffsklasse schließt.
gegen: mime-sniffing
// h-05einbettung
Wer die Seite in einen fremden iFrame laden darf, regelt frame-ancestors in der CSP — der moderne Nachfolger von X-Frame-Options. Standardmäßig verbieten wir Fremd-Einbettung ganz.
gegen: clickjacking
// h-06datensparsamkeit
Legt fest, wie viel über die Herkunft eines Klicks nach außen geht. Wir setzen sie sparsam, damit keine vollen URLs mit womöglich sensiblen Parametern an Ziel-Server weitergereicht werden — Datenschutz per Header.
gegen: daten-leak
// haltung
eine entscheidung, zwei ziele
Die meisten Ratgeber behandeln Sicherheit und Datenschutz als zwei Baustellen. In der Umsetzung sind es oft dieselben Handgriffe. Wer ohne Fremd-CDN baut, härtet die Seite ab und hält Besucherdaten im Haus — zwei Ziele aus einer Entscheidung.
Das klassische Beispiel sind Schriften. Bindet eine Seite Google Fonts direkt vom Google-Server ein, lädt der Browser des Besuchers die Datei dort — und überträgt dabei dessen IP-Adresse an einen Dritten, ohne Einwilligung. Genau das hat 2022 eine Abmahnwelle ausgelöst. Wir hosten Schriften und alle Assets deshalb lokal auf deiner Domain. Beim Seitenaufruf fließt kein Byte an Fremd-Hosts, und es gibt nichts, wofür ein Cookie-Banner um Einwilligung bitten müsste.
Das ist gelebte Datensparsamkeit: Was nicht erhoben wird, kann nicht abfließen und nicht abgemahnt werden. Wo Tracking, Consent oder Analyse gewünscht sind, bauen wir sie bewusst und datenschutzkonform ein — als Entscheidung, nicht als eingeschleppte Standard-Last eines fremden Skripts.
// beleg
was wir bauen, fahren wir selbst
Diese Seite ist das Muster: ausgeliefert über TLS, mit gesetzten Security Headern, ohne Fremd-CDN und ohne Tracker beim Aufruf. Die Schriften, die du gerade liest, kommen von unserer Domain — nicht von Google. Dass das nicht zulasten der Geschwindigkeit geht, zeigt der PageSpeed-Wert der Startseite: mobil 100/100/100/100. Schlanke, fremdfreie Auslieferung ist kein Kompromiss, sondern Voraussetzung für beides — Tempo und Datenschutz.
// faq
HTTP Security Header sind Anweisungen, die der Webserver bei jedem Seitenaufruf im Antwort-Header an den Browser mitschickt. Sie schalten Schutzfunktionen scharf, die der Browser sonst nicht nutzt: Eine Content-Security-Policy legt fest, welche Quellen laden dürfen, HSTS erzwingt HTTPS, X-Content-Type-Options: nosniff stoppt das MIME-Raten. Ohne die Header bleiben diese Funktionen aus — mit ihnen wehrt der Browser Angriffe wie Cross-Site-Scripting oder Clickjacking selbst ab.
siteway liefert jede Seite über TLS aus und setzt einen festen Grundstock: Content-Security-Policy, Strict-Transport-Security (HSTS), X-Content-Type-Options: nosniff, X-Frame-Options beziehungsweise frame-ancestors in der CSP und eine sparsame Referrer-Policy. Die CSP schneiden wir auf das jeweilige Projekt zu, statt eine offene Blanko-Regel zu setzen — geprüft wird das Ergebnis danach im Security-Audit.
Die Content-Security-Policy ist eine Whitelist: Sie sagt dem Browser, aus welchen Quellen Skripte, Styles, Bilder und Schriften geladen werden dürfen. Alles, was nicht auf der Liste steht, blockiert der Browser. Damit läuft eingeschleustes Fremd-Skript aus einer Cross-Site-Scripting-Lücke gar nicht erst an. Weil siteway ohne Fremd-CDN und ohne Tracker baut, bleibt die Policy eng — meist reicht die eigene Domain als erlaubte Quelle.
HSTS steht für HTTP Strict Transport Security. Der Header weist den Browser an, die Seite ausschließlich über HTTPS aufzurufen — auch dann, wenn jemand http:// tippt oder einem alten Link folgt. Das schließt die Lücke zwischen erstem Klick und Weiterleitung, über die ein Angreifer sonst mitlesen könnte. Auf Wunsch melden wir die Domain für die HSTS-Preload-Liste an, damit der Schutz schon vor dem ersten Kontakt greift.
Bindet eine Seite Google Fonts oder ein anderes Fremd-CDN direkt ein, lädt der Browser des Besuchers die Datei beim Drittanbieter — und überträgt dabei dessen IP-Adresse, ohne Einwilligung. Genau das hat 2022 zu einer Abmahnwelle geführt. siteway hostet Schriften und Assets deshalb lokal auf der eigenen Domain. Beim Seitenaufruf fließen keine Besucherdaten an Dritte, und die CSP kann eng bleiben. Sicherheit und Datenschutz fallen so in einer Entscheidung zusammen.
Direkt sind Security-Header kein Ranking-Faktor. Indirekt zahlen sie ein: HTTPS ist ein bestätigtes Signal, und eine trackingfreie, ohne Fremd-CDN gebaute Seite lädt schneller — was auf die Core Web Vitals einzahlt. Wichtiger ist der Vertrauens- und Rechtssicherheits-Gewinn: keine Mixed-Content-Warnung, keine Third-Party-Requests, die ein Cookie-Banner erzwingen. Das ist saubere Technik, die nebenbei die Sichtbarkeit stützt.
Ja. Das Setzen der Header ist Teil jedes Projekts, die Prüfung eine eigene Leistung. Im Security-Audit testen wir die Header gegen den Ist-Stand und decken Konfigurationslücken auf, im Datenschutz-Audit prüfen wir Tracking, Third-Party-Requests und Consent. Wer nur wissen will, wie die eigene Seite dasteht, bucht das Audit einzeln — der Umbau folgt daraus, ist aber getrennt.
// womit das zusammenhängt
prüfen & ausrollen
// leistung · prüfung
Die Header und die Absicherung deiner bestehenden Seite prüfen lassen — mit Befund und Prioritätenliste. Der buchbare Gegenpart zu dieser Technik.
zur leistung →
// leistung · prüfung
Tracking, Third-Party-Requests und Consent auf den Prüfstand: Wo fließen Daten ab, wo fehlt eine Einwilligung? Einzeln buchbar.
zur leistung →
// stack · deployment
Wie die Header ausgerollt werden: versioniert im Git, über eine Pipeline mit GitHub Actions, mit getrennter Staging- und Live-Umgebung.
zur technologie →
// Deine Seite sicher und trackingfrei bauen?
Projekt anfragen