Primary topic Mobile Web
Chrome 157 is tightening Cross-Origin Resource Sharing (CORS) checks for Background Fetch, the API that lets a website hand a large, user-visible download to the browser. For a publisher whose “Save for offline” button retrieves audio, video, or a reading package from a separate CDN, the consequence is concrete: a missing server permission can now make that background job fail. Google lists the change as CORS enforcement for Background Fetch in Chrome 157.
Google announced Chrome 157.0.8103.38 for Android on November 3, 2026, with availability on Google Play over the following days. As of November 4, that is a phased browser update, not evidence that every Android visitor has already received it.
The immediate job for site teams is to check the actual offline-download flow, particularly where it crosses into a media host, storage bucket, or authentication redirect. Opening the file successfully in a browser tab does not establish that the website can retrieve it through Background Fetch.
Which download button is affected?
Background Fetch is a specific API, exposed through a service-worker registration’s backgroundFetch property. It manages transfers with browser-provided progress and cancellation controls and can continue independently of the page that started them. That makes it useful for a reader saving a long podcast before leaving Wi-Fi. It does not mean every file download, service-worker request, or installed PWA uses this mechanism.
Start by checking whether the site calls backgroundFetch.fetch(). A PWA that only caches article pages with ordinary requests has a different download path. Installing a website on the home screen does not, by itself, put its requests through Background Fetch. The API’s documentation describes the browser-managed transfer and the service-worker events that deliver its outcome.
Consider a hypothetical publication at https://reader.example that stores episodes at https://media.reader.example. Those are different origins even though the publisher controls both. An origin includes the scheme, hostname, and port; sharing a brand or parent domain is insufficient. For a cross-origin CORS request, the media server must return the appropriate permission for the requesting site. A file’s being publicly downloadable does not automatically supply that permission.
The browser now carries the request’s real mode
The Chromium implementation change explains the underlying correction: the download service previously used a navigation request mode that bypassed CORS. Background Fetch now passes its original request mode through to the network machinery and preserves it across restarts. A site that happened to work through the old path may therefore have a server configuration problem that the browser now exposes.
Passing a URL string does not avoid this. Background Fetch turns it into a Request, whose defaults in the released code are mode: "cors" and credentials: "same-origin". These settings answer different questions: the mode governs cross-origin access, while the credentials setting controls browser-managed credentials such as cookies.
An explicit mode: "same-origin" restricts the request to its own origin; adding CORS headers to another server does not relax that choice. And mode: "no-cors" is not a Background Fetch repair. The current Background Fetch specification rejects that mode with a TypeError, as does Chrome 157’s implementation.
Make the CDN’s permission match the request
For a straightforward cross-origin download, inspect the response delivered by the CDN or storage endpoint. The allowed-origin header belongs on that response. Adding it to the website’s outgoing request, or only to the HTML served by the main site, cannot grant permission on behalf of the file server.
Public files without browser credentials
For a file deliberately available for any website to read without browser-managed credentials, the server can return:
Access-Control-Allow-Origin: *A request using credentials: "omit" can use that wildcard permission. The default same-origin credentials mode also excludes cookies on a cross-origin request. Choose the setting to match the delivery design; changing credentials is not a substitute for deciding how a protected file is authorized.
Downloads that need cross-origin cookies
If the request uses credentials: "include", the response must name the allowed origin explicitly and include the credentials permission. For the hypothetical publication, that would be:
Access-Control-Allow-Origin: https://reader.example
Access-Control-Allow-Credentials: trueThe Fetch standard’s credential rules reject a wildcard origin with include, even if no cookie happens to accompany a particular request. Cookie policies still apply; include does not guarantee that a cookie will be available or sent. A valid signed URL likewise still needs an appropriate CORS response: authorization to retrieve a file and permission to share its response with another origin are separate requirements.
Check caching at the delivery edge, too. When the allowed-origin response varies according to the incoming Origin, use Vary: Origin and make sure the CDN respects that variation. For a fixed allowed origin or wildcard, consistently emitting the permission avoids cached responses that lack it. The standard’s HTTP-cache guidance explains why a working storage configuration can still produce the wrong browser response.
Finally, audit response headers the application reads after downloading. A successful CORS response does not expose every header to application code. If the offline importer needs a custom metadata header, the server must expose it through Access-Control-Expose-Headers. Chromium’s Chrome 157 browser-test source includes checks for credential mismatches and filtering of unexposed response headers.
Follow redirects, then check the preflight limitation
A download can begin on the website’s own origin and finish somewhere else. An endpoint such as /download/episode may redirect to a storage service or a regional CDN host. Checking only the first URL misses the server that ultimately supplies the file.
The Chrome 157 browser tests explicitly cover this case: a same-origin URL redirecting to a cross-origin resource is expected to fail without the destination’s CORS permission and succeed with it. Audit the redirect chain and the applicable responses, including authentication gateways and alternate file hosts. A permission header on the initial same-origin endpoint does not authorize the external destination.
Requests needing a preflight require additional attention. Ordinary Fetch can send an OPTIONS preflight to ask permission for a method or request header outside the CORS safelist. But the Background Fetch job controller in Chrome 157.0.8103.38 still marks initially cross-origin requests as failed when their methods or headers require that preflight, before passing them to the downloader.
This includes requests with an Authorization header or other non-safelisted request headers. Configuring an OPTIONS response alone is therefore insufficient for that implementation path. A successful ordinary fetch() test does not establish that the equivalent Background Fetch job works. Teams with these authenticated download designs need to validate the real API flow and, where necessary, provide a compatible authorized delivery route or a fallback.
Local Network Access is a separate permission
Google’s CORS announcement also mentions Local Network Access, or LNA. The two checks address different boundaries. CORS governs cross-origin response sharing. Local Network Access controls access to destinations on the user’s local network or machine, such as a home media server or a loopback service.
A normal public CDN does not become a local-network destination merely because it uses another hostname. Conversely, a local server’s correct CORS headers do not grant LNA permission. Chromium’s separate Background Fetch LNA announcement, which targeted Chrome 154, requires the service worker’s origin to have the necessary permission for local or loopback requests. A product that downloads from a local media appliance should check that permission separately; ordinary CDN downloads do not acquire a new local-network permission requirement from this announcement.
Background Sync and caching do different jobs
The similar names can send a repair in the wrong direction. Ordinary Fetch retrieves resources for page or worker code and already follows cross-origin policy. It does not provide Background Fetch’s browser-managed, user-visible transfer lifecycle. Moving a long download into a service worker is not an unlimited-runtime guarantee: the service-worker lifetime rules allow termination of tasks that exceed imposed limits.
Background Sync schedules an opportunity for a service worker to perform work when connectivity permits, such as sending queued changes. The Background Synchronization specification allows browsers to limit retries and event duration. A sync handler that runs ordinary requests still faces those requests’ security rules. It does not turn a large transfer into a Background Fetch job.
The Cache API stores request-and-response pairs under application control. It can hold successfully downloaded content for offline use, but it does not supply a persistent download manager or repair server permissions. The service-worker caching model also keeps these application caches separate from the browser’s HTTP cache. A team may use Background Fetch to transfer a file and Cache storage to retain it; those remain separate responsibilities.
Handle failure before promising offline access
Error handling has two stages. Starting a job can fail, and a successfully registered job can later fail while retrieving its resources. Catching only the promise returned by backgroundFetch.fetch() leaves the latter case uncovered. Handle the service worker’s backgroundfetchfail event as well as backgroundfetchsuccess and backgroundfetchabort.
For diagnosis, inspect event.registration.failureReason. The documented fetch-error value covers CORS problems and network failures, so it cannot identify a missing CDN header on its own. Record the browser build, destination origin, request mode, and credentials mode alongside the outcome, then reproduce the failing route. Other reasons, including an unsuccessful HTTP status or exhausted storage quota, call for different repairs.
Transfer completion is also earlier than the product’s promise that something is available offline. Under the Background Fetch completion lifecycle, response records cease being available after the completion event’s extended lifetime. Persist the required responses during that event and use event.waitUntil() for the asynchronous work. Mark a podcast or reading package ready only after that storage work succeeds. Handle storage-write failures separately: a successful transfer does not guarantee that the application retained its contents.
For a package containing several files, make the outcome understandable. If an audio file was retained but a required accompanying resource failed, the application should not display the same ready state as a complete package. A useful retry action should preserve that distinction instead of leaving a permanent spinner or reporting success when the job was merely registered.
What to verify during the Android rollout
The current ChromeStatus feature record assigns milestone 157 to Android and desktop and states a plan to ship enabled for all users. Google Play’s delivery of the Android browser update still takes place over several days. Neither statement establishes Background Fetch availability in Android WebView, Chrome on iOS, or another browser.
There is a documentation inconsistency worth keeping in mind: older Chrome 154 developer notes also listed CORS enforcement, while the current feature record and October shipping notice specify 157. Check the actual download flow rather than assuming an earlier version is exempt.
Feature-detect backgroundFetch on the active service-worker registration before offering the enhanced download flow. API presence establishes neither that a particular server will pass CORS nor that every browser configuration behaves identically. Keep an appropriate alternative, such as online access or a clearly labeled conventional file download. A file saved through the browser’s normal download interface is not automatically an item in the PWA’s offline library.
For sites already using Background Fetch, a focused migration check should cover:
- The production delivery route. Use the same origins, redirects, credentials, and request headers as the real download button. Check what the CDN actually returns, including cached responses.
- Every resource needed for completion. Include media, supporting files, and any response metadata the importer reads. Exercise both an allowed response and a deliberately missing permission in a controlled test environment.
- Failure and recovery. Confirm that a failed job produces a useful state and retry option, that cancellation stays distinct, and that the site does not announce offline availability before persistence succeeds.
- Interrupted and resumed work. Include existing queued downloads in the migration plan. Chromium’s implementation upgrades legacy stored Background Fetch requests to CORS when their saved request mode is missing, so an older job should not be treated as exempt after an update.
The acceptance check is the reader’s actual task: start the download through the site, let the job finish, reopen the experience offline, and verify that the promised content is usable. For this migration, a reachable file URL and a working download button are only the beginning of that check.