Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# CORS-Fehlerbehebung
Die folgenden Themen können bei der Behebung von allgemeinen Problemen mit CORS in Bezug auf S3 hilfreich sein.
**Topics**
+ [Fehler 403 Forbidden – CORS ist für diesen Bucket nicht aktiviert](#cors-not-enabled)
+ [Fehler 403 Forbidden – Diese CORS-Anfrage ist nicht zulässig](#cors-not-enabled)
+ [Header nicht in der CORS-Antwort gefunden](#Headers-not-found)
+ [Überlegungen zu CORS in S3-Proxy-Integrationen](#cors-in-proxy)
## Fehler 403 Forbidden: CORS ist für diesen Bucket nicht aktiviert
Der Fehler `403 Forbidden` tritt auf, wenn eine ursprungsübergreifende Anfrage an Amazon S3 gesendet wird, CORS jedoch nicht in Ihrem S3-Bucket konfiguriert ist.
Fehler: HTTP/1.1 403 Forbidden CORS Response: CORS is not enabled for this bucket.
Die CORS-Konfiguration ist ein Dokument oder eine Richtlinien mit Regeln, die die Ursprünge, die auf Ihren Bucket zugreifen dürfen, die Vorgänge (HTTP-Methoden), die die einzelnen Ursprünge unterstützen, sowie weitere operationsspezifische Informationen identifizieren. Erfahren [Sie, wie Sie CORS auf S3 mithilfe der Amazon S3 S3-Konsole und der REST-API konfigurieren](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html). AWS SDKs Weitere Informationen zu CORS und Beispiele für eine CORS-Konfiguration finden Sie unter [Elemente von CORS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ManageCorsUsing.html#cors-example-1).
## Fehler 403 Forbidden: Diese CORS-Anfrage ist nicht zulässig
Sie erhalten den Fehler `403 Forbidden`, wenn eine CORS-Regel in Ihrer CORS-Konfiguration nicht den Daten in Ihrer Anfrage entspricht.
Fehler: HTTP/1.1 403 Forbidden CORS Response: This CORS request is not allowed.
Daher kann der Fehler `403 Forbidden` aus mehreren Gründen auftreten:
+ Ursprung ist nicht zulässig.
+ Methoden sind nicht zulässig.
+ Angeforderte Header sind nicht zulässig.
Für jede von Amazon S3 erhaltene Anfrage benötigen Sie eine CORS-Regel in Ihrer CORS-Konfiguration, die den Daten in Ihrer Anfrage entspricht.
### Ursprung ist nicht zulässig
Der `Origin`-Header in einer CORS-Anfrage an Ihren Bucket muss den Ursprüngen im Element `AllowedOrigins` Ihrer CORS-Konfiguration entsprechen. Ein Platzhalterzeichen (`"*"`) im Element `AllowedOrigins` würde allen HTTP-Methoden entsprechen. Weitere Informationen zum Aktualisieren des Elements `AllowedOrigins` finden Sie unter [Cross-Origin Resource Sharing (CORS) konfigurieren](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html).
Wenn beispielsweise nur die Domain `http://www.example1.com` im Element `AllowedOrigins` enthalten ist, würde eine von der Domain `http://www.example2.com` gesendete CORS-Anfrage den Fehler `403 Forbidden` erhalten.
Das folgende Beispiel zeigt einen Teil einer CORS-Konfiguration, der die Domäne `http://www.example1.com` im Element `AllowedOrigins` enthält.
```
"AllowedOrigins":[
"http://www.example1.com"
]
```
Damit eine von der Domain `http://www.example2.com` gesendete CORS-Anfrage erfolgreich ist, muss die Domain `http://www.example2.com` in das Element `AllowedOrigins` der CORS-Konfiguration aufgenommen werden.
```
"AllowedOrigins":[
"http://www.example1.com"
"http://www.example2.com"
]
```
### Methoden sind nicht zulässig
Die HTTP-Methoden, die in der `Access-Control-Request-Method` einer CORS-Anfrage an Ihren Bucket angegeben sind, müssen der oder den Methoden entsprechen, die im Element `AllowedMethods` Ihrer CORS-Konfiguration aufgeführt sind. Ein Platzhalterzeichen (`"*"`) in `AllowedMethods` würde allen HTTP-Methoden entsprechen. Weitere Informationen zum Aktualisieren des Elements `AllowedOrigins` finden Sie unter [Cross-Origin Resource Sharing (CORS) konfigurieren](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html).
In einer CORS-Konfiguration können Sie im Element `AllowedMethods` die folgenden Methoden angeben:
+ `GET`
+ `PUT`
+ `POST`
+ `DELETE`
+ `HEAD`
Das folgende Beispiel zeigt einen Teil einer CORS-Konfiguration, der die Methode `GET` im Element `AllowedMethods` enthält. Nur Anfragen, die die Methode `GET` enthalten, wären erfolgreich.
```
"AllowedMethods":[
"GET"
]
```
Wenn eine HTTP-Methode (z. B. `PUT`) in einer CORS-Anfrage verwendet wurde oder in einer Preflight-CORS-Anfrage an Ihren Bucket enthalten war, die Methode jedoch nicht in Ihrer CORS-Konfiguration vorhanden ist, führt die Anfrage zu einem Fehler des Typs `403 Forbidden`. Um diese CORS- oder CORS-Preflight-Anfrage zuzulassen, muss die Methode `PUT` zu Ihrer CORS-Konfiguration hinzugefügt werden.
```
"AllowedMethods":[
"GET"
"PUT"
]
```
### Angeforderte Header sind nicht zulässig
Die im Header `Access-Control-Request-Headers` einer Preflight-Anfrage aufgeführten Header müssen den Headern im Element `AllowedHeaders` Ihrer CORS-Konfiguration entsprechen. Eine Liste mit üblichen Headern, die in Anforderungen an Amazon S3 verwendet werden können, finden Sie unter [Häufig verwendete Anforderungsheader](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html). Weitere Informationen zum Aktualisieren des Elements `AllowedHeaders` finden Sie unter [Cross-Origin Resource Sharing (CORS) konfigurieren](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html).
Das folgende Beispiel zeigt einen Teil einer CORS-Konfiguration, der den Header `Authorization` im Element `AllowedHeaders` enthält. Nur Anfragen für den Header `Authorization` wären erfolgreich.
```
"AllowedHeaders": [
"Authorization"
]
```
Wenn ein Header (z. B. `Content-MD5`) in einer CORS-Anfrage enthalten war, jedoch nicht in Ihrer CORS-Konfiguration vorhanden ist, führt die Anfrage zu einem Fehler des Typs `403 Forbidden`. Um diese CORS-Anfrage zuzulassen, muss der Header `Content-MD5` zu Ihrer CORS-Konfiguration hinzugefügt werden. Wenn Sie sowohl den Header `Authorization` als auch den Header `Content-MD5` in einer CORS-Anfrage an Ihren Bucket übergeben möchten, stellen Sie sicher, dass beide Header im Element `AllowedHeaders` Ihrer CORS-Konfiguration enthalten sind.
```
"AllowedHeaders": [
"Authorization"
"Content-MD5"
]
```
## Header nicht in der CORS-Antwort gefunden
Das Element `ExposeHeaders` Ihrer CORS-Konfiguration identifiziert, welche Antwort-Header Sie für Skripts und Anwendungen, die in Browsern ausgeführt werden, als Antwort auf eine CORS-Anfrage zugänglich machen möchten.
Wenn Ihre in Ihrem S3-Bucket gespeicherten Objekte benutzerdefinierte Metadaten (z. B.`x-amz-meta-custom-header`) zusammen mit den Antwortdaten haben, könnte dieser benutzerdefinierte Header zusätzliche Metadaten oder Informationen enthalten, auf die Sie über Ihren JavaScript clientseitigen Code zugreifen möchten. Standardmäßig blockieren Browser jedoch aus Sicherheitsgründen den Zugriff auf benutzerdefinierte Header. Damit Ihre Client-Seite auf benutzerdefinierte Header zugreifen JavaScript kann, müssen Sie den Header in Ihre CORS-Konfiguration aufnehmen.
Im folgenden Beispiel ist der Header `x-amz-meta-custom-header1` im Element `ExposeHeaders` enthalten. Der Header `x-amz-meta-custom-header2` ist nicht im Element `ExposeHeaders` enthalten und fehlt in der CORS-Konfiguration. In der Antwort würden nur die im Element `ExposeHeaders` enthaltenen Werte zurückgegeben werden. Hätte die Anfrage den Header `x-amz-meta-custom-header2` im Header `Access-Control-Expose-Headers` enthalten, würde die Antwort trotzdem `200 OK` zurückgeben. Es würde jedoch nur der zulässige Header, z. B. `x-amz-meta-custom-header`, zurückgegeben und in der Antwort angezeigt werden.
```
"ExposeHeaders": [
"x-amz-meta-custom-header1"
]
```
Um sicherzustellen, dass alle Header in der Antwort erscheinen, fügen Sie dem Element `ExposeHeaders` Ihrer CORS-Konfiguration alle zulässigen Header hinzu, wie unten gezeigt.
```
"ExposeHeaders": [
"x-amz-meta-custom-header1",
"x-amz-meta-custom-header2"
]
```
## Überlegungen zu CORS in S3-Proxy-Integrationen
Wenn bei Ihnen Fehler auftreten und Sie die CORS-Konfiguration in Ihrem S3-Bucket bereits überprüft haben und die Cross-Origin-Anfrage an Proxys wie gesendet wird, versuchen Sie Folgendes: AWS CloudFront
+ Konfigurieren Sie die Einstellungen so, dass die Methode `OPTIONS` für HTTP-Anfragen zulässig ist.
+ Konfigurieren Sie den Proxy so, dass er die folgenden Header weiterleitet: `Origin`, `Access-Control-Request-Headers` und `Access-Control-Request-Method`.
+ Konfigurieren Sie die Proxyeinstellungen so, dass der Origin-Header in den Cache-Schlüssel aufgenommen wird. Dies ist wichtig, da das Zwischenspeichern von Proxys, die den Origin-Header nicht in ihrem Cache-Schlüssel enthalten, zwischengespeicherte Antworten bereitstellen kann, die nicht die entsprechenden CORS-Header für unterschiedliche Ursprünge enthalten.
Einige Proxys bieten vordefinierte Features für CORS-Anfragen. In können Sie beispielsweise eine Richtlinie konfigurieren CloudFront, die die Header enthält
die CORS-Anforderungen (Cross-Origin Resource Sharing) aktivieren, wenn der Ursprung ein Amazon S3 Bucket ist.
Diese Richtlinie hat folgende Einstellungen:
+ Header, die in Ursprungsanfragen enthalten sind:
`Origin`
`Access-Control-Request-Headers`
`Access-Control-Request-Method`
+ **Cookies, die in Ursprungsanfragen enthalten sind:** Keine
+ **Abfragezeichenfolgen, die in Ursprungsanforderungen enthalten sind:** Keine
Weitere Informationen finden Sie unter [Steuern von Anfragen mit Ursprung mithilfe einer Richtlinie](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.htm) und [Verwenden von Richtlinien für verwaltete Anfragen mit Ursprung](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-origin-request-policies.html#managed-origin-request-policy-cors-s3) im *CloudFront Entwicklerhandbuch*.