No CORS Headers

[Nuli-byte]

Bug report

Required System information

• Node.js version: v16.17.0
• NPM version: 6.14.17
• Strapi version: 4.3.8
• Database: SQLite
• Operating system: Windows 10

Describe the bug

There is no CORS headers when i request the api.

Steps to reproduce the behavior

1. Launch "npx create-strapi-app@latest strapi-4.3.8 --no-run"
2. Change the port ".env" to 3000
3. Start the app in developpement mode and add content
4. Request the API

Expected behavior

By default (from the documentation), there should be an "access-control-allow-origin : '*'" header.

Screenshots

[majjikishore007]

Hi, @kasonde is this issue still there? if not resolved, can I work on this

[davidenke]

Hi, @kasonde is this issue still there? if not resolved, can I work on this

@majjikishore007 I'm having this issue as well, running 4.3.9 locally. Checked with Postman.

[CleberRossi]

I think this problem is because of how koa/js handles requests with missing Origin header.

I just opened a PullRequest for Koarjs/cors in order to fix the call for options handlers, even if Origin header is not sent. Follow req: https://www.rfc-editor.org/rfc/rfc6454#section-7.3

I Believie I'll fix this Koa/js Issue:
koajs/cors#18

After fixing it - If my Fix is right - I think we will need to check the default credentials true and allow with '*' as default. I am not sure if all request should have default credentials as true:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials

To correct this problem on the client side, ensure that the credentials flag's value is false when issuing your CORS request.

If the request is being issued using XMLHttpRequest, make sure you're not setting withCredentials to true.
If using Server-sent events, make sure EventSource.withCredentials is false (it's the default value).
If using the Fetch API, make sure Request.credentials is "omit".
If, instead, you need to adjust the server's behavior, you'll need to change the value of Access-Control-Allow-Origin to grant access to the origin from which the client is loaded.

In order to FIX

• Wait if Koa/js PR is merged
• If so, set default credentials as false on strapi and origin to '*'
• Permit, if not is already, credentials to be overloaded as true

[CleberRossi]

@Nuli-byte @davidenke

In order to prioritize security, I left credentials as true as default. This means that the api will not responde with ´*' , as default, despite the configuration is.
We need to undestand that the default behavior is following Cors protocol and the default configuration is being followed.

Now, you guys have the possibility to set credentials as false and, even though origin is not being set on request header, you will see Access-Control-Allow-Origin as '*' as response.

How to set Access-Control-Allow-Origin as '*' ?

Set credentials as false on config/middlewares.js, call any API in order to retrive Access-Control-Allow-Origin as '*' as DEFAULT.

{
    name: 'strapi::cors',
    config: {
      credentials: false,
    },
  },

[derrickmehaffy]

reopening as the fix was reverted in #14677 since it was a breaking change.

[strapi-bot]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/i-dont-see-the-cors-access-origin-headers-in-the-response-headers/30646/3

[lorenlew]

the vulnerability was discoved recently CVE-2023-49803(GHSA-qxrj-hx23-xp82)
the fix in koa/cors/v/5.0.0 which has been published yesterday

[derrickmehaffy]

the vulnerability was discoved recently CVE-2023-49803(GHSA-qxrj-hx23-xp82) the fix in koa/cors/v/5.0.0 which has been published yesterday

That vuln doesn't apply to us as we intentionally set the origin by default as *

[lorenlew]

@derrickmehaffy ah true, default cors middleware has "*" value.
But anyways it is overly permissive origin policy (similar issue as in the vulnerability I mentioned).

Is it possible to deactivate CORS completely, if one does not need it? e.g. calling strapi API from the server side (nextjs) and not from the browser.

[derrickmehaffy]

@derrickmehaffy ah true, default cors middleware has "*" value.
But anyways it is overly permissive origin policy (similar issue as in the vulnerability I mentioned).

Is it possible to deactivate CORS completely, if one does not need it? e.g. calling strapi API from the server side (nextjs) and not from the browser.

Possible yes if you needed to. Yes our default is overly permissive on the origin but we can't set the origin without knowing it and we don't. Users have to configure that when they deploy.

[dassiorleando]

Hello there, is this still a pending issue? Or is it fixed somewhere else?
We will be happy to have it working like before, Thanks.

[ExploHash]

I currently have issues with this on 4.24.0, allowed origin header stays empty no matter what I change in the cors middleware config. 4.23.1 is unaffected though.

[simwai]

@ExploHash +1, so damn annoying

[derrickmehaffy]

I currently have issues with this on 4.24.0, allowed origin header stays empty no matter what I change in the cors middleware config. 4.23.1 is unaffected though.

origin is always empty on same-site, only cross domain does the browser send that header

[simwai]

I changed the koa cors version back to an earlier by setting an overrides entry in the package.json file, and then at least the empty origin access control header was gone, and I could set the missing header by Apache. Overriding empty header keys seems not to be a strength of Apache.

[ExploHash]

I currently have issues with this on 4.24.0, allowed origin header stays empty no matter what I change in the cors middleware config. 4.23.1 is unaffected though.

origin is always empty on same-site, only cross domain does the browser send that header

Hmm previously no header was sent at all, so maybe it's just a symptom not the problem. All I know is that after upgrading I have cors errors and the header wasn't set. When I reverted back a version it worked again.

[FlorianH]

I have the same problem, as far as I can tell. My frontend does an OPTIONS request, does not get any Access-Control-Allow-Origin back and the browser blocks the actual request (GET) because of missing access control.

This is my error message in the browser:
Access to XMLHttpRequest at 'http://localhost:1337/api/getMe' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Strapi 4.24.3 on node.js 18.17.1

[Anubiso]

We have the same issue, after upgrade to 4.24.x Access-Control-Headers are missing:

4.23.1 headers:

In our example we pinned all the versions but changed only @strapi/strapi from 4.23.1 to 4.24.4.
We also tried to pin @koa/cors to version 3.4.3 and use @strapi/strapi in version 4.24.4 but this also didn't help.

[simwai]

When you have no Access-Control-Header with empty value you can easily set the header by this Apache server config:

HTTP

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

HTTPS

# Proxy settings
ProxyPass / http://localhost:13370/
ProxyPassReverse / http://localhost:13370/
ProxyPreserveHost On
ProxyRequests Off

# Header settings
RequestHeader set X-Forwarded-Host %{HTTP_HOST}s
RequestHeader set X-Forwarded-Server %{HTTP_HOST}s
RequestHeader set X-Real-IP %{REMOTE_ADDR}s
RequestHeader set X-Forwarded-For %{HTTP_X_FORWARDED_FOR}s
RequestHeader set X-Forwarded-Proto %{REQUEST_SCHEME}s
RequestHeader set Host %{HTTP_HOST}s
RequestHeader set Upgrade %{HTTP_UPGRADE}s
RequestHeader set Connection "Upgrade"

# CORS headers
# Header set Access-Control-Allow-Origin "http://localhost:42000" "expr=-z %{req:Access-Control-Allow-Origin}"
Header set Access-Control-Allow-Origin "*" "expr=-z %{req:Access-Control-Allow-Origin}"
Header set Access-Control-Allow-Headers "Authorization"