Kann URL-Userinfo Ihr API-Ziel verbergen?

Ein Agent, der eine beliebige URL akzeptiert, kann an ein Ziel gelenkt werden, das sein Betreiber nicht vorgesehen hat. URL-Userinfo erleichtert diesen Fehler, weil sie einen vertrauten Hostnamen vor ein @-Zeichen setzt, während das tatsächliche Ziel dahinter steht. Wenn Ihr Freigabebildschirm, Ihre Allowlist oder Ihre Audit-Ansicht die gesamte Zeichenfolge als hostähnliche Bezeichnung behandelt, kann eine Anfrage genehmigt wirken und trotzdem an einen anderen Server gehen.

Behandeln Sie Userinfo bei ausgehenden API-Aktionen als unzulässige Eingabe, sofern es keinen eng gefassten, dokumentierten Kompatibilitätsgrund gibt. Analysieren Sie die URL einmal an der Grenze, weisen Sie ein nicht leeres Userinfo-Feld zurück, bevor Anmeldedaten in die Anfrage gelangen, und treffen Sie alle späteren Entscheidungen anhand der analysierten Felder. Das ist kein exotischer URL-Trick. Hier trifft gewöhnliche Syntax auf eine Prüfansicht, die Menschen zu viel Satzzeichen in zu kurzer Zeit lesen lässt.

Der Hostname steht nach dem letzten At-Zeichen

In einer absoluten HTTP-URL steht die Authority zwischen // und dem nächsten /, ? oder #. RFC 3986 beschreibt sie als optionale Userinfo, dann @, dann Host und optionalen Port. Der Host ist also nicht der Text, der zuerst nach // erscheint.

Betrachten Sie diese Anfrage:

https://[email protected]/v1/charges

Wer nur über den Anfang schaut, erkennt vielleicht api.example.com und liest nicht weiter. Ein konformer URL-Parser trennt sie so auf:

scheme:   https
userinfo: api.example.com
host:     collector.invalid
port:     443
path:     /v1/charges

Die TCP-Verbindung und die TLS-Prüfung des Hostnamens verwenden collector.invalid. Die Zeichenfolge vor @ benennt nicht den entfernten Server. Sie ist Userinfo, ein älterer Teil der URL-Grammatik, der früher für Namen und Passwörter gedacht war.

Dasselbe Problem erscheint in einer vertrauter wirkenden Form:

https://billing.example.com:[email protected]/invoices

Alles vor @ ist weiterhin Userinfo, einschließlich des Doppelpunkts und des Textes danach. Der entfernte Host bleibt evil.invalid. Ein Prüfer kann das Ziel nicht sicher aus der ersten hostnameähnlichen Teilzeichenfolge einer Roh-URL ableiten.

Versuchen Sie nicht, das Problem zu lösen, indem Sie Prüfern beibringen, auf dieses Zeichen zu achten. Menschen machen diesen Fehler bei Incident-Reviews, am Ende eines langen Tages und wenn ein Agent viele Aktionsanfragen erzeugt. Eine Kontrolle, die fehlerfreie visuelle Analyse voraussetzt, ist schwach.

Der von Browsern und vielen Laufzeitumgebungen verwendete URL-Standard führt bei besonderen Schemas wie HTTPS praktisch zum selben Ergebnis: analysierte Benutzername- und Passwortfelder sind vom Hostnamen getrennt. Das genaue Verhalten von Parsern kann bei fehlerhaften Eingaben und Escaping abweichen. Deshalb sollten Sie mit der Laufzeitumgebung analysieren, die die Anfrage auch sendet. Validieren Sie nicht mit einer Bibliothek und führen Sie dann mit einer anderen aus, die andere Zeichenfolgen akzeptiert.

Eine nützliche Regel ist einfach: Nur ein analysierter Hostname darf entscheiden, wohin eine Anfrage gehen darf. Der URL-Rohtext ist ein Beleg, keine Autorität.

Userinfo schafft erst ein Prüfproblem, dann ein Netzwerkproblem

Der Netzwerk-Client weiß normalerweise, wohin er geht. Der Fehler entsteht früher, wenn eine Person oder Kontrolle die falsche Darstellung dieses Ziels genehmigt.

