Letztes Jahr, Mandate bei einem Maschinenbauer in Baden-Württemberg, 85 Mitarbeitende. Die hatten eine REST-API gebaut — intern, für ihren Außendienst-App. Authentifizierung: keiner. Buchstäblich keiner. Der API-Key stand in der React-App hardcodiert im Klartext, und der IT-Leiter wusste es nicht, weil er die App nicht geschrieben hatte. Den hatte ein Freelancer entwickelt, der seit achtzehn Monaten nicht mehr erreichbar war.
Was mich daran nicht überrascht hat: Es war kein Einzelfall. Ich sehe das in drei von fünf KMU-Mandaten. Nicht böse Absicht — einfach niemand, der beim Bauen laut "Moment mal" gesagt hätte. Genau deshalb ist ein Artikel wie der von Nick Chapsas wichtig. Und genau deshalb reicht er nicht.
Was Nick erklärt — und er erklärt es gut
Nick Chapsas ist einer der wenigen .NET-YouTuber und Blogger, die nicht nur Snippets hinwerfen, sondern erklären, warum etwas so gemacht wird. In seinem Beitrag zeigt er zwei saubere Wege, API-Key-Authentifizierung in ASP.NET Core umzusetzen: einmal als Middleware, einmal als Authorization-Filter. Beide Ansätze sind idiomatisch, beide haben ihre Daseinsberechtigung. Der Filter-Ansatz ist besonders nützlich, wenn du die Auth granular per Controller oder Endpoint steuern willst, statt sie pauschal über die gesamte Pipeline zu ziehen. Technisch korrekt, gut lesbar, copy-paste-fähig.
Was er nicht macht: Er erklärt die Stolpersteine, die zwischen "funktionierendem Code" und "sicherer Produktion" liegen. Das ist kein Vorwurf — sein Publikum sind Entwicklerinnen und Entwickler, die .NET können. Meins nicht immer.
Wie das in einem KMU wirklich landet
Lass mich konkret sein. In einem Betrieb mit 30 bis 300 Mitarbeitenden treffe ich selten einen dedizierten Security-Engineer. Ich treffe einen IT-Leiter, der gleichzeitig Helpdesk macht, oder einen Entwickler, der nebenbei die Infrastruktur verantwortet. Der schaut sich Nick' Artikel an, baut es nach — und tappt in genau drei Fallen, die im Artikel nicht vorkommen.
Falle 1: Der Key landet in der Versionskontrolle.
Nick' Beispiel speichert den API-Key in appsettings.json. Wert: traindome420. Das ist ein Tutorial-Wert, klar. Aber ich kann dir sagen: In mindestens zwei Mandaten der letzten zwei Jahre hat jemand genau das in ein Git-Repository eingecheckt — inklusive echtem Key, inklusive öffentlichem GitHub-Repo. Der richtige Weg ist appsettings.json als Template ohne echte Werte, der Key kommt via Umgebungsvariable oder einem Secret-Manager rein. In Azure heißt das Key Vault, on-premise reicht oft ein simpler Environment-Variable-Inject über den Deployment-Prozess. Kostet nichts, verhindert das Schlimmste.
Falle 2: Ein Key für alles.
Nick zeigt ein einzelnes Feld: Authentication:ApiKey. Das reicht für ein Tutorial. In der Praxis heißt das: Wenn du diesen Key rotatieren oder sperren willst, sind alle Clients gleichzeitig draußen. Ich empfehle meinen Mandanten ab dem ersten externen Client eine Key-Tabelle — sei es in der Datenbank oder im Konfigurationssystem. Jeder Client bekommt seinen eigenen Key, mit einem lesbaren Label ("Außendienst-App", "ERP-Integration", "Partner Müller GmbH"). Wenn Müller GmbH abspringt oder der Key kompromittiert wird, ziehst du einen Eintrag, nicht das gesamte System vom Netz.
Das ist keine Raketenwissenschaft: eine Tabelle mit drei Spalten (key_hash, client_name, is_active), und statt dem statischen Config-Wert machst du einen Datenbankabfrage. Nick' Middleware-Pattern ist dafür perfekt erweiterbar — der IConfiguration-Inject wird zu einem IApiKeyRepository-Inject, fertig.
Falle 3: Kein Logging, kein Alerting.
Der Code in Nick' Artikel gibt bei ungültigem Key eine 401 zurück. Richtig. Aber er schreibt nichts ins Log — jedenfalls nicht mit genug Kontext, um später zu sehen: "Seit Dienstag kommen aus einer IP-Range 400 ungültige Requests pro Minute." Das ist kein Angriff, den du siehst. Das ist ein stiller Scan. Ich baue in jede Middleware mindestens ein ILogger.LogWarning mit der Quell-IP und dem (geschwärzten) Key-Fragment. Kostet zwei Zeilen. Gibt dir später Kontext, wenn du erklären musst, was passiert ist.
Was ich konkret empfehle
Wenn du ein KMU bist und gerade deine erste interne oder externe API absichern willst, dann ist Nick' Artikel der richtige Einstieg. Bau die Middleware, nicht den Filter — sie ist einfacher zu verstehen und zu warten, wenn in sechs Monaten jemand anderes dran muss. Und dann ergänze sofort drei Dinge, bevor es in Produktion geht:
- Key nie in
appsettings.jsonmit echtem Wert — Umgebungsvariable, Punkt. - Pro Client ein Key — auch wenn du heute nur einen Client hast. Der zweite kommt schneller als du denkst.
- LogWarning bei jedem fehlgeschlagenen Versuch — mit IP, Timestamp und einem gekennzeichneten Key-Fragment (erste 4 Zeichen reichen, damit du weißt, ob es ein alter Key ist).
Was ich nicht empfehle: Den Filter-Ansatz aus Nick' Artikel für KMU-Erstlösungen. Er ist mächtiger, aber er setzt voraus, dass du weißt, wie ASP.NET Core's Authorization-Pipeline funktioniert. Die meisten IT-Generalisten in Mittelstandsbetrieben wissen das nicht — und wenn die Middleware bricht, ist die Fehlersuche einfacher, weil sie explizit und sequenziell ist.
Und noch eins: API-Key-Auth ist kein Ersatz für TLS. Wenn deine API über HTTP läuft, ist der Key im Klartext auf der Leitung. Nick erwähnt das kurz, ich betone es härter — weil ich bei dem Maschinenbauer oben eine API über HTTP gesehen habe. In 2025. Über HTTP.
Der vollständige Original-Beitrag von Nick Chapsas: Adding API key Authentication in .NET
Wenn du dir nicht sicher bist, ob deine API-Absicherung dem standhält, was ich oben beschreibe — oder wenn du gerade dabei bist, eine interne API zu bauen und wissen willst, was du von Anfang an richtig machen kannst — dann lass uns reden.
— Bernhard