Request: Configure CORS for StaticWebApp

[Strepto]

Is your feature request related to a problem? Please describe.

We are creating a solution where the files hosted on our static web app should also be available from a separate website.
Currently that is blocked by CORS, and I cannot find a way to configure it.

The use-case we have is a shared "Portal" website that is embedding different web-apps on separate domains. This means that releases of the web-apps are independent of the portal, but that the portal needs to access these various services from the browser.

We are currently hosting these web-apps on AppService, but would like to use static apps instead. But we are blocked by CORS in the browser, and cannot find a way to enable

Is there any plans for adding CORS configuration?

Describe the solution you'd like

Exposed CORS whitelist for specific domains.

Describe alternatives you've considered

N/A

[manekinekko]

@Strepto Have you tried setting this up using a globalHeaders entry in your staticwebapp.config.json?

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Methods": "GET, POST, PUT"
  }
}

You can also enable those headers for a specific route. See an example in the SWA playground. Let me know if that solved your issue.

[Strepto]

This works great, and I did not know about this.

We would like to be able to whitelist/allowlist multiple domains. So that would be a further feature request. As far as I know the allow origin header is for a single domain at a time (OR wildcard).

[SchulteMarkus]

You can also enable those headers for a specific route.

Can you maybe give an staticwebapp.config.json example for doing so? Having Access-Control-Allow-Origin": "*" only for /articles/*.html?
I had a look at the SWA playground, but well, I don't see where I can get the actual parameters for staticwebapp.config.json

[xiningli]

@Strepto Have you tried setting this up using a globalHeaders entry in your staticwebapp.config.json?

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Methods": "GET, POST, PUT"
  }
}

You can also enable those headers for a specific route. See an example in the SWA playground. Let me know if that solved your issue.

Unfortunately, it doesn’t work for me. But the same server code can work in Vercel, so I don’t think that’s related to my server settings.

[agravity-philipp]

@manekinekko can you verify this solution is still working?

I have added the globalHeaders as well to the staticwebapp.config.json. But without success.

On my static web app my API is not available from my localhost:
Access to XMLHttpRequest at 'https://xxxxxxxxxxx.azurestaticapps.net/api/version' from origin 'http://localhost:4200' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Any idea?

[xiningli]

@manekinekko can you verify this solution is still working?

I have added the globalHeaders as well to the staticwebapp.config.json. But without success.

On my static web app my API is not available from my localhost: Access to XMLHttpRequest at 'https://xxxxxxxxxxx.azurestaticapps.net/api/version' from origin 'http://localhost:4200' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Any idea?

I think you are using NextJS, right? No CORS for nextjs for now

[agravity-philipp]

@xiningli We are using C# for API and for SWA we use Angular / Typescript.

[xiningli]

won't work for nextjs... and the next.config.js also won't work for async headers()

[michaelsoriano]

@xiningli - We're running into the same issue - using NextJS 13. Stuck on CORS issue. globalHeaders, nextConfig - all don't work. How did you fix the issue? Thx.

[AlnisS-ptc]

I'm having trouble getting CORS requests to API (function) endpoints in an Azure Static Web App to work with custom headers (and, in fact, it seems any non-"simple" CORS request).

My staticwebapp.config.json looks like the following:

{
  "globalHeaders": {
    "Access-Control-Allow-Headers": "x-custom",
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Methods": "*"
  }
}

Note: I'm also adding these headers within the function response, but the failure happens at preflight, NOT function execution.

Requests go through without the custom header, but have a CORS preflight failure when the custom header is added. It seems that any request that triggers a preflight to an /api/* route fails - for example, "PUT" verb.

My guess is that there is something else in Azure Static Web Apps that's blocking non-simple requests to API routes. However, this does not happen in the command line simulator (swa start) which seems to disregard the header rules for the preflight from staticwebapp.config.json and always allow the CORS request to proceed to function execution.

The use case here is that we are building a shared data service used by multiple small & independent applications, and while in principle we could set up a proxy for each application to the data service (which would also avoid the latency penalty from CORS preflight requests), in practice that adds a lot of complexity to the system, since we then have N proxies/backends to monitor & maintain in addition to the data service, rather than 1 universal data service (and a bunch of front-end-only applications).

---

EDIT: late night update... I just found a solution to controlling CORS preflight responses on api endpoints! Yay! I guess the problem was in the chair (me), not in the computer...

You can adjust the function host.json settings to include custom headers that allow cross origin requests.

I added the following to /api/host.json in my project:

  "extensions": {
    "http": {
      "routePrefix": "api",
      "customHeaders": {
        "Access-Control-Allow-Headers": "x-custom",
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Methods": "*"
      }
    }
  }

Now, the preflights pass and CORS is working.

It would probably be nice to have a hint about this in the documentation. The way I read the "Global headers" section was that these headers would be applied to every response in the static web app—including the api—when in reality they only (seem) to apply to static content, and the managed functions API's headers are controlled in host.json. i.e., if you specify an api route in globalHeaders it actually won't apply it to the API—you need to do this in host.json.

In retrospect, this makes sense, but it sure took me a lot of time to figure out...