Ein HTTP-Sicherheitsheader ist eine Anweisung, die der Server einer Website bei jedem Besuch an den Browser sendet, noch bevor die Seite angezeigt wird. Diese Anweisungen sind für den Internetnutzer nicht sichtbar, legen jedoch fest, welche Aktionen der Browser ausführen darf: Verschlüsselung erzwingen, die Ausführung eines von einer anderen Quelle stammenden Skripts verweigern oder die Anzeige der Seite in einem unsichtbaren Frame verhindern. Diese Seite erfasst die tatsächlich von den offiziellen Websites der 26 Schweizer Kantone gesendeten Header.
Passive Cybersicherheitsanalysen : Keine Schwachstellen-Scans, keine Zugriffs- oder Ausnutzungsversuche. Die Prüfungen beschränken sich auf das Lesen öffentlicher Informationen, die jeder Browser oder Mailserver bei einer gewöhnlichen Verbindung zur Website erhält.
- Globale Sicherheit
- security.txt
- Sicherheits-Header (Detail den CISO vorbehalten)
- E-Mail-Sicherheit (Detail den CISO vorbehalten)
Karte wird geladen…
Stand 11. Oktober 2026: 26 Websites der Schweizer Kantone bewertet (Sicherheits-Header): 12 wenden die bewährten Praktiken an (Schutzmassnahmen, die die Website bei jedem Besuch ankündigt und die Internetnutzende in ihrem Browser schützen).
- Stark12(46%)
- Teilweise12(46%)
- Zu verstärken1(4%)
- Nicht bewertet1(4%)
Diese Zahlen zeigen den heutigen Stand. Die konsolidierte Analyse zeigt ihre Entwicklung Monat für Monat und den nach Schweregrad geordneten Massnahmenplan: konsolidierte Analyse ansehen
Verlauf der Entwicklung
| Zeitraum | Stark | Teilweise | Zu verstärken | Nicht bewertet | Total |
|---|---|---|---|---|---|
| Juli 2026 | 0 | 0 | 0 | 0 | 0 |
| August 2026 | 11 | 14 | 1 | 0 | 26 |
| September 2026 | 12 | 13 | 1 | 0 | 26 |
| Oktober 2026 | 12 | 12 | 1 | 1 | 26 |
Katalog der Prüfpunkte
Hier das Detail jeder Prüfung, nach Familie gruppiert: Datei security.txt, HTTP-Header, DNS-Einträge – dann, am Ende der Seite, die ergänzenden Indikatoren ausserhalb der Bewertung. Jede Prüfung wird als «Stark», «Teilweise» oder «Zu verstärken» bewertet; eine Prüfung, die nicht gemessen werden konnte (Website nicht erreichbar, DNS-Antwort fehlgeschlagen), ist «Nicht bewertet» und zählt weder als Erfolg noch als Mangel. Eine Frage oder eine Domain ausschliessen? Bitte über das Kontaktformular.
Sicherheits-Header
Schutzmassnahmen, die die Website bei jedem Besuch ankündigt und die Internetnutzende in ihrem Browser schützen.
Vollständiger Leitfaden: HTTP-Sicherheits-Header: Der umfassende Leitfaden (HSTS, CSP, Cookies)
HEAD-HTTPSVerschlüsselte Verbindung verfügbar (HTTPS)KritischWarum es wichtig ist. Ohne verschlüsselte Verbindung kann alles, was zwischen Besucher und Website fliesst – Formulare, Zugangsdaten, Dokumente -, von jemandem im Netz mitgelesen oder verändert werden (öffentliches WLAN, kompromittiertes Gerät). Browser kennzeichnen solche Websites zudem als «nicht sicher».
Wie es funktioniert. HTTPS verschlüsselt die Verbindung mit einem Zertifikat: einem digitalen Ausweis der Website, ausgestellt von einer anerkannten Stelle. Damit es akzeptiert wird, muss das Zertifikat gültig sein, für den richtigen Domainnamen ausgestellt und vollständig, mit seinen Zwischenzertifikaten, ausgeliefert werden. Diese Kontrolle betrifft die verschlüsselte Verbindung selbst; die Weiterleitung von der http://-Adresse ist eine eigene Kontrolle.
Wie es bewertet wird.
- Stark: die Website antwortet per HTTPS mit einem akzeptierten Zertifikat.
- Teilweise: das Zertifikat ist gültig, wird aber ohne seine Zwischenzertifikate ausgeliefert (unvollständige Kette). Desktop-Browser ergänzen die Kette oft selbst, aber Anwendungen, Mobilgeräte oder automatisierte Dienste lehnen die Verbindung ab.
- Zu verstärken: keine verschlüsselte Verbindung (Website nur unverschlüsselt, kein Dienst auf dem HTTPS-Port) oder abgelehntes Zertifikat: abgelaufen, für einen anderen Namen ausgestellt oder selbst signiert. Der Browser zeigt dann eine Sicherheitswarnung.
Kritischer Schweregrad: Ist es «Zu verstärken», wird die ganze Familie «Sicherheits-Header» als «Zu verstärken» eingestuft, unabhängig von den übrigen Ergebnissen; ist es «Teilweise», kann sie «Teilweise» nicht übersteigen.
Wie man es behebt. Ein gültiges Zertifikat für den Namen der Website installieren (Let's Encrypt ist kostenlos und erneuert sich automatisch), es mit seinen Zwischenzertifikaten ausliefern und prüfen, dass die automatische Erneuerung funktioniert.
OWASP-Leitfaden – Transport Layer SecurityHEAD-REDIRECTAutomatische Weiterleitung auf HTTPSHochWarum es wichtig ist. Viele Besucher tippen die Adresse ohne «https://» oder folgen einem alten http://-Link. Ohne Weiterleitung findet dieser erste Besuch unverschlüsselt statt und kann auf eine gefälschte Website umgeleitet werden, bevor die verschlüsselte Verbindung überhaupt angeboten wird.
Wie es funktioniert. Fragt der Browser die http://-Adresse ab, muss der Server sofort antworten, dass die Seite unter der https://-Adresse liegt. Eine dauerhafte Weiterleitung (Code 301 oder 308) ist vorzuziehen: der Browser merkt sie sich für die nächsten Besuche.
Wie es bewertet wird.
- Stark: die http://-Adresse leitet sofort auf eine https://-Adresse weiter.
- Zu verstärken: die http://-Adresse zeigt die Website unverschlüsselt oder leitet auf eine Adresse weiter, die nicht mit https:// beginnt.
Hoher Schweregrad: Ist es «Zu verstärken», kann die Familie «Sicherheits-Header» «Teilweise» nicht übersteigen.
Wie man es behebt. Den Server oder das Hosting so einrichten, dass jede http://-Adresse auf ihre https://-Entsprechung weiterleitet, vorzugsweise dauerhaft (301 oder 308).
MDN-Leitfaden – HTTP-WeiterleitungenHEAD-HSTSBrowser zu dauerhaftem HTTPS gezwungen (HSTS)HochWarum es wichtig ist. Selbst mit Weiterleitung geht die allererste Anfrage unverschlüsselt hinaus und kann von einer angreifenden Person im Netz abgefangen werden. HSTS weist den Browser an, die Website nie mehr anders als per HTTPS aufzurufen: nach einem ersten Besuch verschwindet dieses Angriffsfenster.
Wie es funktioniert. Die Website sendet den Header «Strict-Transport-Security» mit einer Dauer (max-age, in Sekunden), während der sich der Browser die Vorgabe merken muss; jeder Besuch verlängert sie. Die Option includeSubDomains dehnt die Regel auf die Subdomains aus.
Wie es bewertet wird.
- Stark: der Header wird mit einer Dauer von mindestens 6 Monaten (15 552 000 Sekunden) gesendet; ein Jahr wird empfohlen.
- Teilweise: der Header wird gesendet, aber für weniger als 6 Monate: der Schutz erlischt, wenn der Besucher selten wiederkommt.
- Zu verstärken: kein Header oder ein Header ohne verwertbare Dauer.
Hoher Schweregrad: Ist es «Zu verstärken», kann die Familie «Sicherheits-Header» «Teilweise» nicht übersteigen.
Wie man es behebt. Sobald die Website vollständig per HTTPS ausgeliefert wird, den Header «Strict-Transport-Security: max-age=31536000» (ein Jahr) hinzufügen; «includeSubDomains» ergänzen, wenn auch alle Subdomains per HTTPS erreichbar sind.
MDN-Leitfaden – HSTSHEAD-CSPListe erlaubter Skripte und Ressourcen (CSP)GeringWarum es wichtig ist. Gelingt es einer angreifenden Person, Code in eine Seite einzuschleusen – über ein schlecht geschütztes Formular, ein kompromittiertes Modul -, läuft dieser Code bei jedem Besucher und kann Daten stehlen oder auf eine gefälschte Website umleiten. Eine CSP-Richtlinie teilt dem Browser mit, welche Skriptquellen legitim sind: alles andere wird blockiert.
Wie es funktioniert. Der Header «Content-Security-Policy» listet die zugelassenen Herkünfte auf: die Website selbst, einen bestimmten Statistikdienst usw. Eine Variante «Report-Only» erlaubt es, die Richtlinie zu testen: der Browser meldet, was er blockiert hätte, ohne etwas zu blockieren. Es ist die einzige Kontrolle, die echte Integrationsarbeit an der Website verlangt, daher die geringe Schwere trotz ihres Gewichts.
Wie es bewertet wird.
- Stark: eine Richtlinie wird angewendet.
- Teilweise: eine Richtlinie besteht im Testmodus (Report-Only): der Schritt ist eingeleitet, aber noch wird nichts blockiert.
- Zu verstärken: keine Richtlinie, weder angewendet noch im Test.
Geringer Schweregrad: Es zählt für die Bewertung der Familie und begrenzt deren Ergebnis nie.
Wie man es behebt. Eine auf die Website zugeschnittene Richtlinie festlegen, sie zuerst im Modus «Content-Security-Policy-Report-Only» testen, das Gemeldete korrigieren und sie dann anwenden.
MDN-Leitfaden – Content-Security-PolicyHEAD-NOSNIFFDateityp nicht vom Browser neu interpretiert (nosniff)GeringWarum es wichtig ist. Manche Browser erraten den Typ einer Datei anhand ihres Inhalts. Eine angreifende Person kann dies nutzen, um eine auf der Website abgelegte Datei – ein präpariertes Bild oder Dokument – als Programm ausführen zu lassen. Der Header nosniff verbietet dieses Raten.
Wie es funktioniert. Die Website sendet «X-Content-Type-Options: nosniff»: der Browser hält sich dann an den vom Server angegebenen Dateityp.
Wie es bewertet wird.
- Stark: der Header wird gesendet.
- Zu verstärken: der Header fehlt.
Geringer Schweregrad: Es zählt für die Bewertung der Familie und begrenzt deren Ergebnis nie.
Wie man es behebt. Den Header «X-Content-Type-Options: nosniff» in der Serverkonfiguration hinzufügen.
MDN-Leitfaden – X-Content-Type-OptionsHEAD-FRAMESchutz vor Einbettung in unsichtbare Rahmen (Anti-Clickjacking)GeringWarum es wichtig ist. Eine bösartige Website kann die Seiten der Organisation in einem unsichtbaren Rahmen über eigene Schaltflächen legen, um Besucher unbemerkt klicken zu lassen – eine Zahlung bestätigen, eine Einstellung ändern. Das ist «Clickjacking».
Wie es funktioniert. Zwei gleichwertige Mittel verhindern es: der Header X-Frame-Options, alt und überall verstanden, oder die Direktive frame-ancestors einer CSP-Richtlinie, moderner und in neueren Browsern vorrangig. Beide können nebeneinander bestehen.
Wie es bewertet wird.
- Stark: das eine oder das andere ist vorhanden.
- Zu verstärken: keines von beiden ist vorhanden.
Geringer Schweregrad: Es zählt für die Bewertung der Familie und begrenzt deren Ergebnis nie.
Wie man es behebt. «X-Frame-Options: SAMEORIGIN» oder die Direktive «frame-ancestors 'self'» in der CSP-Richtlinie hinzufügen.
MDN-Leitfaden – X-Frame-OptionsHEAD-REFERREREingeschränkte Informationen an externe Links (Referrer-Policy)GeringWarum es wichtig ist. Folgt ein Besucher einem Link auf eine andere Website, kann sein Browser die Adresse der verlassenen Seite übermitteln. Diese Adresse enthält manchmal sensible Angaben: Dossiernummer, Suchbegriff, Zugangstoken.
Wie es funktioniert. Der Header «Referrer-Policy» regelt, was übermittelt wird. Der Wert «strict-origin-when-cross-origin» teilt anderen Websites nur den Namen der Herkunftswebsite mit, nie die vollständige Adresse der Seite.
Wie es bewertet wird.
- Stark: eine Richtlinie ist festgelegt (ausser unsafe-url).
- Teilweise: die Richtlinie «unsafe-url» ist gewählt: die vollständige Adresse der Seite wird an alle verlinkten Websites übermittelt.
- Zu verstärken: keine Richtlinie: jeder Browser wendet dann sein eigenes Verhalten an.
Geringer Schweregrad: Es zählt für die Bewertung der Familie und begrenzt deren Ergebnis nie.
Wie man es behebt. Den Header «Referrer-Policy: strict-origin-when-cross-origin» hinzufügen.
MDN-Leitfaden – Referrer-PolicyHEAD-PERMISSIONSZugriff auf Browserfunktionen eingeschränkt (Permissions-Policy)GeringWarum es wichtig ist. Eine Seite kann Zugriff auf Kamera, Mikrofon oder Standort des Besuchers verlangen. Braucht die Website das nicht, schliesst man diese Türen besser: ein eingeschleustes Skript oder ein eingebetteter Fremdinhalt kann sie dann nicht anfordern.
Wie es funktioniert. Der Header «Permissions-Policy» listet die Browserfunktionen auf, die die Seite und ihre eingebetteten Inhalte nutzen dürfen.
Wie es bewertet wird.
- Stark: eine Richtlinie ist festgelegt.
- Zu verstärken: keine Richtlinie ist festgelegt.
Geringer Schweregrad: Es zählt für die Bewertung der Familie und begrenzt deren Ergebnis nie.
Wie man es behebt. Eine Richtlinie hinzufügen, die Ungenutztes schliesst, zum Beispiel «Permissions-Policy: camera=(), microphone=(), geolocation=()».
MDN-Leitfaden – Permissions-PolicyHEAD-VERSIONSoftwareversion nicht offengelegtGeringWarum es wichtig ist. Ein Server, der seine Software und deren genaue Version angibt – zum Beispiel «Apache/2.4.41» oder «PHP/7.4.3» -, zeigt Angreifern, welche bekannten Schwachstellen sie zuerst ausprobieren können, ganz ohne Suchaufwand.
Wie es funktioniert. Die Angabe erscheint in den Headern «Server» und «X-Powered-By» jeder Antwort. Die Nummer zu verbergen behebt keine Schwachstelle, nimmt Angreifern aber einen wertvollen Hinweis. Der Name der Software allein, ohne Nummer, wird akzeptiert.
Wie es bewertet wird.
- Stark: keine Versionsnummer wird angegeben.
- Zu verstärken: eine Versionsnummer ist in den Headern sichtbar.
Geringer Schweregrad: Es zählt für die Bewertung der Familie und begrenzt deren Ergebnis nie.
Wie man es behebt. Den Server so konfigurieren, dass die Versionsnummer in den Headern Server und X-Powered-By verborgen bleibt (zum Beispiel ServerTokens Prod und ServerSignature Off bei Apache, expose_php = Off bei PHP).
OWASP-Projekt – Sichere HeaderHEAD-COOKIESGeschützte Cookies (Secure, HttpOnly, SameSite)GeringWarum es wichtig ist. Cookies tragen oft die Sitzung einer angemeldeten Person. Schlecht geschützt kann ein Cookie gestohlen werden – in einem unverschlüsselten Netz, durch ein eingeschleustes Skript – und es erlauben, sich als diese Person auszugeben.
Wie es funktioniert. Drei Attribute schützen ein Cookie: Secure (nur per HTTPS gesendet), HttpOnly (für Skripte der Seite nicht lesbar) und SameSite (bei Anfragen von anderen Websites nicht gesendet). Geprüft werden nur die Cookies, die die Startseite in der ersten Serverantwort setzt; eine Website ohne Cookies wird in diesem Punkt nicht bewertet.
Wie es bewertet wird.
- Stark: alle Cookies tragen die drei Attribute.
- Teilweise: alle Cookies sind als Secure markiert, aber bei mindestens einem fehlt HttpOnly oder SameSite.
- Zu verstärken: mindestens ein Cookie ist nicht als Secure markiert.
Geringer Schweregrad: Es zählt für die Bewertung der Familie und begrenzt deren Ergebnis nie.
Wie man es behebt. Jedem von der Website gesetzten Cookie die Attribute Secure, HttpOnly und SameSite (mindestens Lax) hinzufügen.
MDN-Leitfaden – Set-CookieHäufige Fragen
Sind diese Cybersicherheitsanalysen invasiv?
Nein. Alles, was hier gemessen wird, ist öffentlich und wird von jedem Besucher oder Mailserver ohnehin gelesen: die von der Startseite zurückgegebenen Header, DNS-Einträge, die bei jeder eingehenden E-Mail abgefragt werden, und die Datei security.txt, wo sie veröffentlicht ist. Hinzu kommen zwei öffentliche Datenbanken, die abgefragt werden, ohne die Organisation je zu kontaktieren: die in die Browser integrierte HSTS-Preload-Liste und die Routing-Datenbank des RIPE NCC (RIPEstat). Keine Penetrationstests, keine Suche nach Schwachstellen, keine Anmeldeversuche, keine abgeschickten Formulare. Eine einzige Anfrage pro Domain und Durchlauf dient allen Prüfungsfamilien zugleich, und der User-Agent der Sonden verweist auf diese Seite, damit ein Betreiber, der seine Protokolle prüft, weiss, woher der Datenverkehr stammt.
Warum ist das detaillierte Ergebnis der Organisationen nicht öffentlich?
Zu veröffentlichen, dass eine bestimmte Website einen bestimmten Schutz nicht anwendet, kommt einer Liste von Angriffszielen gleich und hilft niemandem bei der Behebung. Diese Seite veröffentlicht daher aggregierte Werte: wie viele Organisationen die bewährten Praktiken anwenden, in welchem Umfang und wie sich die Lage entwickelt. Die Karte zeigt das Gesamturteil jeder Organisation, nie die Liste ihrer Mängel. Die Datei security.txt bildet eine Ausnahme und bleibt öffentlich, denn sie gibt an, wem eine Sicherheitslücke gemeldet werden kann.
Wer kann das detaillierte Ergebnis einer Organisation einsehen?
Die verantwortliche Person für Informationssicherheit (CISO) der betreffenden Organisation oder des Gemeinwesens, dem sie angehört: Ein kantonaler CISO sieht den Kanton und alle Gemeinden dieses Kantons, ein kommunaler CISO die Gemeinde. Für Organisationen, die mehrere Einrichtungen koordinieren, gibt es branchenweite und nationale Zugänge.
Wer kann einen Zugang erhalten, was zeigt er zusätzlich, und wie wird er beantragt?
Der Zugang steht den Sicherheitsverantwortlichen der erfassten Organisationen offen, auf Anfrage und nach Prüfung. In seinem Bereich bietet ein genehmigter Zugang das Detail Prüfung für Prüfung, die Liste der noch zu behebenden Punkte, den Verlauf jeder Organisation, ein PDF-Blatt sowie die konsolidierte Auswertung mit ihrem Massnahmenplan. Der Antrag erfolgt auf dieser Seite: Zugang beantragen.
Was misst die Sicherheitsbewertung und wie wird sie berechnet?
Jede Prüfung hat ein Gewicht und einen Schweregrad. Das Ergebnis einer Prüfungsfamilie wird in drei Stufen bewertet: «Stark» ab 80 % der Punkte, «Teilweise» ab 40 %, «Zu verstärken» darunter. Danach gelten unabhängig von der Summe zwei Obergrenzen: Eine fehlgeschlagene kritische Prüfung führt auf «Zu verstärken» zurück, eine teilweise erfüllte kritische Prüfung oder eine fehlgeschlagene schwerwiegende Prüfung verhindert ein besseres Ergebnis als «Teilweise». Die Gesamtbewertung ist der Durchschnitt der Sonden, die ein Urteil geliefert haben, auf derselben Skala. Was nicht gemessen werden konnte, bleibt «Nicht bewertet» und fliesst nicht in diesen Durchschnitt ein. Mehr dazu: die Gewichte und Schweregrade im Detail, Prüfung für Prüfung.
Was sind die ergänzenden Indikatoren, die zur Information angezeigt werden?
Messwerte, die bei jeder Analyse erhoben werden, um zu informieren, ohne zu bewerten: IPv6-Erreichbarkeit von Website und Mailsystem, Eintrag in der HSTS-Preload-Liste der Browser, RPKI-Signatur der Route zum Server, im DNS verankertes Zertifikat der Mailserver (DANE), Werbe- oder Analyse-Tracker und Google Fonts, die von der Startseite geladen werden, sowie Betreiber und Registrierungsland der Adressen von Website und Mailsystem. Sie fliessen in kein Ergebnis ein: Diese Praktiken sind noch wenig verbreitet oder hängen vom Hoster ab, und eine Seite, die ohne Ausführung von Skripten gelesen wird, verrät nicht, ob ein Tracker auf die Einwilligung des Besuchers wartet. Das Land ist jenes, unter dem die Adresse registriert ist, in der Regel der Sitz des Betreibers, nicht der Standort des Servers. Die Öffentlichkeit sieht die Anteile pro Bereich; das Detail pro Organisation bleibt deren Sicherheitsverantwortlichen vorbehalten.
Wie oft werden diese Daten aktualisiert?
Jeder Bereich wird monatlich analysiert. Das genaue Datum der angezeigten Messung steht weiter oben auf dieser Seite am Anfang der Statistiken, und der Verlauf hält sie Monat für Monat fest. Eine Korrektur durch eine Organisation erscheint daher beim nächsten Durchlauf, nicht am selben Tag.
Was ist ein HTTP-Sicherheits-Header?
Eine Anweisung, die der Server mit jeder Seite an den Browser sendet und die der Browser anschliessend für den Besucher umsetzt: bei HTTPS bleiben (HSTS), nur Skripte aus einer deklarierten Liste ausführen (CSP), den Typ einer Datei nicht neu interpretieren (nosniff), die Anzeige der Website in einem unsichtbaren Rahmen verweigern (Schutz vor Clickjacking), begrenzen, was an ausgehende Links weitergegeben wird (Referrer-Policy), oder den Zugriff auf Browserfunktionen einschränken (Permissions-Policy). Diese Anweisungen werden auf dem Webserver eingestellt, ohne den Inhalt der Website anzutasten. Rolle jedes Headers, Prioritäten und Einführung, ohne die Website zu beschädigen: der vollständige Leitfaden zu den HTTP-Sicherheits-Headern.
Wie wird ein Problem mit dem TLS-Zertifikat berücksichtigt?
Die Prüfung «Verschlüsselte Verbindung verfügbar (HTTPS)» kontrolliert, ob die Website über HTTPS mit einem akzeptierten Zertifikat antwortet. Wird das Zertifikat abgelehnt, werden die genaue Ursache und die nötige Korrektur angegeben, und die übrigen Header (HSTS, CSP usw.) werden trotzdem gemessen. Eine unvollständige Zertifikatskette zählt als «Teilweise»: Ein Desktop-Browser ergänzt die Kette oft selbst und zeigt die Website an, andere Clients (Apps, Sicherheitstools, manche Mobilgeräte) verweigern jedoch die Verbindung. Ein abgelaufenes, für einen anderen Namen ausgestelltes oder selbstsigniertes Zertifikat zählt als Fehler, weil dann alle Browser eine Warnung anzeigen. Die Details der TLS-Aushandlung (Protokollversion, Aussteller, bevorstehendes Ablaufdatum) werden nicht bewertet: Ein Zertifikat wird heute automatisch alle paar Wochen erneuert, und die Überwachung seines Ablaufs würde vor allem Warnungen erzeugen, die sich von selbst erledigen. Eine Website, die gar nicht antwortet (Name nicht gefunden, Zeitüberschreitung), bleibt «Nicht bewertet»: Ein vorübergehender Ausfall wird nicht angelastet. HTTPS, Weiterleitung und HSTS im Detail: der Leitfaden zu den HTTP-Sicherheits-Headern.