54
votes

Erreur Chrome CORS sur demande au serveur de développement localhost à partir du site distant

Vendredi, j'avais un environnement de développement fonctionnel. Lundi, j'en ai eu un cassé. J'ai rencontré ce message d'erreur dans la console Chrome Dev-Tools pour tous mes actifs:

L'accès à CSS Stylesheet à 'http: // localhost: 8080 / build / app.css' from Origin 'http://example.com' a été bloqué par la politique CORS: le client de demande n'est pas un contexte sécurisé et La ressource est dans l'espace d'addition plus privé local .

Y a-t-il une solution rapide pour cela? J'ai essayé de définir l'origine access-control-allow-origin dans mon webpack DevServer.heders config en voire:

config.devServer.headers = {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers': 'Origin, X-Requested-With, Content-Type, Accept'
}


1 commentaires

Oh mon! Comment dois-je accéder à un serveur Web MCU ESP32 de mon ardumower qui ne peut pas servir via HTTPS et qui a une interface Web qui exécute 10.0.0.1 via CORS? Si j'accède à l'interface graphique via HTTPS, je suis bloqué par un contenu mixte! Devrait probablement ouvrir une question distincte. Voici plus d'informations sur la nouvelle fonctionnalité: web. Dev / CORS-RFC1918-Feedback /…


5 Réponses :


67
votes

Réponse originale

J'ai finalement trouvé la réponse, dans ce RFC À propos de CORS-RFC1918 à partir d'un membre de l'équipe chromée. Pour résumer, Chrome a mis en œuvre CORS-RFC1918 , qui empêche les ressources de réseau public des ressources de réseau public des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources de réseau public des ressources publiques des ressources publiques des ressources du réseau public Demander des ressources en réseaux privés - à moins que la ressource de réseaux publics ne soit sécurisée (HTTPS) et que la ressource de réseaux privés fournit des en-têtes COR appropriés (encore non définis).

Il existe également un drapeau chromé que vous pouvez changer pour désactiver Le nouveau comportement pour l'instant: Chrome: // Flags / # Block-Insecure-Private-Network-Requests

Désactivation que l'indicateur signifie que vous réouverture le trou de sécurité que le nouveau comportement de Chrome est signifié pour fermer.


mise à jour 2021 : Quelques mois après avoir posté cette question, le drapeau que j'ai référencé dans ma réponse originale a été supprimé, et au lieu de désactiver une fonctionnalité de sécurité J'ai été obligé de résoudre le problème de manière plus satisfaisante en servant des actifs sur HTTPS.

Update 2022 : Chrome 98 est sorti, et il présente le support pour Demandes de préfilé . Selon l'annonce, les demandes ratées sont censées produire un avertissement et n'ont aucun autre effet, mais dans mon cas, ce sont des erreurs complètes qui rompent mes sites de développement. J'ai donc dû ajouter du middleware pour enseigner webpack-dev-server comment servir les demandes de premier plan.

Accès au réseau privé (anciennement CORS-RFC1918) est une spécification qui interdit les demandes de ressources de réseau moins privées à des ressources de réseau plus privées. Comme HTTP à HTTPS, ou un hôte distant de LocalHost.

La solution ultime consistait à ajouter un certificat auto-signé et un middleware qui a permis les demandes de mon serveur de développement distant à mon LocalHost webpack-dev- Server pour les actifs.

générer des certificats