Ein typischer Agentenablauf hat mehrere Stellen, an denen Rohtext durchsickern kann: das Tool-Aufrufargument, eine Freigabekarte, ein Sitzungsjournal, eine Fehlermeldung und eine Benachrichtigung. Wenn eine dieser Ansichten Calling api.example.com meldet, weil sie Text vor @ extrahiert, vermittelt sie dem Betreiber etwas Falsches. Wenn eine andere Ansicht die volle Zeichenfolge protokolliert, sie aber nach einer festen Breite kürzt, kann der tatsächliche Host vollständig verschwinden.

Das ist auch wichtig, wenn der Agent keine Anmeldedaten für das Ziel besitzt. Eine ausgehende Anfrage kann Nutzerdaten, einen signierten Anfrage-Body, ein Bearer-Token aufgrund einer zu breiten Regel mitführen oder einfach eine interne Adresse erreichen, die nie Agentenverkehr erhalten sollte. Die Geschichte der Anmeldedaten bekommt Aufmerksamkeit, weil sie greifbar ist. Die Integrität des Ziels braucht dieselbe Sorgfalt.

Oft verschwimmt der Unterschied zwischen sicherer URL-Anzeige und sicherem URL-Transport. Ein @ in einer HTML-Ansicht zu maskieren kann eine Seite weniger verwirrend machen, bestimmt jedoch nicht, wohin ein HTTP-Client verbindet. Umgekehrt kann ein Parser den Netzwerkaufruf korrekt ausführen, während eine schlecht gestaltete Freigabeansicht Menschen dazu verleitet, den falschen Host zu genehmigen. Sie brauchen eine korrekte Transportentscheidung und eine ehrliche Anzeige.

Ersetzen Sie @ in der gespeicherten Anfrage nicht durch ein harmloses Zeichen und fahren Sie fort. Das verbirgt die Eingabe, die zur Ablehnung geführt hat, und erschwert spätere Untersuchungen. Bewahren Sie die ursprüngliche Zeichenfolge als Roh-Eingabe auf, markieren Sie die Anfrage als abgelehnt und protokollieren Sie den analysierten Grund, ohne eingebettete Anmeldedaten in ein lesbares Journal zu schreiben.

Die Anzeige sollte mit einem separaten Zielfeld beginnen, etwa Host: collector.invalid, und die ursprüngliche URL darunter zeigen. Diese Reihenfolge macht aus einem Satzzeichenrätsel eine direkte Aussage. Sie gibt Prüfern außerdem ein stabiles Feld, das sie mit den angeforderten Anmeldedaten oder der vorgesehenen Integration vergleichen können.

Userinfo zurückweisen ist sicherer als sie zu reparieren

Für ein Gateway für Agentenaktionen sollte die klare Voreinstellung sein, jede ausgehende HTTP-URL zurückzuweisen, deren analysiertes Benutzername- oder Passwortfeld nicht leer ist. Die meisten API-Integrationen senden Anmeldedaten ohnehin in Anfrage-Headern oder verwenden einen Injektor für Anmeldedaten. URL-Userinfo vergrößert die Angriffsfläche, ohne ein übliches API-Bedürfnis zu erfüllen.

Die Reihenfolge der Validierung ist wichtig. Analysieren Sie zuerst die ursprüngliche Zeichenfolge. Weisen Sie fehlerhafte URLs, nicht unterstützte Schemas und Userinfo zurück, bevor Sie Hosts gegen eine Allowlist prüfen, Freigaben anzeigen, Weiterleitungen verfolgen, DNS auflösen oder Anmeldedaten auswählen. So vermeiden Sie, eine Anfrage als geeignet darzustellen, obwohl Sie später einen Teil davon verwerfen.

Dieser Pseudocode beschreibt die Regel:

u = parse_absolute_url(raw_url)

if u.scheme not in {"https", "http"}:
    deny("unsupported scheme")

if u.username != "" or u.password != "":
    deny("URL userinfo is not accepted")

host = normalize_hostname(u.hostname)
if host == "":
    deny("missing hostname")

if not destination_is_allowed(u.scheme, host, u.port):
    deny("destination is not allowed")

send(u)

Der Parser muss strukturierte Felder liefern. An @ aufzuteilen, ein Präfix zu entfernen oder nach einem Hostnamen-Teilstring zu suchen, scheitert an gewöhnlichen Varianten. Eine Authority kann in der Roh-Eingabe mehr als ein @ enthalten. Ein Parser entscheidet, welches Trennzeichen syntaktisch ist und ob frühere Zeichen zu Userinfo gehören. Er behandelt auch IPv6-Literale in Klammern, explizite Ports, Prozentcodierung und leere Bestandteile verlässlicher als handgeschriebene String-Logik.

