Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Warum wir nicht zuerst ein Browser-SDK gebaut haben
Ein Browser-SDK ist schnell gewünscht und für vieles, was eine Geokodierungs- oder IP-Abfrage-API tatsächlich leistet, eine ausgesprochen schlechte Idee. Eine IP-Adresse einem Standort zuzuordnen ist gerade deshalb aussagekräftig, weil es auf dem Server geschieht, wo die tatsächliche Herkunft der Anfrage sichtbar ist. Verlagern Sie dieselbe Abfrage in clientseitiges JavaScript, das im Browser eines Besuchers läuft, haben Sie die Integration nicht bequemer gemacht. Sie haben einen authentifizierten API-Schlüssel an die einzige Stelle des gesamten Anfragewegs verschoben, an der jeder die Entwicklertools öffnen und ihn auslesen kann.
Deshalb hatte ein Browser-SDK für uns keine Priorität vor einfachem HTTP-Zugriff und Drop-in-Hosts. Ein Schlüssel, der als X-API-Key-Header, Bearer-Token, HTTP Basic Auth oder Query-Parameter akzeptiert wird, funktioniert auf jedem Host gleich, aufgerufen von dort, wo Ihr serverseitiger Code ohnehin läuft: ein Backend-Dienst, eine Serverless-Funktion, ein Batch-Job, überall dort, wo die Anfrage ohnehin aus Infrastruktur stammt, die Sie kontrollieren, und nicht aus einem Browser-Tab, den Sie nicht kontrollieren.
Gerade IP-Geolokalisierung ergibt nur serverseitig Sinn. Der gesamte Wert der Abfrage liegt darin, die tatsächliche IP-Adresse aufzulösen, von der die Anfrage kommt, und das muss für die meisten sinnvollen Anwendungsfälle (Betrugsprüfungen, Lokalisierung, Analysen, die Sie selbst kontrollieren statt sie zu verkaufen) dort geschehen, wo diese IP-Adresse maßgeblich ist: auf Ihrem Server, der die Anfrage direkt empfängt, nicht in einer Browserumgebung, in der die „IP“, die ein clientseitiger Aufruf melden würde, entweder irrelevant oder mühelos zu fälschen ist.
Die Geokodierung einer eingetippten Adresse ist weniger eindeutig rein serverseitig, und es gibt ein echtes Argument dafür, dass sich Adress-Autovervollständigung direkt im Formular, im Browser, reaktionsschnell anfühlen soll, ohne vorher einen Umweg über Ihr eigenes Backend. Wir haben nichts dagegen, dass es dieses Muster irgendwann gibt. Wir sind dagegen, es als ersten und wichtigsten Integrationsweg zu bauen, noch vor dem einfachen serverseitigen HTTP-Zugriff, den die Mehrheit der realen Anwendungsfälle (Checkout-Abläufe, Versandkostenrechner, Betrugsprüfungen) tatsächlich braucht und der keine Zugangsdaten öffentlich preisgibt.
Das übergeordnete Muster, gegen das wir uns wenden, ist, „bietet ein Browser-SDK“ als Häkchen zu behandeln, das jede API haben soll, unabhängig davon, ob clientseitiger Zugriff auf genau diese Art von Daten sinnvoll ist. Bei einer Abfrage, bei der der serverseitige Kontext der eigentliche Zweck ist, beantwortet ein Browser-SDK meist nur eine Marketingfrage, „wirkt das modern und bequem“, auf Kosten einer echten Sicherheitsfrage, „wo landen diese Zugangsdaten am Ende“. Wir beantworten lieber zuerst die Sicherheitsfrage und lassen die Bequemlichkeit folgen, nicht umgekehrt.
Nichts davon schließt aus, dass es irgendwann ein schlankeres, browserfreundliches Werkzeug gibt, das gezielt auf die Fälle zugeschnitten ist, in denen clientseitige Nutzung wirklich sinnvoll ist, etwa eine Formular-Autovervollständigung, die nie die echten Zugangsdaten Ihres Kontos benötigt. Was es nicht sein sollte, ist das Erste, dem ein Kunde vertrauen soll, noch vor dem einfachen HTTP-Weg, der die Mehrheit der realen Integrationen bereits sicher abdeckt.