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.
Was Ratenlimits auf Netzwerkebene lösen, was Limits pro Schlüssel nicht können
Ein Ratenlimit, das nur an einen API-Schlüssel gebunden ist, trifft eine stillschweigende Annahme: dass ein Schlüssel einem legitimen Nutzer entspricht, der ihn auf eine einigermaßen vorhersehbare Weise verwendet. Diese Annahme bricht häufiger zusammen, als das Design vorsieht. Ein Schlüssel kann in einem Team geteilt, in eine clientseitige App eingebettet sein, in der viele verschiedene Besucher Anfragen unter denselben Zugangsdaten auslösen, oder vielfach von jemandem erzeugt werden, der gezielt mehrere Schlüssel stapeln will, um das Limit eines einzelnen Schlüssels zu umgehen.
Genau aus diesem Grund begrenzen wir die Rate sowohl auf Netzwerkebene als auch auf Schlüsselebene. Jedes Netzwerk, ein /24-Block für IPv4 oder ein /48-Block für IPv6, erhält ein kostenloses Kontingent von 2.500 Anfragen pro Tag, das zwischen der Nutzung ohne Schlüssel und allen Schlüsseln geteilt wird, die von Adressen in diesem Netzwerk registriert wurden. Niemand kann zehn Schlüssel aus demselben Netzwerk erzeugen und so sein kostenloses Kontingent verzehnfachen, denn die Obergrenze auf Netzwerkebene erkennt dieses Muster, egal wie viele separate Schlüssel darunter liegen.
Dabei geht es nicht in erster Linie darum, böswilligen Missbrauch zu stoppen, auch wenn es das ebenfalls tut. Es geht darum, das kostenlose Kontingent für alle, die es ehrlich nutzen, sinnvoll zu halten. Eine gemeinsame Ressource wie ein kostenloses Kontingent bleibt nur großzügig, wenn diese Großzügigkeit nicht still und massenhaft von einer kleinen Zahl von Konten abgeschöpft wird, die das Limit pro Schlüssel umgehen. Kontingente auf Netzwerkebene halten die Rechnung des kostenlosen Kontingents näher an dem, wofür es eigentlich gedacht war: ein echtes Tageskontingent pro Quelle, nicht pro Zugangsdaten, die diese Quelle zufällig besitzt.
Es gibt einen legitimen Anwendungsfall, den dies nicht bestrafen darf: mehrere echte Nutzer oder Dienste, die rechtmäßig aus demselben Netzwerk heraus arbeiten, etwa aus einem Büro, einer gemeinsam genutzten Hosting-Umgebung oder einer großen Organisation hinter einer kleinen Zahl öffentlicher IP-Adressen. Genau deshalb veröffentlichen wir rollierende IP-Plätze und machen die Netzwerknutzung über Kontingent-Header sichtbar, darunter ein eigener Header dafür, wie viele der IP-Plätze Ihres Schlüssels im Verhältnis zum Limit belegt sind. Ein legitimes Team, das sich ein Netzwerk teilt, kann seinen tatsächlichen Stand sehen, statt eine gemeinsame Obergrenze erst zu entdecken, wenn es unerwartet an sie stößt.
Ratenlimits nur auf Schlüsselebene sind einfacher zu bauen und zu erklären, und für viele APIs reichen sie wahrscheinlich aus. Gerade für einen Dienst mit einem nennenswerten kostenlosen Kontingent lassen Limits nur pro Schlüssel jedoch eine offensichtliche Lücke: Das kostenlose Kontingent war nie als Ressource gedacht, die man durch das Erzeugen weiterer Zugangsdaten vervielfachen kann, und ein Limit, das dies nicht berücksichtigt, schützt nicht wirklich das, was es zu schützen vorgibt. Eine Obergrenze auf Netzwerkebene über die auf Schlüsselebene zu legen, schließt diese Lücke, ohne dass jeder legitime Nutzer beweisen muss, dass er nicht die Ausnahme ist.