1. Was zeigt diese Seite?
Die erste Demo zeigt, wie Coraza verdächtige Angriffsmuster blockiert. Diese Seite zeigt eine andere Schutzfunktion: Das API-Gateway kontrolliert die veröffentlichte API-Oberfläche.
Browser
Startet eine API-Anfrage, zum Beispiel per Button.
ClientCaddy
Nimmt die Anfrage entgegen und leitet sie an die Demo weiter.
Reverse ProxyCoraza
Prüft, ob die Anfrage gefährliche Muster enthält.
WAFKrakenD
Entscheidet, ob Pfad und Methode zur veröffentlichten API gehören.
API GatewayMock API
Wird nur erreicht, wenn KrakenD die Anfrage erlaubt und weiterleitet.
Backend2. Interaktive Gateway-Demo
Die folgenden Tests zeigen erlaubte und nicht erlaubte API-Aufrufe. Nicht jeder abgelehnte Request ist ein Angriff. Manchmal ist er einfach nicht Teil der veröffentlichten API.
3. Ergebnis und Erklärung
https://demo.aufeni.com/gateway.
Die eigentliche API-Anfrage wird im Hintergrund ausgeführt.
Tatsächlich aufgerufene API-Adresse:
Noch keine Anfrage ausgeführt.
HTTP-Methode:
Noch keine Anfrage ausgeführt.
Technische Antwort
Noch keine Anfrage ausgeführt.
Was ist passiert?
Bereit für die Gateway-Demo
Starte mit Erlaubten GET-Aufruf testen. Danach kannst du sehen, was passiert, wenn Methode oder Pfad nicht zur veröffentlichten API gehören.
4. Was verhindert hier das Gateway?
| Test | Erwartung | Warum? |
|---|---|---|
GET /api/products |
Erlaubt | Dieser Endpunkt ist in KrakenD als veröffentlichte API definiert. |
POST /api/products |
Nicht erlaubt | Die Demo-API erlaubt Lesen, aber keine Schreiboperation auf diesem Pfad. |
GET /api/internal-users |
Nicht veröffentlicht | Dieser Pfad existiert nicht in der öffentlichen API-Konfiguration von KrakenD. |
5. WAF vs. Gateway
Coraza WAF
Prüft Inhalte der Anfrage auf verdächtige Muster.
Beispiel: q=' OR 1=1 oder DROP TABLE users.
Rolle: Angriffsversuche früh erkennen und blockieren.
KrakenD API Gateway
Kontrolliert, welche API-Endpunkte und Methoden veröffentlicht sind.
Beispiel: GET /products ist erlaubt, POST /products nicht.
Rolle: API-Oberfläche definieren, Backends verstecken und kontrolliert weiterleiten.
6. Warum ist das wichtig?
Ohne API-Gateway müssten interne Services selbst entscheiden, welche Pfade und Methoden öffentlich erlaubt sind. Mit KrakenD kann die veröffentlichte API-Oberfläche zentral beschrieben werden.
Dadurch entsteht eine klare Trennung:
- Öffentliche API: bewusst freigegebene Endpunkte
- Interne Services: nicht direkt aus dem Internet erreichbar
- Gateway: kontrolliert, was nach innen weitergeleitet wird
- WAF: prüft zusätzlich, ob Requests verdächtige Inhalte enthalten