module.exports = {
  //...
  devServer: {
    https: {
      key: readFileSync("./.ssl/cert.key"),
      cert: readFileSync("./.ssl/cert.crt"),
      cacert: readFileSync("./.ssl/ca.crt"),
    },

    allowedHosts: ".example.dev", // should match host in origin below
    setupMiddlewares(middlewares, devServer) {
      // Serve OPTIONS requests
      devServer.app.options('*', (req, res) => {
        // Only serve if request has expected origin header
        if (/^https:\/\/example\.dev$/.test(req.headers.origin)) {
          res.set({
            "Access-Control-Allow-Credentials": "true",
            "Access-Control-Allow-Private-Network": "true",
            // Using * results in error if request includes credentials
            "Access-Control-Allow-Origin": req.headers.origin,
          })

          res.sendStatus(200)
        }
      }

      return middlewares
    }
  }
}

Configurer webpack-dev-server pour utiliser des certificats et servir Demandes de préfilé

cd path/to/.ssl
npx mkcert create-cert

Trust Certificates

  1. clic droit ca.crt dans Windows Explorer et sélectionnez Installer le certificat
  2. Sélectionnez Utilisateur actuel .
  3. Choisissez Placer tous les certificats dans le magasin suivant , puis parcourir ... , et sélectionner Autorités de certification racine de confiance .
  4. Finition.
  5. Instructions spécifiques à Firefox

    Firefox ne respecte pas votre autoritah! Par défaut. Configurez-le pour le faire avec ces étapes:

    1. Type À propos: config dans la barre d'adresse
    2. Rechercher security.enterprise_roots.enabled
    3. Basculez le paramètre sur true


12 commentaires

J'adorerais voir les règles exactes pour cela. J'ai aussi frappé par cela, mais le serveur "privé" était le serveur Web comprenant la ressource (il figurait sur un bloc IP publiquement alloué mais pas à l'externe roulable), et la ressource était un bootstrap.js < / Code> Hébergé sur CloudFlare. Je crois comprendre qu'il devrait bloquer les ressources chargées de points de terminaison "plus privés" et je vois à peine comment le flat pourrait être considéré comme plus privé à cet égard. Cela pourrait-il considérer l'adresse proxy plutôt que la résolution DNS pour la cible?


Votre serveur privé est-il HTTP et CloudFlare HTTPS?


Oui en effet et aucun n'est sous mon contrôle ... le message d'erreur manque de clarté à mon humble avis, donc apparemment ils considèrent une connexion HTTPS plus privée qu'une connexion HTTP. Cette considération est-elle prioritaire sur les adresses IP privées et publiques? N'oubliez pas que mon hôte "privé" utilise toujours un bloc IP publique, mais pas une routiulation en externe. Ce sont deux définitions valides mais différentes de "privé".


Le cercle auto-signé n'est pas une solution, le navigateur n'accepte pas ceux qui sortent de la boîte. Dummy Extranet-Domain-CERT (via un domaine sur Internet réutilisé pour le serveur extranet) n'est pas une solution, le serveur extranet a une IP (très fixe, très codé) (uniquement accessible via VPN). Créer mon propre CA dans le navigateur est encore plus peu sûr, car je dois alors protéger cette clé CA, ce qui est une surpuissance complète pour un problème aussi simple. Par conséquent, l'Extranet Ressource doit rester http: // ip . Mais il doit toujours être en mesure d'accéder à des http: //127.* bien définis (qui sont sécurisés contre les abus). Échec et mat?


@Tino concernant les certificats auto-signés, dans Windows, vous pouvez cliquer avec le bouton droit sur un fichier .crt , sélectionner Installer le certificat et l'installer sur Autorités de certification de racine de confiance . Dans Firefox, vous devez ensuite aller sur À propos: config et définir security.enterprise_roots.enabled à true . Tous les autres navigateurs acceptent automatiquement vos autorités de confiance dans mon expérience. Vous devrez peut-être redémarrer.


@Tino J'ai mis à jour ma réponse pour inclure les étapes pour générer les certificats et amener vos navigateurs à leur faire confiance


@tvanc merci pour l'idée, mais cela ne m'aide pas. Comme je l'ai écrit, les navigateurs devraient accepter cela prêt à l'emploi, donc l'installation d'un certificat est un non-go car cela contredit le paradigme prêt à l'emploi. Et Windows? La toile! D'où tous les OS s'il vous plaît (qui sont capables d'exécuter une application)! Pensez à Byod, WiFi et http: //1.1/ (où 1.0.0.1 est pas acheminé vers Internet)


@tvanc et btw, Comme vous l'avez noté , j'espère que l'ajout de l'en-tête Access-Control-allow-Private-Network au Webservice localhost fera l'affaire. Mais wicg.github.io/private-network-access est toujours un projet. .


Ma question concernait l'utilisation de webpack-dev-server dans les environnements de développement, où les certificats auto-signés et manuellement installés sont une solution acceptable. Pour la production, il est moins probable que vous ayez des raisons de demander localhost des ressources à partir d'un site distant, et vous utiliseriez des certificats SSL signés traditionnels.


L'accès-control-request-private-network et l'accès-contrôle-allow-private-network déjà pris en charge? Où puis-je vérifier cela?


@musmus wicg.github.io/private-network-access/#heders


@tvanc Je ne sais pas pourquoi vous m'avez référé à ce lien.



38
votes

Juste une façon chromée du client d'ignorer cet avertissement et de rendre les actifs accessibles:

1: Accédez à chrome: // flags / # block-inseccure-private-network-requests

2: Définissez Bloquer les demandes de réseau privé insécurité aux désactivés

Remarque: cela fonctionne bien lorsque vous êtes dans votre propre ordinateur ou votre environnement de développement


2 commentaires

Cela exposait à tout risque de sécurité réel?


2022 ne fonctionne plus: /



4
votes

J'ai pu autoriser les demandes de LocalHost à LocalHost avec la définition d'un nouvel en-tête de serveur vers Fillight et les demandes habituelles:

Access-Control-Allow-Private-Network: true

Source:
https: // web.dev/cors-rfc1918-feedback/#step-2:-sending-preflight-requests-with-a spécial-header


1 commentaires

Montrer comment ou où vous définissez cet en-tête rendrait cette réponse plus utile.



1
votes

Bien que ce soit une bonne chose que Chrome protège désormais les utilisateurs contre les attaques de la contrefaçon de demande croisée (CSRF) ciblant les routeurs et autres appareils sur les réseaux privés, cela signifie également que les applications légitimes, à savoir les applications commerciales, qui reposent sur le site transversal Les demandes de ressources sur les réseaux privés sont affectées négativement et doivent être modifiées. Dans mon entreprise, nous maintenons une application Web qui est exposée publiquement via HTTPS et appelle un service Web sur les imprimantes d'étiquette sur le réseau privé du client. Nous avons fini par développer un proxy qui accepte les demandes de service Web sur un point de terminaison public et sécurisé, et les transmet au service Web sur le réseau privé. Nous mettons maintenant ce proxy disponible pour les autres à utiliser: https://p2prox.io/


1 commentaires

Comme il est actuellement écrit, votre réponse n'est pas claire. S'il vous plaît modifier pour ajouter des détails supplémentaires qui aideront les autres à comprendre comment cela répond à la question posée. Vous pouvez trouver plus d'informations sur la façon d'écrire de bonnes réponses dans le centre d'aide .



0
votes

vient de rencontrer ce sujet, car j'ai eu le même problème avec une instance de serveur Web dans notre réseau local. Ce n'est pas nécessairement un problème complexe. Cela peut arriver, par exemple Si vous incluez des bibliothèques JavaScript à partir de ressources publiques, telles que Vue.js ou Node.js. Pour éviter cela dans un réseau local, stockez une copie de la bibliothèque sur votre serveur local et référencez-la dans vos pages Web. Par exemple. Au lieu d'utiliser:

<script src="./lib/vue.global.min.js"></script>

Utiliser

<script src="https://cdnjs.cloudflare.com/ajax/libs/vue/3.2.31/vue.global.min.js"></script>


0 commentaires