Wie behebe ich HTTP-403-Fehler von API Gateway?

Lesedauer: 8 Minute

Wenn ich meine Amazon-API-Gateway-API aufrufe, erhalte ich einen 403-Fehler.

Kurzbeschreibung

Wenn ein Client nicht auf eine gültige URL zugreifen kann, erhältst du den Antwortcode HTTP 403. Der Server versteht die Anforderung, der Server kann die Anforderung jedoch aufgrund von clientseitigen Problemen nicht erfüllen.
API-Gateway-APIs können aus den folgenden Gründen 403-Antworten zurückgeben:


Problem	Antwort-Header	Fehlermeldung	Grundursache
Zugriff verweigert	„x-amzn-errortype“ = „AccessDeniedException“	„Der Benutzer ist nicht berechtigt, auf diese Ressource mit einer expliziten Zugriffsverweigerung zuzugreifen“	Der Aufrufer ist nicht berechtigt, auf eine API zuzugreifen, die einen API-Gateway-Lambda-Authorizer verwendet.
Zugriff verweigert	„x-amzn-errortype“ = „AccessDeniedException“	„Benutzer: <user-arn> ist nicht berechtigt, Folgendes auszuführen: execute-api:invoke on resource: <api-resource-arn> mit einer ausdrücklichen Ablehnung“	Der Aufrufer ist nicht berechtigt, auf eine API zuzugreifen, die die AWS Identity and Access-Management (IAM, Identitäts- und Zugriffsmanagement)-Autorisierung verwendet. Oder die API verfügt über eine angehängte Ressourcenrichtlinie, die dem Aufrufer ausdrücklich den Zugriff verweigert. Weitere Informationen findest du unter IAM-Authentifizierungs- und Ressourcenrichtlinie.
Zugriff verweigert	„x-amzn-errortype“ = „AccessDeniedException“	„Benutzer: anonymous hat keine Berechtigung zur Ausführung von: execute-api:Invoke auf Ressource:<api-resource-arn>“	Der Aufrufer ist nicht berechtigt, auf eine API zuzugreifen, die die IAM-Autorisierung verwendet. Oder die API hat eine angehängte Ressourcenrichtlinie, die es dem Aufrufer nicht ausdrücklich erlaubt, die API aufzurufen. Weitere Informationen findest du unter IAM-Authentifizierungs- und Ressourcenrichtlinie.
Zugriff verweigert	„x-amzn-errortype“ = „AccessDeniedException“	„Das in der Anforderung enthaltene Sicherheitstoken ist ungültig.“	Der Aufrufer verwendete IAM-Schlüssel, die nicht gültig sind, um auf eine API zuzugreifen, die die IAM-Autorisierung verwendet.
Fehlender Authentifizierungstoken	„x-amzn-errortype“ = „MissingAuthenticationTokenException“	„Fehlender Authentifizierungstoken“	In der Anforderung wurde kein Authentifizierungstoken gefunden.
Authentifizierungstoken ist abgelaufen	„x-amzn-errortype“ = „InvalidSignatureException“	„Signatur abgelaufen“	Das Authentifizierungstoken in der Anforderung ist abgelaufen.
API-Schlüssel ist nicht gültig	„x-amzn-errortype“ = „ForbiddenException“	„Verboten“	Der Aufrufer hat einen API-Schlüssel für eine Methode verwendet, die einen API-Schlüssel erfordert, aber der API-Schlüssel ist nicht korrekt. Oder der API-Schlüssel ist keinem Nutzungsplan zugeordnet, der der Phase zugeordnet ist. Oder der API-Schlüssel ist deaktiviert oder existiert nicht.
Signatur ist nicht gültig	„x-amzn-errortype“ = „InvalidSignatureException“	„Die von uns berechnete Anforderungssignatur stimmt nicht mit der von dir angegebenen Signatur überein. Prüfe deinen geheimen AWS-Zugriffsschlüssel und die Signaturmethode.“	Die Signatur in der Anforderung stimmt nicht mit der Signatur auf dem Server überein, wenn der Aufrufer auf eine API zugreift, die die IAM-Autorisierung verwendet.
AWS WAF gefiltert	„x-amzn-errortype“ = „ForbiddenException“	„Verboten“	Die Filterung der Webanwendungs-Firewall blockiert die Anforderung, wenn AWS WAF in der API aktiviert ist.
Ressourcenpfad existiert nicht	„x-amzn-errortype“ = „MissingAuthenticationTokenException“	„Fehlender Authentifizierungstoken“	Eine Anforderung ohne „Authorisierungs“-Header wird an einen API-Ressourcenpfad gesendet, der nicht existiert. Weitere Informationen findest du unter Wie behebe ich Fehler vom Typ 403 „Missing Authentication Token“ am REST-API-Endpunkt von API-Gateway?
Ressourcenpfad existiert nicht	„x-amzn-errortype“ = „IncompleteSignatureException“	„Der Autorisierungsheader erfordert den Parameter „Credential“. Der Autorisierungsheader erfordert den Parameter „Signatur“. Der Autorisierungsheader erfordert den Parameter SignedHeaders“. Der Autorisierungsheader erfordert entweder das Vorhandensein eines „X-Amz-Date“- oder eines „Date“-Headers. Authorization=allow“	Eine Anforderung mit einem „Authorisierungs“-Header wird an einen API-Ressourcenpfad gesendet, der nicht existiert.
Verwendet fälschlicherweise öffentliche DNS-Namen, um eine private API aufzurufen	„x-amzn-errortype“ = „ForbiddenException“	„Verboten“	Du hast fälschlicherweise öffentliche DNS-Namen verwendet, um eine private API aus einer Amazon Virtual Private Cloud (Amazon VPC) heraus aufzurufen. Zum Beispiel: Der Header „Host“ oder „x-apigw-api-id“ fehlt in der Anforderung. Weitere Informationen findest du unter Aufrufen deiner privaten API mithilfe endpunktspezifischer öffentlicher DNS-Hostnames.
Verwendet den Standardendpunkt execute-api, um eine REST-API aufzurufen, die einen benutzerdefinierten Domainnamen hat	„x-amzn-errortype“ = „ForbiddenException“	„Verboten“	Der Aufrufer verwendet den Standardendpunkt execute-api, um eine REST-API aufzurufen, nachdem du den Standardendpunkt deaktiviert hast. Weitere Informationen findest du unter Deaktivierung des Standardendpunkts für REST-APIs
Verwendet ein Client-Zertifikat, das nicht gültig ist, um einen benutzerdefinierten API-Gateway-Domainnamen aufzurufen, der gegenseitige TLS erfordert	„x-amzn-errortype“ = „ForbiddenException“	„Verboten“	Der Truststore des benutzerdefinierten Domainnamens stellt das Client-Zertifikat, das in der API-Anforderung enthalten ist, nicht aus, oder das Zertifikat ist nicht gültig. Weitere Informationen findest du unter Wie behebe ich „HTTP 403 Forbidden“-Fehler von einem benutzerdefinierten API-Gateway-Domainnamen, für den gegenseitige TLS erforderlich ist?
Aufrufen eines benutzerdefinierten Domänenamens ohne Basispfadzuordnung	„x-amzn-errortype“ = „ForbiddenException“	„Verboten“	Der Aufrufer ruft eine benutzerdefinierte Domain auf und weist einer API keinen Basispfad zu. Weitere Informationen findest du unter Benutzerdefinierter Domänenname für REST-APIs in API Gateway.
Aufrufen einer API mit aktivierter benutzerdefinierter Domäne, wenn die Domänen-URL folgende Phase enthält:	„x-amzn-errortype“ = „MissingAuthenticationTokenException“	„Fehlender Authentifizierungstoken“	Eine API-Zuordnung spezifiziert eine API, eine Phase und einen optionalen Pfad, der für die Zuordnung verwendet werden soll. Wenn also die API-Phase einer benutzerdefinierten Domain zugeordnet ist, musst du die Phase nicht mehr in die URL aufnehmen. Weitere Informationen findest du unter API-Phasen einem benutzerdefinierten Domainnamen für REST-APIs zuordnen.
Die Phase in der URL der Anforderung ist ungültig	„x-amzn-errortype“ = „ForbiddenException“	„Verboten“	Die Anforderungs-URL des Aufrufers enthält eine Phase, die nicht existiert. Weitere Informationen findest du unter Aufrufen von REST-APIs in API Gateway.

