A company hosts a client-side web app in an S3 bucket and serves it via CloudFront at https://www.example.com. The developer consolidates common JavaScript and web font files into a central S3 bucket for reuse by multiple subsidiary sites, but browsers block those shared JS and font files during testing. What should the developer do so browsers will allow the shared JavaScript files and web fonts to be used by the other web applications?

The correct solution is to add a Cross-Origin Resource Sharing (CORS) configuration to the central S3 bucket. Browsers implement a security feature that restricts web pages from making requests to a different domain than the one that served the original page. This is known as the Same-Origin Policy. Since the shared JavaScript and font files are hosted on a different origin (the central S3 bucket) than the client-side web app (served via CloudFront from another S3 bucket), browsers block these requests by default. A CORS configuration on the central S3 bucket explicitly tells browsers that it's safe to allow requests from specified origins (your subsidiary sites), enabling the shared assets to load. Creating S3 access points is for managing access to objects within a bucket, not for resolving cross-origin browser security policies. Attaching a bucket policy to explicitly allow access from other web application buckets would grant programmatic access to the bucket, but it does not address the browser's Same-Origin Policy. Including a Content-MD5 header is for data integrity verification, not for cross-origin resource sharing.