An Azure service that provides geospatial APIs to add maps, spatial analytics, and mobility solutions to apps.
CORS for Azure Maps is enforced at the Azure Maps account and at the browser, not by the map style (road vs satellite). To get past the CORS blockage, configure allowed origins on the Azure Maps account, or use a server-side proxy when calling services that do not support CORS.
Use these steps and checks:
- Configure CORS on the Azure Maps account
- In the Azure portal, open the Azure Maps account used by the web app.
- Configure the CORS settings so that the web app’s origin is allowed. The origin is the exact
scheme + host + port(for example,https://www.contoso.comorhttp://localhost:3000). - The CORS configuration is stored in the account properties as a single rule with a list of allowed origins, for example:
{ "location": "eastus", "sku": { "name": "G2" }, "kind": "Gen2", "properties": { "cors": { "corsRules": [ { "allowedOrigins": [ "https://www.azure.com", "https://www.microsoft.com" ] } ] } } } - Ensure the actual origin of the web app is present in
allowedOrigins. Only one CORS rule is supported, but it can contain multiple origins.
- Remember CORS is separate from authentication
- Even with CORS correctly configured, every request to Azure Maps must still include valid authentication (Shared Key, Microsoft Entra ID, or SAS token). CORS does not replace authentication.
- If authentication fails (401/403), the browser may still show CORS-related errors. Confirm that tokens/keys are valid and correctly attached to requests.
- Understand preflight behavior
- For non-simple requests (custom headers, methods other than GET/HEAD/POST, or use of
Authorizationheader), the browser sends anOPTIONSpreflight request. - Azure Maps evaluates the CORS rules during this preflight. If the origin is not in the allowed list, the preflight fails and the browser blocks the actual request.
- Adjust the CORS rule so that the origin used in development (for example,
http://localhost:xxxx) and in production are included.
- For non-simple requests (custom headers, methods other than GET/HEAD/POST, or use of
- If calling other domains (non–Azure Maps) from the map
- When overlaying external services (for example, WMS/WMTS or other geospatial XML/OGC services) that do not have CORS enabled, the browser will block those requests even if Azure Maps itself is configured correctly.
- In that case, use a proxy service:
- Host a small backend endpoint in the same origin as the web app.
- The frontend calls the proxy; the proxy calls the external service server-side and returns the data.
- This pattern is explicitly recommended when loading resources from domains without CORS support.
- When using SAS tokens or other Azure storage–backed assets
- Some Azure storage endpoints used via SAS tokens do not allow browser
fetch()due to their own CORS policies, even if Azure Maps is fine. - In that case, use a backend proxy endpoint (
/api/proxy-asset) that takes the parameters, uses the SAS token server-side, and returns the processed result to the browser.
- Some Azure storage endpoints used via SAS tokens do not allow browser
- Verify with browser dev tools
- Open DevTools (F12) in Edge, reproduce the map load, and inspect the failing network requests.
- Confirm that:
- The
Originheader matches one of the configuredallowedOrigins. - The response from Azure Maps includes
Access-Control-Allow-Originwith that origin (or*if applicable for that endpoint). - Any failing requests to non–Azure Maps domains are either updated to support CORS or routed through a proxy.
- The
Once the Azure Maps account CORS rule includes the web app’s origin and any non–Azure Maps resources are accessed via a proxy (if they lack CORS), the map control can load both road and satellite styles without CORS blockage. Note that CORS preflight requests themselves are not billed as Azure Maps transactions.
References: