So ist diese Website gebaut, und so messen wir sie

Diese Seite zeigt, wie wir selbst bauen: ohne fremde Dienste beim Aufruf, mit Sicherheits-Headern, gemessen mit Werkzeug und Datum. Jeder Punkt ist von außen nachprüfbar, auch die Stellen, an denen wir an eine Grenze stoßen.

Was wir messen

  • Verbindungen zu fremden Domains beim Aufruf
  • Cookies
  • Lighthouse mobil, Leistung
  • Zeit, bis das größte Element sichtbar ist (LCP), mobil
  • Sicherheits-Header
Neun Sicherheits-Header, die wir prüfen, als Raster: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, X-Permitted-Cross-Domain-Policies. Die Grafik zeigt, was geprüft wird, kein Messergebnis

Womit wir messen

  • Lighthouse 13.5.0 (Google), mobil und Desktop, je drei Läufe, genannt wird der mittlere Wert.
  • check-external.mjs und check-headers.mjs aus dem Prüfwerkzeug tr-website (Playwright 1.63.0, Chromium 153): Verbindungen zu fremden Domains, Cookies und Sicherheits-Header auf allen Seiten der Sitemap.
  • check-a11y.mjs aus demselben Prüfwerkzeug, mit axe-core über Playwright 1.63.0: Barrierefreiheit nach WCAG 2.2 AA bei 390 und 1280 Pixel Breite.
  • EDPS Website Evidence Collector 4.3.1, das Prüfwerkzeug des Europäischen Datenschutzbeauftragten: Cookies, fremde Hosts, Speicher im Endgerät.

Mit diesen Werkzeugen in diesen Versionen messen wir diese Website live nach. Die Werte dieser Fassung tragen wir nach der Live-Messung nach, jeden mit Werkzeug und Datum.

Weglassen, was nicht gebraucht wird

Eine Komponente, die es nicht gibt, kann niemand angreifen. Diese Website besteht aus vorgefertigten HTML-Dateien. Es gibt kein Redaktionssystem, keine Datenbank, keinen Login-Bereich und keine serverseitige Ausführung von Programmcode beim Aufruf einer Seite. Damit fallen die Angriffswege weg, die ein Redaktionssystem mitbringt: veraltete Plugins, gestohlene Redaktionszugänge, Einschleusen von Datenbankbefehlen.

Kein PHP auf diesem Server, und trotzdem kein Freibrief

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Lücken geschlossen (CVE-2026-109618, CVE-2026-109619). Diese Website setzt kein PHP ein: Die Seiten sind fertige HTML-Dateien, nginx liefert sie aus, und das Formular nimmt ein eigener Dienst in Node entgegen. Das ist kein Freibrief. Node, nginx und der Seitengenerator Astro haben eigene Sicherheitsmeldungen, die wir genauso verfolgen: mit npm audit für die Programmpakete und mit den Release-Notes der eingesetzten Versionen.

Was PHP2Shell für Websites bedeutet

Keine Requests an fremde Domains

Diese Website ist so gebaut, dass sie beim Aufruf nichts von einer Domain außerhalb dieser Website lädt. Keine Schriftarten von einem Schriftdienst, keine Programmbibliothek von einem Auslieferungsnetz, keine eingebettete Karte, kein Video von einer Plattform, kein Social-Widget, kein Tracking-Skript eines Anbieters. Seitenaufrufe zählt ein eigenes kleines Skript dieser Website an Umami auf demselben Server, ohne Cookies und ohne Zugriff auf den Speicher im Gerät.

  • Die Schriften Geist und Geist Mono liegen als lokale Dateien auf dem eigenen Server.
  • Animationen laufen mit eigenem Code, ohne nachgeladene Bibliothek.
  • Es gibt kein Google Analytics, kein Meta-Pixel, kein LinkedIn Insight, kein Hotjar.
  • Es gibt keine eingebettete Karte und kein eingebettetes Video.

Wo nichts von außen geladen wird, erfährt auch kein Werbe- oder Analysedienst vom Seitenaufruf. Im Endgerät legt diese Website keine Kennung ab.

Der Server schickt bei jeder Antwort einen Satz Regeln mit, an die sich der Browser halten muss. Diese Header sind mit einem Aufruf von außen prüfbar, zum Beispiel über securityheaders.com (externe Website, neues Fenster) oder das Mozilla Observatory (externe Website, neues Fenster).

  • Content-Security-Policy: Legt fest, von wo überhaupt Inhalte geladen werden dürfen. Ein eingeschleustes Skript von einer fremden Domain wird vom Browser abgelehnt, bevor es läuft.
  • Strict-Transport-Security: Zwingt jeden künftigen Aufruf auf eine verschlüsselte Verbindung, auch wenn jemand die Adresse ohne https eintippt.
  • X-Frame-Options / frame-ancestors: Verhindert, dass die Seite in einem fremden Rahmen eingebettet und für Klick-Täuschung missbraucht wird.
  • X-Content-Type-Options: Unterbindet, dass der Browser den Dateityp errät statt ihn zu lesen.
  • Referrer-Policy: Gibt an fremde Server nur die Domain weiter, von der ein Besucher kommt, nicht die vollständige Adresse mit Pfad.
  • Permissions-Policy: Schaltet Kamera, Mikrofon, Standort, Zahlungsschnittstelle und die Interessenszuordnung des Browsers ab.
  • Cross-Origin-Opener-Policy / -Resource-Policy: Trennt die Seite von anderen Browsing-Kontexten, damit fremde Fenster keinen Zugriff auf sie bekommen.

Wo wir an eine Grenze stoßen

Die strengste Form einer Content-Security-Policy arbeitet mit einem Einmalkennwort (Nonce), das der Server für jede einzelne Antwort neu erzeugt und in die erlaubten Skripte schreibt. Das setzt voraus, dass jede Seite bei jedem Aufruf neu erzeugt wird.

Diese Website besteht aus fertigen Dateien, die unverändert ausgeliefert werden. Das ist ein bewusster Kompromiss: Der statische Aufbau entfernt eine ganze Klasse von Angriffswegen, dafür gibt es keine Einmalkennwörter, die bei jedem Aufruf neu entstehen. Die Policy erlaubt deshalb nur Skriptdateien von dieser Domain. Skripte, die direkt im Quelltext stehen, führt der Browser nicht aus. Da keinerlei fremde Quellen zugelassen sind und keine Nutzereingabe in die Seite zurückgeschrieben wird, bleibt der praktische Angriffsweg dünn.

Auch Stilangaben sind nur aus Dateien dieser Domain erlaubt (style-src 'self'). Eingebettete Styles enthält diese Website nicht, und die ausgelieferte Policy lässt auch keine zu.

Formular ohne Drittanbieter

Die beiden Formulare dieser Website, Erstgespräch und Sicherheits-Check, brauchen Schutz vor automatisiertem Massenversand. Der übliche Weg dafür sind Bilderrätsel oder unsichtbare Prüfdienste, und jeder davon ist ein Request an eine fremde Domain. Damit wäre das Kernargument dieser Seite aufgehoben.

  • Honigtopf-Feld: ein für Menschen unsichtbares Eingabefeld. Wer es ausfüllt, ist keiner.
  • Zeitschwelle: Ein Mensch braucht für ein Formular länger als zweieinhalb Sekunden. Wird schneller abgesendet, wartet die Seite still, bis die Schwelle erreicht ist, für echte Nutzer unmerklich, für Massenversand unbrauchbar.
  • Datenminimierung: Wir fragen nur, was wir für die Antwort brauchen.

Kein reCAPTCHA, kein hCaptcha, kein Turnstile. Die Übertragung ist verschlüsselt, die Zieladresse steht in der Dienstleisterliste.

Meldewege für Schwachstellen

Unter /.well-known/security.txt liegt eine maschinenlesbare Datei nach RFC 9116 mit Kontaktadresse, Ablaufdatum und bevorzugten Sprachen. Wer eine Schwachstelle findet, muss nicht suchen, an wen er sich wendet. Wir bestätigen den Eingang innerhalb von zwei Tagen.

Abhängigkeiten

Jedes zusätzliche Programmpaket ist eine zusätzliche Stelle, an der etwas schiefgehen kann. Diese Website kommt mit zwei Paketen aus: dem Seitengenerator und einer Erweiterung für die Sitemap. Der Formulardienst auf dem Server nutzt zusätzlich ein Paket für den E-Mail-Versand (nodemailer). Kein Paket wird eingesetzt, ohne dass wir sagen können, warum es da ist.

Was nicht in der EU liegt

Hosting und Formularverarbeitung laufen auf einem Server in Deutschland. Die Namensauflösung der Domain liegt bewusst bei einem anderen Anbieter, bei Cloudflare, einer Gesellschaft mit Sitz in den USA: So hängen Domain und Hosting nicht vom selben Anbieter ab. Über Cloudflare läuft nur die Namensauflösung, nicht der Datenverkehr der Website. Die vollständige Aufstellung steht in der Dienstleisterliste.

Selbst nachprüfen

Sie müssen uns nichts davon glauben. Alle genannten Punkte lassen sich von außen messen, ohne Zugang und ohne unsere Mitwirkung:

Erstgespräch

Welcher Ablauf kostet Sie heute die meiste Zeit?

Kostenloses Erstgespräch anfragen

Wir sagen Ihnen, welcher Ablauf sich bei Ihnen zuerst lohnt. Ohne Verpflichtung.

Kostenloses Erstgespräch anfragen