Lösung

Identifizieren der Ursache des Fehlers

Wenn der 403-Fehler von anderen Ressourcen gemeldet wird, wie in den folgenden Beispielen, kann es eine andere Ursache für den Fehler geben:

Wenn der Fehler in einem Webbrowser gemeldet wird, erlaubt eine falsche Proxyeinstellung möglicherweise keinen HTTP-Zugriff.
Wenn sich ein anderer AWS-Service vor der API befindet, z. B. Amazon CloudFront, kann der Service die Anforderung ablehnen.

Um die Ursache des Fehlers zu ermitteln, richte die Amazon CloudWatch-Zugriffsprotokollierung für die API ein. Sieh dir dann die Protokollereignisse deiner API in CloudWatch an, um festzustellen, ob Anforderungen die API erreichen.

Hinweis: HTTP-APIs unterstützen keine Ausführungsprotokollierung.

Gehe wie folgt vor, um 403-Fehler zu beheben, die von einem benutzerdefinierten Domainnamen zurückgegeben werden, der gegenseitige TLS erfordert und eine HTTP-API aufruft:

Erstelle eine neue API-Zuordnung, um den REST-API-Aufruf für deinen benutzerdefinierten Domainnamen zu testen.
Sieh dir die Protokollereignisse der REST-API in CloudWatch an, um die Ursache der Fehler zu ermitteln.
Nachdem du den Fehler identifiziert und behoben hast, leite die API-Zuordnung an die HTTP-API um.

