Astro CORS

A decoupled (Astro) storefront calls Magento’s GraphQL and REST APIs cross-origin — which the browser blocks unless Magento returns the right CORS headers. Astro CORS adds those headers correctly and safely: a configurable origin allow-list per API, spec-safe wildcard/credentials handling, fast preflight responses, and an optional redirect that points the backend’s leftover Luma pages at your real storefront.

Compatibility

Magento

Open Source 2.4.9 GA (and later 2.4.x).

PHP

Tested on 8.4 and 8.5.

Scope

Separate CORS policies for GraphQL and REST.

Security

Spec-safe: wildcard origin and credentials are never combined.

What it does

1. Allow-list your storefront origins for GraphQL and REST separately.

2. On every API response from an allowed origin, it sets Access-Control-Allow-Origin (the exact origin, echoed back), Vary: Origin, and — when enabled and safe — Access-Control-Allow-Credentials.

3. OPTIONS preflights are short-circuited at app launch: the request never runs the full router, it just gets the Allow-Methods / Allow-Headers / Max-Age headers back immediately.

4. (Optional) Headless redirect: browseable Luma pages on the Magento host are redirected to your storefront URL, while /graphql, REST, the admin and /media + /static stay put.

Wildcard + credentials is a hole — and it's handled

Returning Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true lets any site make authenticated cross-origin requests — a serious CORS vulnerability and something the spec forbids. When you set origins to *, this module returns * for the origin but never emits Allow-Credentials. For credentialed requests, use an explicit origin allow-list (the origin is then echoed back exactly).

Configuration

Stores → Configuration → AgenticEcom · Headless & Astro → Astro CORS

GraphQL / REST policy

Each API has its own policy:

Field	What it does
Allowed Origins	Comma-separated origins (https://store.example.com), or * for any.
Allowed Methods	e.g. GET, POST, OPTIONS.
Allowed Headers	e.g. Content-Type, Authorization, Store.
Allow Credentials	Send Allow-Credentials: true (ignored for the * origin).
Max Age	Preflight cache lifetime in seconds (e.g. 86400).
Exposed Headers	Response headers the browser may read.

Headless redirect

Field	What it does
Enable Headless Redirect	Redirect the backend’s Luma pages to your storefront.
Storefront URL	Absolute base URL of your decoupled storefront.
Redirect Type	301 (recommended) or 302.
Allowed Front Names	Path segments that must keep working on the backend (e.g. sociallogin, payment return URLs).

Both APIs covered

The same correct behaviour applies to GraphQL and REST — origin echoed for allow-listed origins, Vary: Origin set so caches don’t cross-serve, and preflights answered fast. Set the two policies independently (your storefront may need different headers for each).

FAQ

My preflight passes but the real request is still blocked — why?

For CORS to work, both the OPTIONS preflight and the actual GraphQL/REST response need Access-Control-Allow-Origin. This module sets it on both — for the actual response too, not just the preflight — so an allow-listed origin gets a usable response.

Can I allow any origin?

Yes, set Allowed Origins to *. Note that credentials are then disabled (per the CORS spec). If your storefront sends cookies/credentials, list its exact origin instead.

Will it break the admin or media files?

No. The optional headless redirect only affects browseable storefront pages — /graphql, REST, the admin, and /media + /static assets are explicitly never redirected, and you can allow-list extra front names (OAuth callbacks, payment returns) that must keep working.

Is it secure?

Yes — origins are matched exactly (no substring/regex tricks), the wildcard+credentials hole is prevented, Vary: Origin is always set, and the config is behind the AgenticEcom_AstroCors permission. Verified clean on PHP 8.4 and 8.5.