«Niemand kennt die Adresse» ist kein Schutz, sondern ein Zufallsvorteil, der irgendwann endet. Automatisierte Scanner testen fortlaufend ganze IP-Bereiche und Domain-Muster durch und finden Test- und Entwicklungsseiten oft innerhalb weniger Tage – unabhängig davon, ob jemand den Link je öffentlich geteilt hat. Eine unveröffentlichte Test- oder Entwicklungsseite muss darum genauso abgesichert werden wie die Hauptseite.
Wie ein Bot eine Seite findet, die niemand verlinkt hat
Entwicklungsseiten heissen fast immer nach demselben Muster: dev.firma.ch, staging.firma.ch, test.firma.ch. Scanner probieren solche Präfixe systematisch gegen bekannte Domains durch, unabhängig von Google oder Suchmaschinen. Ist die Subdomain per DNS aufgelöst und ohne Passwortschutz erreichbar, taucht sie irgendwann in einer solchen Liste auf – meist ohne dass am eigentlichen Betrieb der Website etwas Auffälliges passiert.
Es geht aber oft noch schneller, und dieser Weg wird regelmässig übersehen: Jedes ausgestellte TLS-Zertifikat wird öffentlich protokolliert. Sobald Sie für dev.firma.ch ein Zertifikat beziehen – etwa automatisch über Let’s Encrypt –, erscheint der vollständige Hostname innert Minuten in den öffentlich durchsuchbaren Certificate-Transparency-Protokollen. Jeder kann sie abfragen. Die Subdomain ist damit bekannt, bevor der erste Mensch sie je aufgerufen hat.
Das ist kein Fehler des Systems, sondern seine Funktion: Certificate Transparency existiert, damit gefälschte Zertifikate auffallen. Nur ist die Nebenwirkung, dass «geheime» Hostnamen keine Geheimnisse sind.
Warum ausgerechnet die Formulare das Ziel sind
Der Bot wollte keine echten Anfragen stellen. Die meisten Felder enthielten Zufallszeichen oder generische Test-Adressen – typisch für automatisierte Prüfungen, ob sich über ein Formularfeld die Datenbank manipulieren lässt (sogenannte SQL-Injection-Versuche). Formulare sind für solche Scanner attraktiv, weil sie eine der wenigen Stellen einer Website sind, an denen Eingaben tatsächlich verarbeitet und gespeichert werden – anders als eine reine Textseite.
Ein konkreter Fall aus der Praxis: Eine Firmenwebsite mit Kontakt-, Bewerbungs- und Serviceformularen betrieb parallel eine öffentlich erreichbare Entwicklungsseite mit identischem Code – auch identischen Formularen. In einer einzigen Nacht sendete ein automatisierter Bot rund 16’000 Formular-Absendungen an diese Entwicklungsseite, im Schnitt etwa eine pro Sekunde, über vier Stunden ohne Unterbruch. Die Hauptseite blieb im selben Zeitraum praktisch unberührt.
Was der Bot erreichte – und was nicht
Der bestehende Spam-Filter blockierte rund zwei Drittel der Anfragen automatisch. Das verbleibende Drittel – knapp 5’400 Mails – landete trotzdem im Postfach der zuständigen Stelle. Kein einziger Datensatz ging dabei verloren, keine Datenbank wurde kompromittiert: Die Schutzmechanismen, die für die Hauptseite gedacht waren, hielten. Der Schaden blieb auf ein überfülltes Postfach und kurzzeitige Serverlast beschränkt.
Das ist die eigentliche Lehre: Die Entwicklungsseite war nicht ungeschützt, weil ihre Firewall schwächer war – sie war ungeschützt, weil niemand daran gedacht hatte, dass sie überhaupt öffentlich erreichbar sein durfte. «Wird schon niemand finden» ist kein Sicherheitskonzept, sondern eine Wette, die ein Scanner-Netzwerk irgendwann gewinnt.
Was diesen Vorfall von einem echten Sicherheitsleck unterscheidet:
- Kein Zugriff auf echte Kundendaten – die Formulare wurden durchprobiert, nicht die Datenbank ausgelesen.
- Keine Serverkompromittierung – der Bot blieb auf der Ebene eines normalen Website-Besuchers, nur in absurder Frequenz.
- Kein gezielter Angriff auf die Firma – die IP-Adresse gehörte zu einem Rechenzentrum, das typischerweise für Massen-Scans gemietet wird; die Auswahl der Zieladresse war generisch, nicht persönlich.
Eine Entwicklungsseite ohne Passwortschutz ist keine unsichtbare Seite – sie ist eine Seite, die noch niemand gefunden hat.
Welche Massnahme wovor schützt – und wovor nicht
Nicht jede naheliegende Massnahme wirkt, und zwei davon sind sogar kontraproduktiv:
| Massnahme | Schützt vor | Schützt nicht vor |
|---|---|---|
| Passwortschutz auf Serverebene (Basic Auth) | jedem Zugriff, bevor die Website überhaupt startet | nichts – das ist die wirksame Massnahme |
robots.txt mit Disallow | nichts | Scanner ignorieren sie; schlimmer: die Datei nennt den Pfad, den man verstecken wollte |
noindex-Angabe | dem Erscheinen in der Google-Suche | Zugriff, Formular-Spam, Scannern |
| Nur intern kommunizierte Adresse | nichts | Certificate-Transparency-Protokolle, Muster-Raten, DNS-Auswertung |
| IP-Sperre / VPN-Zwang | Zugriff von aussen | wirkt, ist aber aufwendiger als Basic Auth |
| Rate-Begrenzung am Formular | Massen-Absendungen | dem Zugriff selbst |
Wie Sie Ihre Entwicklungsseite prüfen und absichern
- Herausfinden, welche Subdomains überhaupt existieren. Fragen Sie die Certificate-Transparency-Protokolle für Ihre Domain ab (etwa über
crt.sh). Dort steht jeder Hostname, für den je ein Zertifikat ausgestellt wurde – oft mehr, als im Haus bekannt ist. Vergessene Staging-Umgebungen früherer Agenturen tauchen genau hier auf. - Jede gefundene Adresse im privaten Fenster öffnen. Erscheint die Seite ohne Login, ist sie öffentlich – unabhängig davon, ob sie irgendwo verlinkt ist.
- Passwortschutz auf Serverebene setzen, nicht in der Anwendung. Bei Apache eine
.htaccessmitAuthType Basicund einer.htpasswd-Datei; bei Nginxauth_basic. Er greift, bevor PHP, WordPress oder ein Formular überhaupt geladen werden – und schützt damit auch vor Lücken, die Sie noch gar nicht kennen. - Prüfen, ob der Schutz wirklich greift, und zwar nicht nur auf der Startseite: Rufen Sie eine Unterseite, das Formular-Ziel und die Admin-Anmeldung direkt auf. Ein Schutz, der nur den Einstieg absichert, ist keiner.
- Die Spam-Abwehr gleich scharf stellen wie auf der Hauptseite – nicht laxer, «weil es ja nur zum Testen ist». Und eine Rate-Begrenzung setzen, die auffällig viele Absendungen aus derselben Quelle stoppt.
Zwei Fallstricke, die den Schutz aushebeln:
- Basic Auth blockiert auch Ihre Werkzeuge. Webhooks, Deployment-Skripte, Zahlungs-Rückmeldungen und Vorschau-Funktionen scheitern plötzlich still. Wer das nicht bedenkt, deaktiviert den Schutz nach dem dritten Ärger wieder. Nehmen Sie gezielt einzelne Pfade aus, statt den Schutz ganz abzuschalten.
- Die Seite ist über die IP-Adresse weiterhin erreichbar. Wer den Schutz nur an den Hostnamen hängt, lässt die Tür offen, wenn der Server direkt über seine IP angesprochen wird. Der Schutz gehört an den Server, nicht an den Namen.
Ihre Testseite ist öffentlich, auch wenn Sie sie nie jemandem gezeigt haben
Fast jede Firma hat irgendwo eine zweite Website: eine Testversion, an der die Agentur den nächsten Umbau vorbereitet. Sie ist nicht verlinkt, sie steht nicht bei Google, niemand kennt die Adresse. Genau deshalb wird sie stiefmütterlich behandelt – kein Passwort, ältere Software, die Sicherheitseinstellungen etwas lockerer.
Das Missverständnis dabei ist, dass «nicht verlinkt» und «nicht auffindbar» dasselbe wären. Sind sie nicht. Es gibt Programme, die den ganzen Tag nichts anderes tun, als Adressen durchzuprobieren – und die naheliegenden Namen wie «test» oder «dev» stehen ganz oben auf ihrer Liste. Dazu kommt eine technische Eigenheit: Sobald eine Adresse ein Sicherheitszertifikat bekommt, wird sie in einem öffentlichen Verzeichnis eingetragen. Ihre geheime Testseite steht dort, bevor der erste Mensch sie aufgerufen hat.
Was dann passiert, ist selten dramatisch und trotzdem lästig. In einem Fall, den ich begleitet habe, schickte ein Programm in einer Nacht rund 16’000 Formular-Absendungen an eine solche Testseite. Nichts wurde gestohlen, keine Datenbank geknackt – aber gut 5’400 Nachrichten landeten in einem Postfach, das am nächsten Morgen jemand von Hand aufräumen durfte.
Drei Dinge, die Ihre Agentur voraussetzt, ohne sie zu erklären
Entwicklungs- oder Testseite
Eine zweite, vollständige Kopie Ihrer Website, auf der Änderungen ausprobiert werden, bevor sie live gehen. Sie hat meist eine Adresse wie test.ihrefirma.ch und enthält denselben Programmcode – und damit dieselben Formulare und dieselben Schwachstellen.
Scanner
Ein Programm, das automatisch und ohne Ziel eine Adresse nach der anderen abklappert und ausprobiert, ob sich etwas findet. Es sucht nicht Sie. Es sucht irgendjemanden, bei dem etwas offen steht – und arbeitet dabei rund um die Uhr.
Passwortschutz auf Serverebene
Ein Passwort, das der Server abfragt, bevor die Website überhaupt startet. Das ist der Unterschied zum Login Ihrer Website: Dieser Schutz greift schon vor der Haustür, nicht erst im Flur. Er kostet wenige Minuten Einrichtung und schliesst auch Lücken, von denen noch niemand weiss.
Warum ich Testseiten gleich behandle wie die Hauptseite
«Wird schon niemand finden» ist kein Sicherheitskonzept, sondern eine Wette. Sie geht meistens gut aus, und deshalb wird sie immer wieder eingegangen – bis sie einmal nicht gut ausgeht.
Ich argumentiere hier ungern mit dem Schreckensszenario, denn das ist gar nicht nötig. Technisch ist die Sache in wenigen Minuten erledigt: ein Passwort auf Serverebene, und die Testseite ist von aussen nicht mehr erreichbar. Es gibt keinen sinnvollen Grund, das nicht zu tun.
Wirtschaftlich ist die Rechnung noch klarer. Die Einrichtung kostet Minuten. Die Aufräumarbeit nach einem solchen Vorfall kostet einen halben Arbeitstag – und im schlechteren Fall reden Sie danach mit Ihrem Datenschutzverantwortlichen darüber, welche Daten auf der vergessenen Testkopie eigentlich lagen. Genau das ist der Punkt, den ich meist zuerst anspreche: Auf Testseiten liegen erstaunlich oft echte Kundendaten, weil man «zum Testen mal die Live-Datenbank kopiert» hat.
Was ich Ihnen nicht verspreche: dass Sie mit einem Passwort auf der Testseite sicher sind. Sie schliessen damit eine Tür, die weit offen stand – nicht mehr, aber auch nicht weniger. Es ist die günstigste Massnahme mit der besten Wirkung, die ich in diesem Bereich kenne.
Häufige Fragen
Reicht ein guter Spam-Filter nicht auch ohne Passwortschutz?
Ein Spam-Filter reduziert die Menge, verhindert aber nicht den Zugriff selbst. Im beschriebenen Fall blockierte der Filter zwei Drittel der Anfragen – das verbleibende Drittel kam trotzdem durch. Passwortschutz verhindert den Zugriff vollständig, bevor überhaupt etwas gefiltert werden muss.
Genügt es, die Seite per `robots.txt` oder `noindex` auszuschliessen?
Nein, und beides schützt gar nicht vor Zugriff. noindex hält die Seite nur aus der Google-Suche heraus. Die robots.txt ist sogar kontraproduktiv: Sie ist öffentlich lesbar und nennt genau die Pfade, die man verbergen wollte – Scanner halten sich ohnehin nicht daran.
Lohnt sich der Aufwand für eine Seite, die sowieso bald abgeschaltet wird?
Ja, gerade dann. Entwicklungs- und Staging-Seiten existieren oft länger als geplant und werden erfahrungsgemäss seltener gepflegt als die Hauptseite. Ein einmal eingerichteter Passwortschutz auf Serverebene kostet Minuten und bleibt bestehen, solange die Subdomain existiert.
Woran erkenne ich, ob meine eigene Entwicklungsseite betroffen sein könnte?
Prüfen Sie, ob sich dev., staging. oder test. vor Ihrer Domain im Browser ohne Login öffnen lässt. Zusätzlich lohnt eine Abfrage der Certificate-Transparency-Protokolle für Ihre Domain – dort stehen auch die Subdomains, an die im Haus niemand mehr denkt.
Sollte ich nach einem solchen Vorfall auch die Hauptseite prüfen?
Ja. Wenn dieselbe Schwachstelle auf der Hauptseite ebenfalls möglich wäre, sollte sie unabhängig vom konkreten Vorfall geschlossen werden – der Bot hat diesmal die Entwicklungsseite gewählt, ein anderer könnte es beim nächsten Mal nicht tun.