Wenn Sie Userinfo zurückweisen, erhält der Aufrufer eine klare Korrektur: Verwenden Sie https://api.example.com/path und übergeben Sie die HTTP-Authentifizierung über den vorgesehenen Weg für Anmeldedaten. Der Aufrufer muss nicht raten, ob Sie https://name@host stillschweigend in https://host geändert haben.

Einen Kompatibilitätsfall sollten Sie anerkennen. Manche alten URLs betten Basic Authentication als https://name:secret@host/path ein. Wenn eine Migration solche URLs verarbeiten muss, tun Sie das in einem einmaligen Importpfad, der die Anmeldedaten in geschützten Speicher überführt, den analysierten Host bestätigt und die Quellzeichenfolge aus dem Importdatensatz löscht, soweit die Richtlinie es erlaubt. Lassen Sie die Laufzeit-Aktions-API solche URLs nicht dauerhaft akzeptieren. Temporärer Kompatibilitätscode wird leicht zu permanenter Angriffsfläche.

Host-Allowlists brauchen analysierte Labels, keine freundlich wirkenden Zeichenfolgen

Eine Allowlist für Ziele sollte normalisierte analysierte Hostnamen vergleichen und keine Teilstrings in der Roh-URL suchen. Die Regel raw_url.includes("api.example.com") akzeptiert sowohl https://[email protected] als auch https://api.example.com.evil.invalid. Keine dieser Anfragen geht an api.example.com.

Exakter Host-Abgleich ist die am wenigsten überraschende Regel. Wenn eine Integration nur api.example.com braucht, erlauben Sie diesen Namen und weisen Sie jeden anderen Hostnamen zurück. Wenn sie tatsächlich Subdomains braucht, vergleichen Sie DNS-Labels: Erlauben Sie example.com und Namen, die auf .example.com enden, aber weisen Sie badexample.com und example.com.evil.invalid zurück.

Eine klare Implementierungsform sieht so aus:

function allowedHost(host, root) {
  const h = host.toLowerCase().replace(/\.$/, "")
  const r = root.toLowerCase().replace(/\.$/, "")
  return h === r || h.endsWith("." + r)
}

Dieser Code setzt voraus, dass der URL-Parser bereits einen Hostnamen geliefert hat und der Aufrufer Userinfo schon zurückgewiesen hat. Er sollte keine vollständige URL erhalten. Wenn diese Verantwortlichkeiten getrennt bleiben, kann ein späterer Aufrufer nicht versehentlich eine Authority-Zeichenfolge mit Port, Benutzernamen oder @-Zeichen übergeben.

Auch bei internationalisierten Domains brauchen Sie eine Entscheidung. Browser serialisieren Hostnamen häufig per IDNA-Verarbeitung in ASCII, während Nutzern Unicode-Text angezeigt werden kann. Verwenden Sie zum Vergleich dieselbe kanonische Form wie Ihr Anfrage-Client und zeigen Sie bei Abweichungen sowohl den kanonischen Host als auch eine lesbare Form an. Behaupten Sie nicht, zwei Zeichenfolgen bezeichneten dieselbe Domain, nur weil sie in einer Proportionalschrift ähnlich aussehen.

IP-Adressen brauchen eine eigene Regel. Eine Hostnamen-Allowlist macht ein IP-Literal nicht automatisch sicher, und die DNS-Auflösung nach der Genehmigung kann die Adresse ändern, die ein Hostname erreicht. Wenn Ihr Bedrohungsmodell den Zugriff auf lokale Dienste einschließt, entscheiden Sie ausdrücklich, ob private, Loopback-, Link-Local- und lokale IPv6-Adressen erlaubt sind. Userinfo zurückzuweisen ist nötig, löst Server-Side Request Forgery aber nicht allein.

Auch Ports haben Bedeutung. https://api.example.com:8443 kann ein gültiger Partner-Endpunkt oder ein unerwarteter Administrationsdienst sein. Erfassen Sie den effektiven Port und beziehen Sie ihn in Freigabeentscheidungen ein, wenn die Integration einen beschränkt. Ein Host-Label allein beschreibt nicht das vollständige Netzwerkziel.

Weiterleitungen müssen dieselbe Prüfung durchlaufen

Eine erlaubte ursprüngliche URL macht nicht jedes Weiterleitungsziel erlaubt. HTTP-Weiterleitungen sind neue Zielanweisungen vom entfernten Server. Ein Agenten-Gateway sollte jedes davon analysieren und autorisieren, bevor es ihm folgt.

