Messung A · vorher
Noch keine Messung ausgewählt.
Security · Privacy · Lab
Was verrät dein Browser? Was bewirken Schutz-Header? Und wie entstehen typische Sicherheitsfehler? Entdecke Messwerte, vergleiche Einstellungen und lerne an nachvollziehbaren Beispielen.
Der Start prüft Browsermerkmale, Netzwerk-Einordnung und die Header dieser Seite. Vergleiche und Lernübungen funktionieren auch ohne Analyse.
Bereit. Die Analyse wurde noch nicht gestartet.
Fingerabdruck dieser Messung
Noch nicht berechnet
Eine Prüfsumme ausgewählter Merkmale. Sie kann sich mit Browser und Einstellungen ändern.
Auslesbare Merkmalsgruppen
—
Die Anzahl zeigt verfügbare Informationen. Sie misst weder Einzigartigkeit noch Tracking-Erfolg.
Messung & Grenzen
Noch nicht geprüft
Fehlende Messwerte können durch Datenschutzfunktionen oder nicht unterstützte Schnittstellen entstehen.
Die Netzwerk-Einordnung erscheint nach dem Start.
Die Browseranalyse startet erst auf deinen Wunsch.
HTTP-Header sind Anweisungen an deinen Browser. Sie können zum Beispiel verhindern, dass fremde Seiten Inhalte einbetten. Hier wird eine Auswahl dieser Regeln geprüft – die Sicherheit einer gesamten Anwendung lässt sich daraus nicht ableiten.
Erfüllte Basisprüfungen
—
Noch nicht geprüft. Starte oben die Analyse.
Die Ergebnisse erscheinen nach der Analyse.
Dieser Check prüft keine Passwörter, Zugriffsrechte, Geschäftsabläufe oder vollständigen TLS-Einstellungen. „Nicht prüfbar“ bedeutet, dass die vorliegenden Daten keine belastbare Bewertung erlauben.
Übernimm eine Messung als A, ändere eine Einstellung und starte die Analyse erneut. Übernimm das neue Ergebnis als B. Du kannst auch zwei Berichte dieses Labs laden. Dateien bleiben auf deinem Gerät; es gibt keinen Upload.
Noch keine Messung ausgewählt.
Noch keine Messung ausgewählt.
Berichtsformat 2, höchstens 1 MiB je Datei. Gekürzte Berichte enthalten weniger Details; fehlende Angaben werden nicht als Änderung gewertet. Importierte Dateien sind keine unabhängig geprüften Messergebnisse.
Wähle zwei Messungen für den Vergleich.
Füge öffentliche Antwort-Header ein oder wähle ein Beispiel. Die Werkstatt erklärt ausgewählte Schutzregeln vollständig lokal. Sie ruft keine Zielwebsite auf und verändert keine Servereinstellungen.
Eine Zeile je Header, etwa „X-Content-Type-Options: nosniff“. Keine Zugangsdaten oder Sitzungscookies einfügen. Ausgewertet werden ausschließlich die unterstützten Schutz-Header.
Wähle ein Beispiel oder füge Header ein.
Eine CSP legt unter anderem fest, aus welchen Quellen eine Seite Programme und andere Inhalte laden darf. Das ist eine zusätzliche Schutzschicht. Fehler im eigenen Programm behebt sie nicht. Eine Regel muss zur Anwendung passen und im Browser getestet werden; pauschales Kopieren kann Funktionen blockieren.
Die Werkstatt prüft ausgewählte Muster. Komplexe oder mehrdeutige Regeln brauchen eine gesonderte Prüfung. CSP bei MDN nachlesen.
Die Übungen sind lokale Modelle mit erfundenen Daten. Du kannst eine fehlerhafte Regel ausprobieren und anschließend ihre Korrektur prüfen. Es werden keine fremden Systeme angesprochen und keine eingegebenen Programme ausgeführt.
01 · Eingaben sicher ausgeben
Ein Gästebuch soll einen Namen anzeigen. Wenn es ungeprüfte Eingaben als HTML einsetzt, können fremde Elemente oder ausführbare Anweisungen in die Seite gelangen. Das nennt man Cross-Site Scripting, kurz XSS.
Für reinen Text ist textContent eine passende Ausgabe. Absichtlich erlaubtes HTML benötigt eine geprüfte Bereinigung; andere Ausgabestellen wie URLs oder JavaScript erfordern andere Schutzregeln. Eine CSP ergänzt diese Maßnahmen.
Das Modell zeigt die unterschiedliche Behandlung einer Eingabe. Es führt den Beispielcode nicht aus und prüft keine tatsächliche Anwendung. Teste nach einer Korrektur normale Texte, Sonderzeichen und unerwartete Eingaben.
02 · Zugriffsrechte prüfen
Du bist im Modell als Anna angemeldet. Rechnung 104 gehört Anna, Rechnung 105 gehört Ben. Probiere aus, was beim Wechsel der Rechnungsnummer passiert.
Der Server muss für jede angeforderte Rechnung prüfen, ob die angemeldete Person sie sehen darf. Versteckte Schaltflächen oder zufällige Kennungen ersetzen diese Prüfung nicht. Anwendungen können zusätzlich gezielt erlaubte Freigaben oder Rollen haben.
In einem echten Test werden eigene Testkonten mit unterschiedlichen Rechten verwendet. Die Prüfung gehört auf den Server; die Auswahl hier veranschaulicht nur dessen Entscheidung.
03 · Beabsichtigte Aktionen erkennen
Stell dir vor, du bist in einem Konto angemeldet. Eine andere Seite versucht, eine Änderung auszulösen, während dein Browser passende Anmeldedaten mitsendet. Die Anmeldung allein beweist nicht, dass du diese Änderung wolltest.
Viele Frameworks stellen Schutz vor CSRF bereit. Ein Token ist ein nicht vorhersagbarer Nachweis, der zur Sitzung passen und vom Server geprüft werden muss. Herkunftsprüfungen und geeignete SameSite-Cookies können den Schutz ergänzen.
Das Modell nimmt ausdrücklich an, dass die Anmeldung mitgesendet wird. Tatsächlich hängt dies unter anderem von Cookie-Einstellungen und Anfrageart ab. HTTPS allein verhindert CSRF nicht; ein echter Test muss diese Bedingungen berücksichtigen.
Standardmäßig erhältst du einen gekürzten Bericht ohne IP, Fingerprint und detaillierte Gerätewerte. Auch gekürzte Befunde vor dem Weitergeben prüfen. Es wird nichts hochgeladen.
Methodik · Stand 17. September 2026
Gute Sicherheitsprüfung trennt Beobachtung, Einordnung und offene Fragen.
JavaScript fragt verfügbare Geräte- und Browserinformationen ab. Ausgewählte Werte werden zu einer Prüfsumme zusammengefasst. Die Messung bleibt lokal und zeigt, was diese Seite in dieser Sitzung lesen konnte.
Ein gleicher Wert beweist keine eindeutige Identität. Ein anderer Wert beweist keine Anonymität. Browser können Informationen begrenzen, vereinheitlichen oder verändern.
Die eigene API sieht die IP deiner Verbindung. Geo- und Netzbetreiberdaten stammen aus lokal gespeicherten DB-IP-Lite-Datenbanken. Eine Tor-Liste und eine Hosting-Heuristik liefern Hinweise, keine allgemeine VPN-Erkennung.
Datenstand und Verfügbarkeit werden angezeigt. Der geschätzte Standort eines IP-Netzes kann von deinem Aufenthaltsort abweichen. DB-IP Lite: Quelle und Grenzen.
Der Header-Check liest eine neue Antwort dieser Seite. Die Werkstatt wertet eingefügte Beispiele lokal aus. Die Lernübungen simulieren klar begrenzte Regeln mit erfundenen Daten.
Ein vollständiger Anwendungstest braucht weitere Verfahren, etwa für Berechtigungen und Geschäftsabläufe. Eine nützliche Grundlage sind OWASP ASVS 5.0.0 und der WSTG 4.2.
| Verbindung | Was der Server sieht | Was offen bleibt | Browsermerkmale |
|---|---|---|---|
| Ohne bewusst gewähltes VPN | Die öffentliche Ausgangs-IP, etwa deines Providers | IP-Geodaten sind nur eine Schätzung; ein Proxy lässt sich nicht sicher ausschließen | Hängen vom Browser und seinen Einstellungen ab |
| Mit VPN | Üblicherweise die Ausgangs-IP des VPN-Dienstes | Ein Hosting-Hinweis kann passen, beweist aber keinen VPN-Einsatz | Ein VPN allein vereinheitlicht diese Merkmale nicht |
| Tor Browser | Die IP eines Tor-Exit-Relays für diese Verbindung | Erkennung hängt von einer aktuellen Liste ab; verschiedene Websites müssen nicht verschiedene Exits sehen | Tor Browser begrenzt Unterschiede; Einstellungen und Nutzung bleiben relevant |
Das Lab gibt verständliche Hinweise und macht ausgewählte Eigenschaften sichtbar. Es bescheinigt weder vollständige Sicherheit noch Anonymität. Die Erklärungen und Verfahren werden gemeinsam mit der Anwendung versioniert.