Let’s talk
← All insights
ENGINEERING JOURNAL / Google Cloud Operations

Cloud Storage CORS: Check the Endpoint Before the Rule

Fix Cloud Storage browser access by identifying JSON, XML, or browser-download endpoints, reproducing preflight headers, and verifying the intended origin.

Clouvenix Engineering notes · 3 min read · 20 Oct 2026
Cloud Storage CORS: Check the Endpoint Before the RuleCloud Storage CORS: Check the Endpoint Before the Rule — conceptual 3D-style vector showing Web application origin, Endpoint choice, JSON API behavior, XML bucket CORS, Browser download URL, Browser acceptance.. Conceptual teaching illustration; connections show the investigation flow rather than a vendor deployment topology.CLOUVENIX / GOOGLE CLOUD OPERATIONSCloud Storage CORS: Check the Endpoint Before the Rule01Web application origin02Endpoint choice03JSON API behavior04XML bucket CORS05Browser download URL06Browser acceptanceConceptual investigation flow / Cloud Storage CORS: Check the Endpoint Before the Rule
Cloud Storage CORS: Check the Endpoint Before the Rule — conceptual 3D-style vector showing Web application origin, Endpoint choice, JSON API behavior, XML bucket CORS, Browser download URL, Browser acceptance.

Browser policy depends on the endpoint

CORS is a browser-enforced cross-origin access mechanism. It does not grant Cloud Storage object permission. A request can pass CORS and still lack authorization, or possess valid authorization and still be unusable by browser JavaScript because the cross-origin response is not accepted.

Cloud Storage endpoints do not all behave alike. Official documentation says JSON API endpoints return their default CORS behavior, XML API endpoints evaluate bucket CORS configuration, and the authenticated browser-download endpoint at storage.cloud.google.com does not allow CORS requests. Editing bucket rules while testing the wrong endpoint can therefore produce repeated changes with no useful effect.

Prepare the exact application origin, failing request URL, method, request headers, and browser developer-tools trace. Use a nonproduction bucket and harmless object to reproduce the issue. Record the origin with scheme and port; a different development port is a different origin even on the same hostname.

Reproduce what the browser sends

  1. Inspect the network trace to identify the endpoint and whether an OPTIONS preflight occurs. Record Origin, requested method, and requested headers. A command-line download without those headers does not reproduce browser behavior.
  2. Read bucket configuration using gcloud storage buckets describe gs://BUCKET_NAME --project=PROJECT_ID. Review CORS entries only in the context of the endpoint being used. Match the required application origin and method, and expose only the response headers the application needs to read.
  3. Reproduce a safe preflight with a command such as curl -i -X OPTIONS 'https://storage.googleapis.com/BUCKET_NAME/test.txt' -H 'Origin: https://app.example.test' -H 'Access-Control-Request-Method: GET'. If the real browser requests additional headers, include the corresponding preflight header in the controlled test.
  4. Apply a narrowly reviewed rule or correct the client endpoint, then retest in the actual browser. Account for preflight caching when comparing results. Avoid a broad wildcard rule merely to discover whether the application is using the wrong URL.

Illustrative scenario

A fictional web editor copies an object's console-provided browser-download link into a JavaScript fetch call. The team adds a bucket CORS rule repeatedly, but the browser still rejects the operation. Once the endpoint is identified as the authenticated browser-download service, the application switches to its supported storage request flow and validates authorization and CORS independently. The bucket's existing private access model remains part of the design.

ObservationCheckCorrection
Rule edits have no apparent effectActual endpoint familyUse supported endpoint behavior
Local development fails, production worksScheme, host, and portAdd the intended exact development origin
Preflight succeeds, object request failsObject authorization and methodRepair the request's access contract
JavaScript cannot read one response headerExposed response headersExpose the specific required header

Verify the complete browser operation

Test the actual upload, download, or metadata read from the intended application origin. Inspect both preflight and final response. Confirm the application can read the necessary headers and handle unauthorized or missing-object responses. Try an unapproved test origin to establish the intended boundary for XML API rules. Never infer security from CORS alone; access control still governs who may use the object.

Operating procedure

Keep the endpoint, allowed origins, methods, and response-header requirements alongside the frontend integration. Review rules when adding domains, preview environments, or new HTTP headers. Monitor browser failures separately from service-side authorization errors. Retire obsolete development origins after their owners confirm they are unused.

Explore Clouvenix cloud architecture for implementation and operational handover.

Technical reference

CORS behavior, configuration, and examples.