Angenommen, ein Agent ruft https://api.example.com/export an. Dieser Host antwortet mit 302 und diesem Location-Wert:

https://[email protected]/download?id=42

Ein Client, der Weiterleitungen automatisch folgt, verbindet sich als Nächstes mit receiver.invalid. Wenn das Gateway nur die erste URL genehmigt hat, beschreiben seine Allowlist und sein Freigabebildschirm nicht mehr die Netzwerkaktion, die tatsächlich stattfand.

Behandeln Sie Weiterleitungen als Schleife mit einem für Ihren Client gewählten Limit. Lösen Sie jeden Location-Wert als relative Referenz gegen die aktuell genehmigte URL auf, analysieren Sie die resultierende absolute URL, wenden Sie dieselben Regeln für Schema, Userinfo, Host, Port und Adresse an und entscheiden Sie dann über die Fortsetzung. Erfassen Sie sowohl die Quellantwort als auch das analysierte Weiterleitungsziel.

Leiten Sie Anmeldedaten standardmäßig nicht über Hosts hinweg weiter. HTTP-Client-Bibliotheken unterscheiden sich darin, ob sie einen Authorization-Header nach einer hostübergreifenden Weiterleitung behalten. Benutzerdefinierte Header können sich wiederum anders verhalten. Das sicherste Verhalten eines Gateways bindet Anmeldedaten an ein bestimmtes genehmigtes Ziel und erstellt erst dann eine neue ausgehende Anfrage, wenn das Weiterleitungsziel die Autorisierung besteht. Eine Weiterleitung von einem Host eines Anbieters zu einem anderen kann erwartet sein, sollte jedoch eine ausdrückliche Regel sein und kein Zufall von Bibliotheksvorgaben.

Auch die Behandlung der Methode braucht Aufmerksamkeit. Eine 303-Antwort ändert eine spätere Anfrage häufig in GET, während 307 und 308 Methode und Body beibehalten. Wenn ein Agent einen sensiblen Body per POST sendet, kann eine Weiterleitung mit beibehaltener Methode ihn an ein anderes Ziel schicken. Erfassen Sie die verwendete Methode bei jedem Sprung und zeigen Sie das Endziel im Aktionsergebnis an.

Sie können einen Client auch so konfigurieren, dass er Weiterleitungen nicht folgt. Das ist für eng begrenzte API-Tools sinnvoll. Geben Sie die Weiterleitungsantwort an den Agenten zurück und verlangen Sie, dass er das nächste Ziel ausdrücklich anfragt. Das erzeugt ein weiteres Freigabeereignis, gibt dem Betreiber aber einen klaren Punkt, um einen Hostwechsel zu bewerten. Für breit angelegte HTTP-Unterstützung sind automatische Weiterleitungen nur vertretbar, wenn jeder Sprung dieselbe Prüfung durchläuft.

Anmeldedaten erst nach der Zielvalidierung auswählen

Die gefährliche Reihenfolge lässt sich einfach beschreiben: Wählen Sie Anmeldedaten, weil die Roh-URL einen vertrauten Servicenamen enthält, analysieren Sie dann die URL und senden Sie anschließend die Anfrage. Ein @-Trick kann den vertrauten Text zu Userinfo machen, während das ausgewählte Geheimnis zu einem vom Angreifer kontrollierten Host gelangt.

Die sichere Reihenfolge ist ebenso klar. Analysieren und validieren Sie zuerst die URL. Autorisieren Sie dann Schema, Host, Port und einen möglichen Weiterleitungsstatus. Suchen Sie erst danach nach Anmeldedaten, die an dieses genehmigte Ziel gebunden sind, und fügen Sie sie in die ausgehende Anfrage ein. Halten Sie dieses Geheimnis aus Tool-Argumenten, Agentenspeicher und Rückgabewerten heraus.

Das löst auch einen weniger dramatischen, aber häufigen Konfigurationsfehler. Anmeldedaten für api.example.com sollten nicht automatisch an uploads.example.com gehen, auch wenn beide Namen unter derselben übergeordneten Domain liegen. Unterschiedliche Hosts haben oft unterschiedliche Eigentümer, TLS-Terminierung, Protokollierung oder Berechtigungsbereiche. Beginnen Sie mit einer exakten Hostbindung. Erweitern Sie den Abgleich nur, wenn die Integration begründet, warum sie mehr braucht.

