Wenn der Server nicht 404 zurückgibt, ist es sehr einfach, durch Crawler alle privaten URLs herauszubekommen.
Dagegen gibt’s ja bspw. HTTP Auth.
Das verstehe ich nicht. »Nicht 404« trifft auch auf 403 zu.
Und eben damit wären wir doch wieder exakt bei Security through Obscurity – die Sicherheit deiner Information (diesmal nur der im URL enthaltenen) basiert darauf, dass sie niemand „kennt“.
Hier würde ich eher von Privacy sprechen als Security. Wenn einzelne URLs leaken, dann ist das eben so. Das kann schnell passieren, alleine schon durch Referrer. Ein Browser ist keine sichere, abgeschlossene Umgebung. Das ist immer noch ein weiter Unterscheid dazu, dass alle URLs und darin enthaltenen Informationen systematisch lesbar sind und vom Angreifer für Social Engineering oder zur Planung gezielter Angriffe benutzt werden können.
Ergo gehört diese Information für mich *nicht* in den URL, wenn sie derart sensibel ist.
Es redet auch niemand davon, dass die Information in der URL unglaublich geheim ist. Aber hinreichend sensibel, dass sie nicht crawlbar und maschinell auswertbar sein sollte.
Ein geschlossenes Forum beispielsweise wird früher oder später leaken, wenn »SEO-freundliche« URLs den Threadtitel oder gar Postinginhalt preisgeben. Trotzdem ist es nicht möglich, die einzelnen Threads maschinell zu erraten, weil die meisten geschlossenen Foren bei jeder nicht autorisierten Anfrage dieselbe Login-Seite zeigen. Natürlich ist es sinnvoll, solche URL-Generierung kurzerhand abzuschalten, wenn nicht unbedingt benötigt.
Private Repositories auf GitHub funktionieren ähnlich. Durch URL-Leaks kann an die Öffentlichkeit kommen, dass ein Unternehmen an einem $geheimenProjekt arbeitet oder einen Fork von $bekannteSoftware einsetzt. Aber es lässt sich nicht automatisiert erraten, weil GitHub 404s anstatt einer Login-Seite liefert. Dass GitHub konsequent mit sprechenden URLs anstatt mit Zufallsstrings arbeitet, ist ein Usability-Feature und wurde wichtiger als die Privatsphäre erachtet.
Mathias