Una empresa aloja una aplicación web del lado del cliente en un bucket de S3 y la sirve a través de CloudFront en https://www.example.com. El desarrollador consolida archivos JavaScript y fuentes web comunes en un bucket central de S3 para su reutilización por múltiples sitios subsidiarios, pero los navegadores bloquean esos archivos JS y de fuentes compartidos durante las pruebas. ¿Qué debe hacer el desarrollador para que los navegadores permitan que los archivos JavaScript compartidos y las fuentes web sean utilizados por las otras aplicaciones web?

La respuesta correcta es agregar una configuración de cross-origin resource sharing (CORS) al bucket central de S3. Los navegadores web implementan una política de seguridad de mismo origen que restringe las solicitudes HTTP realizadas desde un origen diferente al que sirvió la página web. Para permitir que las aplicaciones web en https://www.example.com carguen recursos (como JavaScript y fuentes web) desde un bucket S3 central que se considera un origen diferente, el bucket S3 debe configurarse con CORS para permitir estas solicitudes de origen cruzado. Las opciones incorrectas son: Crear puntos de acceso de S3 no resuelve el problema de la política de seguridad de mismo origen del navegador. Los puntos de acceso son para acceder a datos de S3 a través de la red de AWS o desde una VPC, no para habilitar solicitudes de origen cruzado del navegador. Adjuntar una política de bucket que permita el acceso desde otros buckets de aplicaciones web no es suficiente. Aunque la política de bucket podría permitir el acceso a nivel de S3, no aborda la restricción de seguridad del navegador. Incluir un encabezado Content-MD5 es para la verificación de integridad del mensaje y no tiene relación con la política de seguridad de mismo origen del navegador o CORS.