Das Einfügen über Header ist URL-Userinfo vorzuziehen, weil es Ziel und Authentifizierung trennt. Ein Anfragedatensatz kann festhalten, dass ein Autorisierungs-Header eingefügt wurde, ohne dessen Wert zu speichern. Der Agent erhält die Antwort, die er für seine Arbeit braucht, kein wiederverwendbares Geheimnis.

Sallyport hält API- und SSH-Anmeldedaten getrennt im verschlüsselten Tresor und führt die ausgehende Aktion aus, ohne diese Anmeldedaten dem Agenten offenzulegen. Bei jedem Gateway mit diesem Modell schließt das Zurückweisen von Userinfo vor der Suche nach Anmeldedaten die Lücke zwischen dem vom Betreiber beabsichtigten Ziel und dem Host, der die Anfrage empfängt.

Vertrauen Sie auch keinem vom Agenten gelieferten Anfrage-Header, um das Ziel zu bestimmen. Der Host-Header, die HTTP/2-Authority, der URL-Host, die Proxy-Konfiguration und der TLS-Servername können je nach Client zusammenwirken. Ein Gateway sollte die Verbindungseinstellungen selbst verwalten und aus der validierten analysierten URL ableiten. Wenn Sie benutzerdefinierte Header erlauben, behandeln Sie sie als Anfrageinhalt, nicht als Berechtigung, das Routing umzuschreiben.

Freigabekarten sollten das analysierte Ziel zuerst zeigen

Eine Freigabekarte sollte drei konkrete Fragen beantworten, ohne dass Lesende eine URL rekonstruieren müssen: Welcher Prozess hat angefragt, welche Aktion läuft und welcher Host empfängt sie? Platzieren Sie analysierten Hostnamen und Port in einer eigenen Zielzeile. Zeigen Sie HTTP-Methode und Pfad daneben. Die ursprüngliche URL dient als ergänzender Beleg, nicht als einziges Signal für das Ziel.

Für die zuvor verwendete fehlerhaft wirkende Anfrage könnte eine nützliche Karte so aussehen:

Process: signed agent process
Action:  POST /v1/charges
Host:    collector.invalid:443
Result:  blocked because URL userinfo is present
Input:   https://[email protected]/v1/charges

Sie sollte api.example.com nicht als Badge anzeigen, das aus der linken Seite der Authority abgeleitet wurde. Ebenso wenig sollte sie nur External HTTP request sagen, denn das bietet Menschen keine sinnvolle Grundlage für eine Entscheidung.

Sitzungsbezogene und aufrufbezogene Genehmigungen lösen unterschiedliche menschliche Probleme. Eine Sitzungsfreigabe sagt, dass ein bestimmter laufender Prozess ein Gateway während seiner Lebensdauer nutzen darf. Eine Freigabe pro Aufruf sagt, dass eine besonders sensible Anmeldedatenverwendung oder Aktion eine neue menschliche Entscheidung braucht. Beides ersetzt keine grundlegende URL-Validierung. Ein Prozess, dem Sie vertrauen, kann dennoch durch einen nicht vertrauenswürdigen Issue-Kommentar, ein Paketmetadatenfeld oder eine erzeugte Konfigurationsdatei manipuliert werden.

Sallyports Entscheidungsleiter hält einen gesperrten Tresor als absoluten Stopp vor und nutzt dann Sitzungsautorisierung sowie optional eine Bestätigung pro Geheimnis. Diese Struktur funktioniert am besten, wenn fehlerhafte Ziele scheitern, bevor sie eine Freigabekarte erreichen. Ein Betreiber sollte nicht entscheiden müssen, ob ein Stück URL-Satzzeichen den Endpunkt verändert hat.

Formulieren Sie Ablehnungsmeldungen konkret. Userinfo is not allowed in outbound URLs sagt einem Agentenentwickler, was zu beheben ist. Invalid request führt zu Wiederholungen, improvisiertem Escaping und Druck, die Validierung abzuschwächen. Geben Sie kein Passwort wieder, falls der Parser eines extrahiert hat. Die Meldung kann die verbotene Komponente nennen, ohne ihren Inhalt zu reproduzieren.

Tests sollten täuschende Eingaben nutzen, nicht nur gültige URLs

Eine Testsuite für Validierung braucht Beispiele, die menschliche Leser und einfache String-Prüfungen täuschen sollen. Dass https://api.example.com/v1 akzeptiert wird, beweist fast nichts über die Grenze, an der ein Agent beliebigen Text übermitteln kann.

