# Wie eine API-Genehmigungskarte das tatsächliche Ziel anzeigt Eine prüfende Person kann eine HTTP-Aktion nicht anhand einer Zeichenfolge genehmigen, die lediglich wie ein Ziel aussieht. Die Karte muss das Anfrageziel anzeigen, das der Transport tatsächlich verwendet, nachdem die URL geparst wurde und bevor Zugangsdaten den Rechner verlassen. Das klingt selbstverständlich, bis ein Agent `HTTPS://API.EXAMPLE.TEST:443/%76%31/../admin` übermittelt, ein Client die URL akzeptiert und der Mensch nur eine verkürzte Bezeichnung wie `api.example.test` sieht. Eine solche Karte bittet nicht um informierte Zustimmung. Sie verlangt, dass man einem Renderer vertraut, der möglicherweise nicht mit dem HTTP-Stack übereinstimmt. Die Lösung besteht nicht darin, den Prüfenden jede Besonderheit der URL-Syntax beizubringen. Erstellen Sie stattdessen eine einzige kanonische Beschreibung der Anfrage, stellen Sie sie verständlich dar und sorgen Sie dafür, dass der Executor genau diese Beschreibung verwendet. Schema, Host, effektiver Port, Methode und Pfad sind das Minimum. Query-Werte, Weiterleitungen, vom Aufrufer kontrollierte Header und die Identität des Bodys gehören oft ebenfalls dazu, weil sie die Aktion ebenso stark verändern können. ## Wie eine Genehmigungskarte ein Ja verdient Eine Genehmigungskarte verdient nur dann ein Ja, wenn sie die Netzwerkaktion so benennt, dass die prüfende Person sie nachvollziehen kann. Ein Hostname allein ist eine Identitätsangabe, keine Beschreibung der Anfrage. `POST https://billing.example.test/v1/invoices/481/refund` sagt wesentlich mehr aus als `billing API` oder `example.test`. Setzen Sie die Aktionszeile an den Anfang und verwenden Sie immer dieselbe Reihenfolge: ```text POST https://billing.example.test/v1/invoices/481/refund ``` Darunter folgen unmittelbar die Details, die die Bedeutung verändern: ```text Authorization: injected from vault entry "billing-production" Query: dry_run=false Body: JSON, 214 bytes, sha256: 7b1f...c0a9 ``` Setzen Sie weder den Zugangswert noch einen Platzhalter für die Autorisierung oder einen freundlichen Namen der Integration an die Stelle des Ziels. Diese Bezeichnungen können helfen, den Kontext zu erkennen, sind aber kein Beleg für das Ziel. Die Methode gehört in die erste Zeile, weil sie die Konsequenz desselben Pfads verändert. `GET /exports/481` und `DELETE /exports/481` sind keine Varianten derselben Aktion. Es sind unterschiedliche Aktionen, die niemals unter einer einzigen Genehmigungsbezeichnung zusammenfallen dürfen. Der Pfad gehört ebenfalls in die erste Zeile, weil dort meist das API-Routing stattfindet. Eine Karte mit `api.example.test` zwingt die prüfende Person zu erraten, ob der Agent ein Profil liest, ein Zugriffstoken erstellt oder ein Projekt löscht. Das ist eine schlechte Nutzung einer Genehmigungsunterbrechung. ## Kanonisierung ist ein Darstellungsvertrag, kein Berechtigungsabgleich Die Kanonisierung beantwortet die Frage: «Was sollte ein Mensch für diese geparste Anfrage sehen?» Sie beantwortet nicht die Frage: «Welche Ziele sind erlaubt?» Teams vermischen diese Aufgaben oft und schaffen so eine spröde Allowlist, die sich als freundliche Formatierung tarnt. Erstellen Sie für eine Genehmigungskarte nach dem Parsen einen strukturierten Datensatz für das Ziel: ```json { "method": "POST", "scheme": "https", "host": "api.example.test", "port": 443, "port_display": null, "path": "/v1/invoices/481/refund", "query": "dry_run=false", "raw_url": "HTTPS://API.EXAMPLE.TEST:443/v1/invoices/481/refund?dry_run=false" } ``` Der Executor sollte dieselben strukturierten Felder oder eine daraus serialisierte URL verwenden. Parsen Sie nicht einmal für die Karte und übergeben Sie später die ursprüngliche Zeichenfolge an eine andere Bibliothek. Genau dort wird eine Prüfungsoberfläche zur Theaterkulisse. RFC 3986 unterscheidet mehrere sichere Kategorien der Normalisierung. Das Dokument behandelt Schema und Host als unabhängig von Groß- und Kleinschreibung, empfiehlt Großbuchstaben für Hexadezimalziffern in Prozentsequenzen und beschreibt das Entfernen von Punktsegmenten. Außerdem warnt es davor, URI-Bestandteile vor dem Dekodieren von Prozentsequenzen nicht zuerst zu parsen, weil eine Dekodierung zum falschen Zeitpunkt Daten in Trennzeichen verwandeln kann. Diese Warnung ist ein praktischer Hinweis für die Entwicklung und keine bloße Spezifikationsnotiz. Bewahren Sie zusätzlich einen Datensatz der rohen Agent-Eingabe auf. Er gehört ins Aktivitätsprotokoll und in eine Detailansicht für Untersuchungen ungewöhnlicher Anfragen. Er sollte die kanonische Aktionszeile nicht um die Aufmerksamkeit der prüfenden Person bringen. Eine einfache Regel hilft: Die Karte zeigt eine normalisierte Beschreibung, das Journal bewahrt Beschreibung und Eingabe auf, und Autorisierungsentscheidungen ersetzen keine expliziten Bereichsregeln. Das sind getrennte Datenprodukte. ## Zuerst parsen und Eingaben ablehnen, die der Transport nicht eindeutig erklären kann Ein URL-Parser gehört zur Sicherheitsgrenze, sobald ein Mensch seine Ausgabe genehmigt. Legen Sie für die unterstützten URL-Schemata ein Parserverhalten fest und machen Sie diesen Parser zur Quelle der Wahrheit für Darstellung und Ausführung. Bei gewöhnlichen HTTP-APIs sollten Sie Eingaben ablehnen, die Unklarheiten hinterlassen, statt besonders hilfreich sein zu wollen. Relative Verweise brauchen eine explizite Basis-URL, bevor sie einen Host haben. Fragmente werden nicht mit einer HTTP-Anfrage übertragen und sollten nicht so erscheinen, als beeinflussten sie den Server. Userinfo wie `https://alice@api.example.test/` ist in einem API-Genehmigungsprozess fast immer irreführend. Lehnen Sie sie ab, statt sie still zu verbergen. Verwenden Sie eine Parsing-Pipeline mit einem klaren Fehlerpunkt: 1. Akzeptieren Sie für den ausgehenden API-Kanal ausschließlich eine absolute `http`- oder `https`-URL. 2. Parsen Sie sie mit der URL-Implementierung, die der Aktions-Executor verwendet. 3. Lehnen Sie Userinfo, einen fehlenden Host, fehlerhafte Portwerte, nicht unterstützte Schemata und ungültige Prozentsequenzen ab. 4. Erstellen Sie die tatsächliche Anfrage aus den geparsten Bestandteilen und genehmigten Headern. 5. Stellen Sie die Karte aus diesen Bestandteilen dar und übermitteln Sie anschließend genau diese Anfrage. Versuchen Sie nicht, dies mit Zeichenkettenaufteilungen selbst zu bauen. Das erste `@`, `:`, `/`, `?` und `#` bedeutet nicht an jeder Position dasselbe. IPv6-Autoritäten benötigen eckige Klammern. Ein Doppelpunkt nach einer Klammer kann einen Port einleiten, während Doppelpunkte innerhalb der Klammern Teil der Adresse sind. Ein Parser kennt diesen Unterschied, ein kurzes reguläres Ausdrucksmuster meistens nicht. Der WHATWG URL Standard definiert das Parsen und Serialisieren von URLs, Hosts, Domains und IP-Adressen. Seine Sicherheitshinweise nennen auch die Verwirrung, die bidirektionaler Text zwischen Host und Pfad erzeugen kann, und empfehlen in diesem Fall, den Host allein darzustellen. Ein Sicherheitsprodukt sollte daraus die strengere Regel ableiten: Halten Sie die Autorität in jeder Karte optisch vom Pfad getrennt, nicht nur bei ungewöhnlichen Zeichenfolgen. Wenn die Aktionsschicht einen eigenen Client verwendet, müssen Sie mit einem Testkorpus nachweisen, dass er mit dem Parser übereinstimmt. Gehen Sie nicht davon aus, dass zwei ausgereifte Bibliotheken Leerzeichen, Backslashes, Unicode-Hostnamen oder ungewöhnliche numerische IP-Formen gleich tolerant behandeln. Übereinstimmung ist eine Eigenschaft, die getestet werden muss. ## Prozentsequenzen dekodieren, ohne die Route zu verändern Prozentkodierung erzeugt die gefährlichste Art irreführender URL: eine URL, die nach einer flüchtigen Dekodierung harmlos aussieht, für Router, Proxy oder vorgelagerten Dienst aber etwas anderes bedeutet. Betrachten Sie diese Pfade: ```text /v1/projects/%2E%2E/admin /v1/projects/%252E%252E/admin /v1/files/report%2Ffinal ``` Der erste enthält prozentkodierte Punkte. Der zweite enthält ein kodiertes Prozentzeichen gefolgt von `2E`, also eine andere Eingabe. Der dritte enthält einen kodierten Schrägstrich innerhalb eines Pfadsegments. Wenn die Darstellungsschicht alle drei Werte wiederholt dekodiert, bis lesbare Satzzeichen entstehen, kann sie eine Pfadstruktur anzeigen, die der Client nicht gesendet hat. RFC 3986 nennt einen eng begrenzten sicheren Fall: Prozentsequenzen für nicht reservierte Zeichen dürfen während der Normalisierung dekodiert werden. Nicht reservierte Zeichen sind Buchstaben, Ziffern, Bindestrich, Punkt, Unterstrich und Tilde. Reservierte Zeichen wie `/`, `?`, `#`, `@` und `:` müssen kodiert bleiben, wenn ihre Dekodierung die Grenzen oder Trennzeichen von Bestandteilen verändern würde. Das RFC sagt außerdem, dass eine Implementierung dieselbe Zeichenfolge nicht mehr als einmal kodieren oder dekodieren darf. Daraus ergibt sich eine gute Regel für die Darstellung: ```text Raw path: /v1/%75sers/alice%7Eops/report%2Ffinal Card path: /v1/users/alice~ops/report%2Ffinal Wire path: /v1/users/alice~ops/report%2Ffinal ``` Die Karte macht `%75` und `%7E` lesbar, weil sie für nicht reservierte Zeichen stehen. `%2F` bleibt sichtbar, weil ein Schrägstrich die Segmentstruktur des Pfads verändern würde. Draht- und Kartenform dürfen sich auf harmlose Weise unterscheiden, müssen aber dieselbe Routing-Bedeutung behalten. Entfernen Sie Punktsegmente nicht, nachdem Sie den Pfad wahllos dekodiert haben. Parsen Sie den Pfad anhand seiner kodierten Struktur, wenden Sie ein festgelegtes Normalisierungsverfahren an und bewahren Sie Sequenzen, die reservierte Zeichen als Daten enthalten. Wenn der nachgelagerte Dienst eine andere Reihenfolge der Dekodierung verwendet, ist das ein Kompatibilitäts- und Sicherheitsproblem, das Tests sichtbar machen sollten. Es ist kein Grund, die Karte raten zu lassen. ## Ein Hostname ist nicht die gesamte Autorität Die Autorität eines HTTP-Ziels umfasst den Host und, sofern er nicht standardmäßig ist, den Port. Wenn der Port fehlt, lügt die Prüfkarte durch Auslassung. Behandeln Sie diese Ziele als unterschiedlich: ```text https://api.example.test/v1/keys https://api.example.test:8443/v1/keys http://api.example.test/v1/keys ``` Das erste verwendet normalerweise Port 443. Das zweite verwendet Port 8443. Das dritte hat ein anderes Schema und normalerweise Port 80. Eine prüfende Person kann einen Produktionsaufruf über HTTPS akzeptieren und eine Anfrage an einen Test-Listener auf einem benutzerdefinierten Port ablehnen. Die Karte muss diese Entscheidung ermöglichen. Schreiben Sie Schema und Hostnamen klein. Blenden Sie den Port nur aus, wenn er für das geparste Schema der Standardport ist: 80 für `http`, 443 für `https`. Lassen Sie einen Port nicht weg, nur weil ein DNS-Eintrag zufällig auf einen bekannten Ort verweist. Internationalisierte Domainnamen erfordern dieselbe Sorgfalt. Eine Unicode-Darstellung kann für Menschen leichter lesbar sein, während die DNS-Darstellung über ASCII-Labels erfolgt. Wenn Sie Unicode anzeigen, zeigen Sie gleichzeitig die ASCII-Form in den Details und verwenden Sie einen Parser mit einem festgelegten Verfahren zur Hostverarbeitung. Erfinden Sie keine eigene Punycode-Umwandlung und vergleichen Sie keine Darstellungszeichenfolgen, um Gleichheit festzustellen. IP-Literale brauchen eine eigene Behandlung. Setzen Sie IPv6-Adressen in Klammern, bewahren Sie einen nicht standardmäßigen Port auf und kennzeichnen Sie ein Literal als IP-Adresse. Eine Anfrage an `https://[2001:db8::9]/v1/keys` sollte nicht wie ein benannter Produktionsdienst aussehen, nur weil ein Agent in einem Notizfeld einen angenehmen Alias angegeben hat. Aliase bringen ein anderes Problem mit sich. `api.internal`, `api` und `10.0.0.9` können heute beim selben Server landen und nach einer DNS-Änderung auseinanderlaufen. Schreiben Sie einen Alias für die Genehmigung nicht still in einen anderen Wert um. Zeigen Sie die geparste Autorität, die der Client angefordert hat. Wenn das System vor dem Öffnen der Verbindung DNS auflöst, zeigen Sie die ausgewählte Adresse als Verbindungskontext und speichern Sie sie im Audit-Log. Die Autorität bleibt das, was die HTTP-Anfrage benennt. HTTP macht diesen Unterschied ausdrücklich. RFC 9110 sagt, dass das `Host`-Feld Host- und Portinformationen aus dem Ziel-URI enthält, während HTTP/2 und HTTP/3 diese Informationen in `:authority` übertragen können. RFC 9113 sagt, dass ein Vermittler, der `Host` aus der HTTP/2-Autorität erzeugt, `:authority` verwenden muss, sofern er das Anfrageziel nicht ändert. Eine Karte muss ein vom Aufrufer geliefertes Autoritätsfeld deshalb als Routing-Material behandeln und nicht als dekorative Metadaten. ## Methode und Pfad brauchen eigenes visuelles Gewicht Setzen Sie HTTP-Methode, Autorität und Pfad zusammen, weil Prüfende die Aktion wie einen Satz lesen. Geben Sie der Methode und gefährlichen Pfadsegmenten anschließend genug Kontrast, damit ein flüchtiger Blick sie nicht in einer langen URL verschwinden lässt. Dieses Layout funktioniert, weil die Bestandteile in einer stabilen Reihenfolge bleiben: ```text DELETE https://api.example.test/v1/projects/acme/production ``` Bei einer Anfrage, die ein Objekt verändert, muss die Kennung im sichtbaren Pfad enthalten sein. Das Ende von `/v1/projects/acme/production` abzuschneiden, damit es in eine Karte passt, wäre der falsche Ansatz. Wenn der Platz knapp ist, kürzen Sie zuerst lange Query-Werte oder Body-Vorschauen, niemals das letzte Pfadsegment, das das Ziel identifiziert. Die Groß- und Kleinschreibung im Pfad muss erhalten bleiben. RFC 3986 sagt, dass die allgemeine URI-Syntax Bestandteile außer Schema und Host als groß- und kleinschreibungssensitiv behandelt, sofern das Schema nichts anderes bestimmt. Viele Frameworks routen tatsächlich mit Beachtung der Groß- und Kleinschreibung, selbst wenn eine bestimmte API dies nicht tut. Aus `/Admin/DeleteUser` den Pfad `/admin/deleteuser` zu machen, wäre eine Aussage über eine Anfrage, die nie gestellt wurde. Ein Anfragepfad kann harmlos aussehen, während die Query die Wirkung verändert: ```text POST https://api.example.test/v1/invoices/481/refund?dry_run=false POST https://api.example.test/v1/invoices/481/refund?dry_run=true ``` Zeigen Sie eine kurze Zusammenfassung der Query unter der Aktionszeile, wenn Parameter den Umfang, das Verhalten oder die Identität verändern. Bei unstrukturierten oder sehr langen Queries zeigen Sie die vollständige kodierte Query in einem ausklappbaren Detailbereich und eine redigierte, dekodierte Zusammenfassung in der Hauptkarte. Dekodieren Sie niemals ein Token in ein lesbares Geheimnis, nur weil die Karte benutzerfreundlich wirken soll. Der Request-Body kann noch wichtiger sein als der Pfad. Eine Genehmigung für `PATCH /v1/users/alice` sagt wenig aus, wenn der Body eine Administratorrolle vergeben kann. Zeigen Sie mindestens Inhaltstyp, Byte-Länge und einen stabilen Digest. Bei strukturierten Formaten wie JSON kann eine kurze Vorschau geänderter Felder helfen, sofern sie aus denselben Bytes stammt, die später übertragen werden. Wenn Sie nach dem Signieren oder Hashen eine andere Bytefolge für die Darstellung erneut serialisieren, entsteht dasselbe Problem zweier widersprüchlicher Wahrheiten wie beim erneuten Parsen von URLs. ## Header und Weiterleitungen können das Ziel verändern Eine kanonische URL schützt einen Genehmigungsprozess nicht, wenn ein anderes Anfragefeld die Verbindung steuern kann. Die Karte muss solche Felder entweder begrenzen oder ihre Wirkung darstellen. Beginnen Sie mit `Host` und `:authority`. Ein HTTP-Client leitet sie normalerweise aus der Ziel-URL ab. Wenn eine Aktionsschnittstelle es dem Aufrufer erlaubt, diese Felder zu überschreiben, lehnen Sie die Überschreibung ab, sofern der Transport keinen dokumentierten Grund dafür hat. Wenn Sie sie unterstützen, muss die Genehmigungszeile sowohl das Verbindungsziel als auch die angeforderte Autorität so anzeigen, dass eine Person beide vergleichen kann. Die Proxy-Konfiguration erfordert dieselbe Behandlung. Ein Proxy verändert den unmittelbaren Kommunikationspartner, aber nicht zwingend das Ursprungsziel. Ersetzen Sie das Ursprungsziel auf der Karte nicht durch die Proxy-Adresse. Zeigen Sie das Ursprungsziel als genehmigte Aktion und den Proxy als Transportkontext. Wenn der Proxy Zielfelder umschreiben kann, behandeln Sie ihn als Bestandteil des Executors mit Tests, Protokollierung und einer eigenen Vertrauensentscheidung. Weiterleitungen sind neue Aktionen, sobald sich ihr Ziel ändert. Unter bestimmten Weiterleitungsverhalten kann aus einem `POST` ein `GET` werden oder die Anfrage erneut an eine neue Autorität gesendet werden. Die ursprüngliche Genehmigung sollte nur für das ursprüngliche Ziel gelten. Parsen Sie vor dem Folgen einer Weiterleitung den `Location`-Wert, erstellen Sie die vorgeschlagene nächste Anfrage, vergleichen Sie Schema, Autorität, Methode, Pfad, Query und Body-Verhalten und fragen Sie erneut, wenn sich etwas Wesentliches ändert. Vermeiden Sie den verbreiteten Kurzw eg, eine «Website» für die Dauer eines Laufs zu genehmigen und jede Weiterleitung darunter als harmlos zu behandeln. Das wirkt weniger störend, macht aber URL-Parsing und Weiterleitungsregeln zu einer unsichtbaren Erweiterung der Berechtigungen. Wenn der Lauf eine weitreichende Erlaubnis braucht, formulieren Sie diesen Umfang ausdrücklich in der Genehmigung, statt Weiterleitungen ihn unbemerkt einschleusen zu lassen. ## Rohe Eingaben gehören ins Protokoll, nicht in die Entscheidungszeile Ein Audit-Trail muss zwei getrennte Fragen beantworten können: Was hat der Agent angefordert und was hat der Executor versucht? Eine einzige URL-Zeichenfolge kann nicht immer beides zeigen. Speichern Sie die rohe URL-Zeichenfolge exakt so, wie sie eingegangen ist, vorbehaltlich der Regeln zur Redigierung von Geheimnissen. Speichern Sie das kanonische Ziel separat. Ergänzen Sie die endgültige Verbindungsautorität und die aufgelöste Adresse, wenn der Executor eine Auflösung durchgeführt hat. Speichern Sie für HTTP/2 oder HTTP/3 die effektive `:authority`, für HTTP/1.1 den effektiven `Host`-Wert. Zeichnen Sie Weiterleitungsschritte als einzelne versuchte Anfragen auf und nicht als Fußnote zum ersten Aufruf. Ein Journaleintrag kann so aussehen: ```json { "request_id": "req_01J...", "agent_input_url": "HTTPS://API.EXAMPLE.TEST:443/v1/%75sers/alice%7Eops", "approved_target": "GET https://api.example.test/v1/users/alice~ops", "effective_authority": "api.example.test", "effective_port": 443, "connection_ip": "203.0.113.42", "result": "200" } ``` Das Beispiel verwendet einen für Dokumentation reservierten Adressbereich für die Verbindungs-IP. In einem echten Log müssen Sie Query-Geheimnisse, Autorisierungsmaterial und sensible Bodies schützen, bevor die Daten in ein langlebiges Protokoll gelangen. Ein Digest hilft, genehmigten und ausgeführten Inhalt zu verbinden, ohne private Nutzdaten in jede Ansicht zu kopieren. Der Unterschied zwischen roher Eingabe und kanonischem Ziel zahlt sich bei Untersuchungen aus. Wenn eine Karte einen normalen Pfad zeigte, die rohe Eingabe aber verschachtelte Kodierungen enthielt, können Sie feststellen, ob Parser, Renderer oder HTTP-Client voneinander abwichen. Wenn Sie nur eine ansehnliche URL gespeichert haben, fehlen die Beweise, die zur Suche nach dem Fehler nötig sind. Sallyports Aktivitätsjournal und Sitzungsjournal werden aus einem einzigen verschlüsselten, hashverketteten Audit-Log erstellt. Deshalb sollte eine Zieldarstellung einmal als Teil des Aktionsdatensatzes gespeichert und nicht später aus UI-Zeichenfolgen rekonstruiert werden. Die Offline-Prüfung `sp audit verify` ist nur dann nützlich, wenn die aufgezeichneten Aktionsfelder zum Zeitpunkt der Ausführung korrekt waren. ## Testen Sie Abweichungen, die gewöhnliche URLs nicht sichtbar machen Die wichtigen Unit-Tests sind nicht zehn gewöhnliche Beispiele wie `https://api.example.test/v1/users`. Es sind Fälle, in denen eine rohe Zeichenfolge, ein Karten-Renderer und eine Transportbibliothek voneinander abweichen könnten. Erstellen Sie einen tabellengesteuerten Testkorpus, der geparste Felder, sichtbares Ziel, Drahtziel und Entscheidung prüft. Berücksichtigen Sie mindestens diese Gruppen: - Änderungen an Groß- und Kleinschreibung von Schema und Host, mit Standard- und nicht standardmäßigen Ports; - Punktsegmente und Prozentsequenzen für nicht reservierte und reservierte Zeichen; - kodierte Prozentzeichen, kodierte Schrägstriche und fehlerhafte Escape-Sequenzen; - IPv6-Literale, Unicode-Hosteingaben und abzulehnende Userinfo; - Query-Werte, die das Aktionsverhalten verändern, sowie Weiterleitungsziele unter einer anderen Autorität. Ein Testfall sollte die erwartete Darstellung ausdrücklich festlegen: ```json { "input": "HTTPS://API.EXAMPLE.TEST:443/v1/%75sers/alice%7Eops?role=viewer", "decision": "approve", "card": "GET https://api.example.test/v1/users/alice~ops?role=viewer", "wire_url": "https://api.example.test/v1/users/alice~ops?role=viewer" } ``` Fügen Sie anschließend negative Fälle hinzu, die vor der Genehmigung fehlschlagen müssen: ```json { "input": "https://alice@api.example.test/v1/users", "decision": "reject", "reason": "userinfo is not supported for outbound API actions" } ``` Führen Sie den Korpus über genau den Client aus, der die Verbindung öffnet. Eine reine Parser-Testsuite findet Darstellungsfehler, übersieht aber Transportverhalten wie das Normalisieren eines leeren Pfads durch eine Bibliothek, das Einfügen einer Standardautorität oder eigene Weiterleitungsregeln. Testen Sie schließlich auch die Oberfläche so, wie eine prüfende Person sie verwendet. Stellen Sie sicher, dass Methode, Host, gegebenenfalls Port und das letzte Pfadsegment bei gewöhnlichen Fenstergrößen vollständig sichtbar bleiben. Sicherheitstexte versagen, wenn jemand erst mit der Maus darüberfahren, etwas ausklappen oder scrollen muss, um zu erkennen, dass eine Anfrage Produktionsdaten löscht. Die Karte sollte den entscheidenden Unterschied sichtbar machen, bevor der Genehmigungsbutton den Fokus erhält. Eine menschliche Genehmigung kann eine starke Kontrolle sein, aber sie ist nur so stark wie die Anfragebeschreibung, die dem Menschen vorgelegt wird. Erstellen Sie diese Beschreibung aus geparsten Bestandteilen, führen Sie genau diese Bestandteile aus, bewahren Sie die rohe Eingabe für spätere Untersuchungen auf und lehnen Sie Mehrdeutigkeit ab, statt sie zu schmücken.