Von Note B zu Note A:
Wie wir NIS2-Compliance in 30 Minuten hergestellt haben

Wir haben unsere eigenen Websites mit KENSAI gescannt und kritische NIS2-Compliance-Lücken gefunden. Fehlende HTTP-Sicherheits-Header brachten zwei unserer drei Domains auf Note B (0,786). Hier steht genau, was falsch war, welche NIS2-Artikel gefährdet waren und wie 30 Minuten Caddy-Konfiguration alles behoben haben.

Die unbequeme Wahrheit

Wir bauen eine Sicherheits-Scanning-Plattform. Wir predigen unseren Kunden NIS2-Compliance. Und dann ließen wir KENSAI auf unseren eigenen Domains laufen — und stellten fest, dass zwei von drei nicht konform waren.

Keine Schwachstellen, keine Datenlecks. Nur fehlende HTTP-Sicherheits-Header — jene Art stiller Lücke, die Regulierer zuerst prüfen und Angreifer als Zweites ausnutzen. Nach der NIS2-Richtlinie (Art. 21 Abs. 2) sind diese Header für regulierte Einrichtungen nicht optional. Sie sind eine grundlegende Hygieneanforderung.

Hier steht, was wir fanden und wie schnell wir es behoben haben.

Die Scan-Ergebnisse

Wir führten KENSAIs automatisierten NIS2-Compliance-Scan am 15. März 2026 über alle drei Portfolio-Domains aus:

kensai.app erzielte mit 0,997 nahezu Bestwert, weil dort bereits die korrekte Caddy-Header-Konfiguration lief. Die beiden anderen Domains — brnz.ai und codeforceai.com — lagen beide bei 0,786 und vermissten jeweils dieselben sechs kritischen Sicherheits-Header.

Was fehlte — und warum es für NIS2 zählt

Sechs HTTP-Response-Header fehlten auf beiden durchgefallenen Domains. Jeder einzelne lässt sich direkt Anforderungen der NIS2-Richtlinie zuordnen:

Die Behebung: Caddy-Header-Konfiguration

Wir nutzen Caddy als Reverse Proxy. Die Behebung war ein einziger, wiederverwendbarer header-Block, den wir auf alle Domains anwenden konnten. Genau das haben wir ergänzt:

# Global header snippet — add to all production sites
(security_headers) {
  header {
    # Force HTTPS — NIS2 Art. 21(2)(h): secure communications
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    # Block XSS & injection — NIS2 Art. 21(2)(d): supply chain security
    Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://fonts.googleapis.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https:; frame-ancestors 'none'"

    # Prevent clickjacking — NIS2 Art. 21(2)(b)
    X-Frame-Options "DENY"

    # Stop MIME-sniffing — NIS2 Art. 21(2)(b)
    X-Content-Type-Options "nosniff"

    # Limit referrer leakage — NIS2 Art. 21(2)(e)
    Referrer-Policy "strict-origin-when-cross-origin"

    # Restrict browser APIs — NIS2 Art. 25: security by design
    Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()"

    # Remove server fingerprinting
    -Server
    -X-Powered-By
  }
}

Anschließend importierten wir das Snippet in jeden Site-Block:

# brnz.ai
brnz.ai, www.brnz.ai {
  import security_headers
  reverse_proxy localhost:3001
}

# codeforceai.com
codeforceai.com, www.codeforceai.com {
  import security_headers
  reverse_proxy localhost:3002
}

Caddy neu laden, Header in den Browser-DevTools verifizieren, fertig:

caddy reload --config /etc/caddy/Caddyfile

Die Zeitleiste: 30 Minuten von Anfang bis Ende

Vorher vs. Nachher

Zentrale Lehren

1. Sicherheits-Header sind NIS2-Compliance-Punkte, keine optionalen Extras

Von jeder NIS2-regulierten Einrichtung wird erwartet, dass grundlegende HTTP-Sicherheits-Header vorhanden sind. Regulierer führen bei Audits zunehmend automatisierte Scans durch. Ein fehlender Strict-Transport-Security-Header ist kein kleines Versäumnis — er ist ein Beleg für unzureichendes Risikomanagement nach Art. 21 Abs. 2.

2. Selbst Sicherheitsunternehmen haben Lücken

Wir bauen Compliance-Werkzeuge und hatten dennoch zwei Sites mit Note B. Das ist nicht peinlich — es ist eine Erinnerung daran, dass Konfigurationsdrift passiert. Eine schnell gestartete Domain, eine nicht synchronisierte Caddyfile, ein fehlender Import. Automatisiertes Scanning fängt ab, was manuelle Audits übersehen.

3. Die Behebung ist fast immer einfach

Sechs fehlende Header. Dreißig Zeilen Caddy-Konfiguration. Dreißig Minuten Arbeit. Die Lücke zwischen Note B und Note A ist kein monatelanges Projekt — sie ist ein Nachmittag. Der schwierige Teil ist, überhaupt zu wissen, dass die Lücke existiert.

4. Wiederverwendbare Snippets verhindern künftigen Drift

Indem wir die Header in ein (security_headers)-Snippet ausgelagert haben, erhält jede neue Domain, die wir hinzufügen, automatisch die volle NIS2-Header-Abdeckung durch eine einzige import-Zeile. Compliance wird zum Standard, nicht zum nachträglichen Einfall.

Was das für Ihre Organisation bedeutet

Wenn Sie unter NIS2 fallen — oder sich auf ein Audit vorbereiten — gehören Ihre HTTP-Sicherheits-Header zu den ersten Dingen, die Regulierer prüfen. Sie sind schnell zu scannen, eindeutig zu bewerten und trivial zu beheben. Es gibt keine Entschuldigung für Note B, wenn Note A 30 Minuten dauert.

Führen Sie den Scan durch. Lesen Sie den Bericht. Beheben Sie, was markiert ist. Scannen Sie erneut zur Bestätigung.