«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.
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.
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.
Was das über den Wert von «unsichtbar» aussagt
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.
Was tatsächlich schützt
Drei Massnahmen schliessen diese Lücke zuverlässig, ohne die Arbeit auf der Entwicklungsseite zu behindern:
- Passwortschutz auf Serverebene (HTTP Basic Auth) für alle Dev-/Staging-Subdomains – wirkt bereits, bevor die eigentliche Website überhaupt lädt.
- Gleich scharfe Spam-Filter-Einstellungen wie auf der Hauptseite, statt einer laxeren Konfiguration «weil es ja nur zum Testen ist».
- Automatische Sperre für IP-Adressen, die in kurzer Zeit ungewöhnlich viele Formulare absenden – eine einfache Rate-Begrenzung fängt genau das Muster ab, das einen manuellen Bot von einem echten Besucher unterscheidet.
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.
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 erfahrungsweise 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. Ist das der Fall, ist die Seite öffentlich erreichbar – unabhängig davon, ob sie irgendwo verlinkt ist oder in Suchmaschinen erscheint.
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.