image² Web Security Headers

Status: Aktiv im Einsatz
Typ: Custom Plugin (Agenturstandard)
Zweck: Serverseitiges Setzen stabiler Security-Header über .htaccess
Kompatibilität: Apache-Server (mod_headers), caching-kompatibel

Ziel des Plugins

Das Plugin setzt sicherheitsrelevante HTTP-Header direkt über die .htaccess-Datei.

Dadurch:

  • wirken die Header unabhängig vom Theme
  • wirken sie vor WordPress
  • bleiben sie auch bei Caching-Plugins stabil
  • greifen sie auch bei statischen Dateien

Es handelt sich bewusst um eine minimale, stabile Agenturversion ohne Overhead.

Gesetzte Header

Das Plugin setzt folgende Header:

  • Strict-Transport-Security
    Erzwingt HTTPS über 12 Monate.
  • X-Content-Type-Options: nosniff
    Verhindert MIME-Type-Sniffing.
  • X-Frame-Options: SAMEORIGIN
    Schutz vor Clickjacking.
  • X-XSS-Protection: 1; mode=block
    Legacy-XSS-Filter für ältere Browser.
  • Referrer-Policy: strict-origin-when-cross-origin
    Datenschutzfreundliche Referer-Weitergabe.
  • Permissions-Policy
    Deaktiviert unnötige Browser-APIs (Kamera, Mikrofon, etc.).

Warum keine Content Security Policy (CSP)?

Die CSP wurde bewusst nicht integriert.

Technischer Hintergrund

Eine Content Security Policy ist:

  • hochgradig projektabhängig
  • stark von externen Ressourcen abhängig
  • empfindlich gegenüber Drittanbieter-Skripten
  • konfliktanfällig bei Tracking-Tools, Maps, Fonts etc.

In einer Agenturumgebung mit:

  • Elementor
  • Crocoblock
  • externen APIs
  • Marketing-Integrationen
  • Cookie-Tools
  • CDN-Setups

würde eine generische CSP:

  • entweder ständig angepasst werden müssen
  • oder regelmäßig Funktionen blockieren
  • oder sehr weich formuliert werden (was sie ineffektiv macht)

Eine „One-Size-Fits-All“-CSP ist in dynamischen Kundenprojekten nicht realistisch.

Sicherheitsphilosophie von image²

Dieses Plugin verfolgt eine klare Linie:

  • stabile, universelle Header setzen
  • keine projektindividuellen Policies erzwingen
  • keine Wartungsfalle erzeugen
  • keine Debug-Hölle verursachen

Eine CSP wird nur dann eingesetzt, wenn:

  • ein Projekt sie explizit erfordert
  • die Architektur statisch ist
  • externe Ressourcen klar definiert sind
  • ein dediziertes CSP-Testing erfolgt

Technische Funktionsweise

  • Schreibt Header-Regeln in die .htaccess
  • Nutzt insert_with_markers() für saubere Blockverwaltung
  • Wird bei Aktivierung und im Admin-Bereich geprüft
  • Zeigt Statusmeldung im Backend
  • Keine Laufzeit-Performancebelastung im Frontend

Die Header werden serverseitig gesetzt – nicht per PHP-Header-Funktion.

Vorteile dieser Lösung

  • unabhängig vom Theme
  • unabhängig von Caching-Plugins
  • keine Performance-Auswirkungen
  • kein zusätzliches JS
  • wartungsarm
  • Apache-konform

Einschränkungen

  • Funktioniert nur auf Apache-Servern mit mod_headers
  • Kein CSP-Schutz enthalten
  • Keine serverseitige WAF-Funktion

Fazit

image² Web Security Headers ist bewusst:

  • minimal
  • stabil
  • caching-kompatibel
  • agenturtauglich

Die Content Security Policy wurde absichtlich nicht integriert, da sie projektindividuell geplant und getestet werden muss und nicht als generische Standardlösung sinnvoll implementierbar ist.