Sicher vergewissern, dass die angeforderte Ressource in der API-Definition existiert

**Hinweis:**Wenn bei der Ausführung von AWS Command Line Interface (AWS CLI)-Befehlen Fehler auftreten, findest du weitere Informationen unter Troubleshoot AWS CLI errors. Stelle außerdem sicher, dass du die neueste Version von AWS CLI verwendest.

Verwende entweder die API Gateway-Konsole oder die AWS CLI, um die folgenden Konfigurationen zu überprüfen:

Du hast die API mit der neuesten API-Definition bereitgestellt.
Die angeforderte Ressource ist in der API-Definition vorhanden.

Verwendung von curl, um Anforderungs- und Antwortdetails abzurufen

Wenn du den Fehler reproduzieren kannst, verwende den Befehl curl -v, um weitere Informationen zwischen dem Client und der API abzurufen:

curl -X HTTP_VERB -v https://{api_id}.execute-api.{region}.amazonaws.com/{stage_name}/{resource_name}

Stelle sicher, dass der Anforderungsheader korrekt ist

Wenn der Fehler auf einen ungültigen API-Schlüssel zurückzuführen ist, überprüfe, ob der Header „x-api-key“ in der Anforderung gesendet wurde. Wenn der Header nicht enthalten oder nicht korrekt ist, aktualisiere den Anforderungsheader.

Sicherstellen, dass die DNS-Einstellung auf den Amazon-VPC-Endpunkten korrekt eingestellt ist

Hinweis: Die folgenden Aufgaben gelten für APIs, die du von einer Amazon VPC aus aufrufst, die nur über einen Schnittstellen-VPC-Endpunkt verfügt.

Stelle sicher, dass die DNS-Einstellung des Schnittstellenendpunkts basierend auf dem von dir verwendeten API-Typ korrekt festgelegt ist.

Um eine regionale API aus einer Amazon VPC heraus aufzurufen, deaktiviere private DNS-Namen auf dem Schnittstellenendpunkt. Ein öffentliches DNS kann dann den Hostnamen des Endpunkts auflösen. Weitere Informationen findest du unter Erstellen einer privaten API.

Um den privaten DNS-Namen der API zum Aufrufen einer privaten API aus einer Amazon VPC heraus zu verwenden, aktiviere die privaten DNS-Namen auf dem Endpunkt. Die lokalen Subnetzressourcen von Amazon VPC können dann den Hostnamen des Schnittstellenendpunkts auflösen.

Hinweis: Wenn du eine der folgenden Optionen verwendest, um die private API aufzurufen, musst du weder den öffentlichen DNS-Namen der privaten API noch einen Amazon Route 53-Alias einrichten.

Ressourcenrichtlinie der API überprüfen

Überprüfe die Ressourcenrichtlinie deiner API, um Folgendes zu überprüfen:

Bei APIs, die du von einer Amazon-VPC mit einem Schnittstellen-VPC-Endpunkt aufrufst: Die Ressourcenrichtlinie der API gewährt der Amazon VPC oder dem Schnittstellenendpunkt Zugriff auf die API.
Die Ressourcenspezifikationen und die Formatierung der Ressourcenrichtlinie sind korrekt.
Hinweis: Wenn du eine Ressourcenrichtlinie speicherst, werden die Ressourcenspezifikationen nicht validiert. Beispiele findest du unter Beispiele für API-Gateway-Ressourcenrichtlinien.
Der Aufrufer darf den API-Endpunkt mit dem Authentifizierungstyp aufrufen, den du für die API definiert hast. Weitere Informationen findest du unter Wie sich API-Gateway-Ressourcenrichtlinien auf den Autorisierungsworkflow auswirken.

HTTP-Anforderungs- und Antwortnachrichten überprüfen

Reproduziere den Fehler in einem Webbrowser. Verwende die Netzwerktools des Browsers, um die HTTP-Anforderungs- und Antwortnachrichten zu erfassen und zu analysieren, um festzustellen, wo der Fehler aufgetreten ist.

**Hinweis:**Speichere die Nachrichten für die Offline-Analyse in einer HTTP-Archivdatei (HAR).