Politique S3 CORS pour le bucket public

Question

Il semble que ce soit facile, mais je ne sais pas ce qui me manque. J'ai un bucket public avec un script js que je récupère depuis mon site web. J'ai remarqué que je n'envoie pas l'en-tête Origin à S3, ce n'est pas nécessaire et tout fonctionne sans aucune configuration CORS.

De plus, même après avoir ajouté manuellement l'en-tête Origin à cet appel GET et avoir explicitement interdit GET et mon domaine via :

    http://www.nonexistingdomain.com
    POST
    *

Je peux toujours obtenir le contenu. Qu'est-ce qui se passe ici?

Answer 1

Ok, après une conversation avec Quentin, je pense comprendre où j'interprète mal comment CORS devrait fonctionner. Dans le monde Java, il est très courant de rejeter effectivement les requêtes lorsque l'origine ne correspond pas. Voici un autre fil de discussion où c'est mentionné. Si nous prenons Spring comme exemple (qui est la norme de facto dans le monde Java), voici ce qui se passe lorsque le filtre CORS est ajouté :

    String allowOrigin = checkOrigin(config, requestOrigin);
    ...

    if (allowOrigin == null) {
        logger.debug("Rejet : l'origine '" + requestOrigin + "' n'est pas autorisée");
        rejectRequest(response);
        return false;
    }

où :

/**
 * Appelée lorsque l'une des vérifications CORS a échoué.
 */
protected void rejectRequest(ServerHttpResponse response) {
    response.setStatusCode(HttpStatus.FORBIDDEN);
}

Vous pouvez trouver le code ici.

Mais à ma surprise, ce n'est pas une pratique aussi courante avec d'autres piles et technologies côté serveur. Une autre approche courante serait d'envoyer leur configuration CORS à navigateur et de laisser la décision à celui-ci.

S3 est encore plus délicat : il n'envoie des en-têtes de réponse CORS que lorsque les règles CORS du compartiment correspondent à la demande activée CORS (une demande avec l'en-tête d'origine). Sinon, il n'y aurait pas d'en-têtes de réponse CORS.

Answer 2

La politique de même origine est une fonctionnalité appliquée par les navigateurs qui empêche le JavaScript d'un site Web de lire des données provenant d'un site différent. (Cela empêche les sites Web aléatoires d'utiliser le JavaScript pour contourner votre pare-feu d'entreprise et accéder à votre intranet ou lire votre GMail avec vos cookies).

CORS permet à un site Web de relâcher la politique de même origine pour permettre à d'autres sites Web de lire des données de cette manière.

CORS n'est pas une authentification/autorisation. Votre seau public est public.

Vous n'utilisez pas JavaScript pour lire des données depuis votre seau, vous chargez le JS directement à partir du seau.

Answer 3

Décortiquons le problème et essayons de comprendre les fondamentaux de CORS.

Qu'est-ce que la requête Cross-Origin & CORS?

Requête Cross-Origin: Une demande de ressource (comme une image ou une police de caractères) en dehors de l'origine est connue sous le nom de demande cross-origin.

CORS est utile lorsque vous demandez une ressource protégée depuis une autre origine.

Partage des requêtes Cross-Origin: Une demande d'une ressource protégée (comme une image, une police de caractères ou une requête XHR) en dehors de l'origine est connue sous le nom de demande cross-origin.

Pourquoi avons-nous besoin de CORS lorsque les ressources peuvent être protégées en utilisant des jetons d'authentification/autorisation?

CORS est la première ligne de défense. Lorsque le client (par exemple, les navigateurs) et les serveurs sont tous deux conscients de CORS, les clients ne permettront que les requêtes provenant d'origines spécifiques vers les serveurs tel qu'instruit par les serveurs.

Par défaut, les navigateurs doivent mettre en œuvre le mécanisme de sécurité de la politique de même origine selon les directives de construction du navigateur. Presque tous les navigateurs modernes mettent en œuvre une politique de même origine qui instruit les navigateurs à autoriser les requêtes vers les serveurs si l'origine est la même.

La politique de même origine est un mécanisme de sécurité d'un navigateur, vous pouvez en savoir plus à son sujet ici. C'est en raison de cette fonctionnalité des navigateurs que le navigateur bloque toutes les requêtes lorsque l'origine de destination et l'origine source sont différentes. (Les serveurs ne sont même pas conscients que cela se produit, Incroyable!)

Pour des cas d'utilisations plus simples, lorsque les ressources (js, CSS, images, polices) sont accessibles avec la même origine, il n'est pas nécessaire de se soucier de CORS.

Si les ressources sont hébergées sur une autre origine ou si les ressources XHR sont hébergées sur des serveurs avec un domaine différent de la source, les navigateurs ne refuseront pas la demande cross-origin par défaut. Seules les demandes et les réponses CORS appropriées sont autorisées par les navigateurs pour effectuer des requêtes cross-origin.

Examinons les en-têtes de requête et de réponse.

En-têtes de requête

• Origin
• Access-Control-Request-Method
• Access-Control-Request-Headers

En-têtes de réponse

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Expose-Headers
• Access-Control-Max-Age
• Access-Control-Allow-Methods Access-Control-Allow-Headers

Pour configurer CORS, les en-têtes Origin et Access-Control-Allow-Origin sont nécessaires. Les navigateurs ajoutent automatiquement l'en-tête Origin à chaque requête, donc un développeur doit configurer seulement l'en-tête de réponse Access-Control-Allow-Origin.

Pour protéger l'accès aux ressources uniquement depuis des domaines spécifiques, S3 propose une option pour configurer des règles CORS. Si la valeur de l'en-tête Access-Control-Allow-Origin est *, toutes les demandes cross-origin sont autorisées, sinon définir une liste séparée par des virgules de domaines.

Il y a quelques points à prendre en compte lorsque vous utilisez CORS.

• C'est le premier niveau de défense pour une ressource protégée et non la défense ultime.
• Vous devez toujours implémenter une authentification & autorisation appropriées pour la ressource afin d'effectuer des opérations CRUD sur le serveur.
• L'implémentation de la politique de même origine est une recommandation pour la construction du navigateur et n'est pas obligatoire.
• Les en-têtes CORS sont utiles uniquement lorsque les clients acceptent les en-têtes. Seuls les navigateurs modernes acceptent les en-têtes CORS. Si vous n'utilisez pas les navigateurs pour effectuer la demande de ressources, alors CORS n'est pas applicable.
• Si vous saisissez le lien dans la barre d'adresse du navigateur, les règles CORS ne s'appliquent pas car le navigateur n'envoie pas l'en-tête Origin au serveur. L'en-tête Origin est envoyé par le navigateur uniquement lors de la demande de ressources subséquente (feuilles de style, fichiers js, polices) et les requêtes XHR par l'origine.
  • Si vous accédez au fichier de ressource en saisissant directement le lien dans la barre d'adresse, le navigateur n'envoie pas l'en-tête Origin à cette demande.

Aussi, si vous souhaitez restreindre l'accès GET, utilisez une URL pré-signée S3 sur un compartiment privé.