Beginnen Sie mit Fällen wie diesen und prüfen Sie analysierten Host, Entscheidung und Begründung:

ALLOW  https://api.example.com/v1                 host=api.example.com
DENY   https://[email protected]/v1    reason=userinfo
DENY   https://name:[email protected]/v1     reason=userinfo
DENY   https://api.example.com.evil.invalid/v1    reason=host
DENY   https://api.example.com:444/v1             reason=port
DENY   https://[::1]/v1                           reason=address

Ergänzen Sie ein Weiterleitungs-Fixture. Lassen Sie einen erlaubten Testserver eine Weiterleitung ausgeben, deren Location Userinfo enthält, und prüfen Sie, dass der Client einen blockierten zweiten Sprung erfasst, ohne eine Anfrage an den Zielserver zu senden. Das deckt den häufigen Fehler auf, bei dem die Validierung der ursprünglichen URL in einem Codepfad liegt, die Behandlung von Weiterleitungen aber in einem Bibliotheks-Callback.

Testen Sie Prozentcodierung bewusst, gehen Sie aber nicht davon aus, dass jedes codierte @ gleich ist. In vielen Parsern bleibt %40 in einem Pfad Pfaddaten, während ein echtes @ in der Authority als Trennzeichen wirkt. Geben Sie die genaue Rohzeichenfolge in den Parser ein, den Sie produktiv verwenden, und prüfen Sie seine Felder. Die wichtige Invariante ist keine selbst geschriebene Dekodierregel. Sie lautet: Eine nicht leere analysierte Userinfo darf den Sender nicht erreichen.

Testen Sie auch die Darstellung in Protokollen und Freigaben. Eine Sicherheitskontrolle kann die korrekte Ablehnung treffen und trotzdem einen schlechten Betriebseintrag erzeugen, wenn die Anzeige den tatsächlichen Host kürzt oder analysierten Passworttext offenlegt. Snapshot-Tests für Zielzeilen lohnen sich, weil visuelle Regressionen oft durch harmlos wirkende Designänderungen entstehen.

Testen Sie schließlich die Audit-Kette und den Widerrufspfad rund um einen abgelehnten Aufruf. Eine Ablehnung sollte für Untersuchungen ausreichend sichtbar sein, darf jedoch niemals eingefügte Geheimnisse enthalten. Nützlich sind die Roh-Anfrage unter passenden Zugriffskontrollen, analysiertes Schema und Host, Entscheidungsgrund, Identität des aufrufenden Prozesses und die Tatsache, dass keine ausgehende Aktion erfolgte.

URL-Syntax ist keine Richtliniensprache

Einige Teams reagieren auf URL-Randfälle mit einem wachsenden Stapel von Ausnahmen: für diesen Anbieter einen Benutzernamen erlauben, für jene Umgebung einen besonderen Port akzeptieren, einer Weiterleitung vertrauen, wenn ein Header richtig aussieht, und bei jedem Vorfall einen String-Matcher patchen. Dieser Ansatz wirkt flexibel, weil er eine seltsame Anfrage nicht ablehnen muss. Er schafft jedoch Regeln, die niemand zuverlässig prüfen kann.

Halten Sie die Regel klein. Ausgehende Anfragen haben ein analysiertes Ziel. Userinfo wird zurückgewiesen. Erlaubtes Schema, Host, Port und Adressklasse sind ausdrücklich festgelegt. Weiterleitungen durchlaufen dieselben Prüfungen erneut. Anmeldedaten werden erst ausgewählt, nachdem das Ziel besteht. Jede Entscheidung erzeugt einen Eintrag, der den analysierten Host klar benennt.

Diese Regel wird einige alte URLs zurückweisen, die ein Browser akzeptieren könnte. Gut so. Ein autonomer Agent braucht nicht jede historische Besonderheit einer Browser-Adressleiste. Er braucht eine enge Schnittstelle, bei der sich Aktion, Ziel und Anmeldedaten nur schwer verwechseln lassen.

Wenn Sie diese Schnittstelle ändern müssen, machen Sie die Ausnahme als benannte Fähigkeit mit Tests und einer Entscheidung über ihr Ablaufdatum sichtbar. Vergraben Sie sie nicht in URL-Bereinigungscode. Die erste feindliche Eingabe findet den Unterschied zwischen Text, der wie ein Host aussieht, und dem Host, den Ihr Client tatsächlich kontaktiert.