Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes de CORS

Les rubriques suivantes peuvent vous aider à résoudre certains CORS problèmes courants liés à S3.

403 Erreur interdite : n'CORSest pas activé pour ce compartiment

L'403 Forbiddenerreur suivante se produit lorsqu'une demande d'origine croisée est envoyée à Amazon S3 mais n'CORSest pas configurée sur votre compartiment S3.

Erreur : HTTP/1.1 403 CORS Réponse interdite : non CORS activée pour ce compartiment.

La CORS configuration est un document ou une politique contenant des règles qui identifient les origines que vous autoriserez à accéder à votre compartiment, les opérations (HTTPméthodes) que vous prendrez en charge pour chaque origine et d'autres informations spécifiques aux opérations. Découvrez comment configurer CORS sur S3 à l'aide de la console Amazon S3 AWS SDKs, et RESTAPI. Pour plus d'informations CORS et des exemples de CORS configuration, voir Eléments de CORS.

403 Erreur interdite : cette CORS demande n'est pas autorisée

L'403 Forbiddenerreur suivante est reçue lorsqu'une CORS règle de votre CORS configuration ne correspond pas aux données de votre demande.

Erreur : HTTP/1.1 403 CORS Réponse interdite : cette CORS demande n'est pas autorisée.

Par conséquent, cette 403 Forbidden erreur peut se produire pour plusieurs raisons :

Pour chaque demande reçue par Amazon S3, vous devez disposer d'une CORS règle dans votre CORS configuration qui correspond aux données de votre demande.

L'origine n'est pas autorisée

L'Originen-tête d'une CORS demande adressée à votre bucket doit correspondre aux origines de l'AllowedOriginsélément de votre CORS configuration. Un caractère générique ("*") dans l'AllowedOriginsélément correspondrait à toutes les HTTP méthodes. Pour plus d'informations sur la mise à jour de l'AllowedOriginsélément, voir Configuration du partage de ressources entre origines (CORS).

Par exemple, si seul le http://www.example1.com domaine est inclus dans l'AllowedOriginsélément, une CORS demande envoyée depuis le http://www.example2.com domaine recevra l'403 Forbiddenerreur.

L'exemple suivant montre une partie d'une CORS configuration qui inclut le http://www.example1.com domaine dans l'AllowedOriginsélément.

"AllowedOrigins":[
   "http://www.example1.com"
]

Pour qu'une CORS demande envoyée depuis le http://www.example2.com domaine aboutisse, le http://www.example2.com domaine doit être inclus dans l'AllowedOriginsélément de CORS configuration.

"AllowedOrigins":[
   "http://www.example1.com"
   "http://www.example2.com"
]

Les méthodes ne sont pas autorisées

Les HTTP méthodes spécifiées Access-Control-Request-Method dans une CORS demande adressée à votre compartiment doivent correspondre à la ou aux méthodes répertoriées dans l'AllowedMethodsélément de votre CORS configuration. Un caractère générique ("*") correspond à AllowedMethods toutes les HTTP méthodes. Pour plus d'informations sur la mise à jour de l'AllowedOriginsélément, voir Configuration du partage de ressources entre origines (CORS).

Dans une CORS configuration, vous pouvez spécifier les méthodes suivantes dans l'AllowedMethodsélément :

L'exemple suivant montre une partie d'une CORS configuration qui inclut la GET méthode dans l'AllowedMethodsélément. Seules les demandes incluant la GET méthode aboutiront.

"AllowedMethods":[
   "GET"
]

Si une HTTP méthode (par exemplePUT) a été utilisée dans une CORS demande ou incluse dans une demande préalable au vol CORS adressée à votre compartiment mais que cette méthode n'est pas présente dans votre CORS configuration, la demande provoquera une 403 Forbidden erreur. Pour autoriser cette CORS demande ou cette demande CORS avant le vol, la PUT méthode doit être ajoutée à votre CORS configuration.

"AllowedMethods":[
   "GET"
   "PUT"
]

Les en-têtes demandés ne sont pas autorisés

Les en-têtes répertoriés dans l'Access-Control-Request-Headersen-tête d'une demande préalable au vol doivent correspondre aux en-têtes de l'AllowedHeadersélément de votre configuration. CORS Pour obtenir la liste des en-têtes courants pouvant être utilisés dans les demandes adressées à Amazon S3, consultez la section En-têtes de demande communs. Pour plus d'informations sur la mise à jour de l'AllowedHeadersélément, voir Configuration du partage de ressources entre origines (CORS).

L'exemple suivant montre une partie d'une CORS configuration qui inclut l'Authorizationen-tête dans l'AllowedHeadersélément. Seules les demandes relatives à l'Authorizationen-tête aboutiront.

"AllowedHeaders":  [
    "Authorization"
]

Si un en-tête (par exemple) Content-MD5 a été inclus dans une CORS demande mais qu'il n'est pas présent dans votre CORS configuration, la demande provoquera une 403 Forbidden erreur. Pour autoriser cette CORS demande, l'Content-MD5en-tête doit être ajouté à votre CORS configuration. Si vous souhaitez transmettre à la fois les Content-MD5 en-têtes Authorization et les en-têtes d'une CORS demande à votre bucket, vérifiez que les deux en-têtes sont inclus dans l'AllowedHeadersélément de votre CORS configuration.

"AllowedHeaders":  [
    "Authorization"
    "Content-MD5"
]           

En-têtes introuvables dans la réponse CORS

L'ExposeHeadersélément de votre CORS configuration identifie les en-têtes de réponse que vous souhaitez rendre accessibles aux scripts et aux applications exécutés dans les navigateurs, en réponse à une CORS demande.

Si vos objets stockés dans votre compartiment S3 comportent des métadonnées définies par l'utilisateur (par exemple,x-amz-meta-custom-header) en plus des données de réponse, cet en-tête personnalisé peut contenir des métadonnées ou des informations supplémentaires auxquelles vous souhaitez accéder à partir de votre code côté client JavaScript . Toutefois, par défaut, les navigateurs bloquent l'accès aux en-têtes personnalisés pour des raisons de sécurité. Pour permettre à votre client JavaScript d'accéder aux en-têtes personnalisés, vous devez inclure l'en-tête dans votre configuration. CORS

Dans l'exemple ci-dessous, l'x-amz-meta-custom-header1en-tête est inclus dans l'ExposeHeadersélément. Le x-amz-meta-custom-header2 n'est pas inclus dans l'ExposeHeadersélément et est absent de la CORS configuration. Dans la réponse, seules les valeurs incluses dans l'ExposeHeadersélément seraient renvoyées. Si la demande incluait l'x-amz-meta-custom-header2en-tête dans l'Access-Control-Expose-Headersen-tête, la réponse renverrait toujours un200 OK. Cependant, seul l'en-tête autorisé, par exemple, x-amz-meta-custom-header serait renvoyé et affiché dans la réponse.

"ExposeHeaders":  [
    "x-amz-meta-custom-header1"
]           

Pour vous assurer que tous les en-têtes apparaissent dans la réponse, ajoutez tous les en-têtes autorisés à l'ExposeHeadersélément dans votre CORS configuration, comme indiqué ci-dessous.

"ExposeHeaders":  [
    "x-amz-meta-custom-header1",
    "x-amz-meta-custom-header2"
]           

Considérations CORS relatives aux intégrations de proxy sur S3

Si vous rencontrez des erreurs et que vous avez déjà vérifié la CORS configuration de votre compartiment S3 et que la demande cross-origin est envoyée à des proxys tels que AWS CloudFront, essayez ce qui suit :

Certains proxys fournissent des fonctionnalités prédéfinies pour les CORS demandes. Par exemple, dans CloudFront, vous pouvez configurer une politique qui inclut les en-têtes qui activent les CORS demandes lorsque l'origine est un compartiment S3. Pour plus d'informations, consultez les sections Contrôler les demandes d'origine à l'aide d'une politique et Utiliser des politiques de demande d'origine gérées dans le Guide du CloudFront développeur.