Ein Unternehmen hostet eine clientseitige Webanwendung in einem S3-Bucket und stellt sie über CloudFront unter https://www.example.com bereit. Der Entwickler konsolidiert gängige JavaScript- und Webfont-Dateien in einem zentralen S3-Bucket zur Wiederverwendung durch mehrere Tochter-Websites, aber Browser blockieren diese gemeinsam genutzten JS- und Font-Dateien während des Tests. Was sollte der Entwickler tun, damit Browser die Verwendung der gemeinsam genutzten JavaScript-Dateien und Webfonts durch die anderen Webanwendungen zulassen?

Die korrekte Antwort ist die CORS-Konfiguration. Wenn eine Webanwendung versucht, Ressourcen (wie JavaScript-Dateien oder Webfonts) von einer anderen Domäne zu laden, blockieren Browser dies standardmäßig aus Sicherheitsgründen (Same-Origin Policy). Eine Cross-Origin Resource Sharing (CORS)-Konfiguration im zentralen S3-Bucket teilt dem Browser mit, dass es sicher ist, Anfragen von bestimmten Ursprüngen (den anderen Webanwendungen) zuzulassen. S3-Zugriffspunkte sind für den Zugriff auf Daten innerhalb desselben Kontos oder über Konten hinweg gedacht und lösen das Problem der ursprungsübergreifenden Ressourcenzugriffe nicht. Eine Bucket-Richtlinie würde den Zugriff auf den Bucket erlauben, aber nicht die Same-Origin Policy des Browsers umgehen, die das Laden von Ressourcen von einer anderen Domäne blockiert. Das Hinzufügen eines Content-MD5-Headers dient der Datenintegrität und hat keinen Einfluss auf die Same-Origin Policy.