Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
All security implementations bypassed if 'x-forwarded-host: strapi' header is set #2969
What is the current behavior?
https://github.com/strapi/strapi/blob/master/packages/strapi/lib/middlewares/index.js (line 13 - set to true if that header is passed).
https://github.com/strapi/strapi/blob/master/packages/strapi/lib/middlewares/cors/index.js (line 22 - if the ctx.request.admin is true, then the origin is set to *)
Steps to reproduce the problem
What is the expected behavior?
Check that strapi.config.currentEnvironment.security.cors.enabled is enabled before checking the ctx.request.admin.
Hello @markjlaney !
Thank you to report this point.
@lauriejim I'm not quite sure I understand what you're saying, but this is reproducible for React app endpoints and admin server endpoints. Or API endpoints. I just tried it against a content type API and an admin API (admin/currentEnvironment) and I'm able to get the origin * every time.
Ah ok, @lauriejim and I had a discussion in slack. They use that header to disable the CORS setup if the request is coming from the admin panel. The problem is that anyone can set this header and they can disable the CORS policy.
Couldn't you just include your admin panel host in your origin and this header wouldn't be necessary? Like I said, you could check if the CORS policy is enabled first. I mean most people probably aren't running on port 4000 as well so it's not even guaranteed that the hard-coded port value will work. That check itself probably causes people a lot of pain.
referenced this issue
Mar 18, 2019
I agree with all of this @lauriejim @soupette @Aurelsicoko using a header for "security" is super bad and is not at all secure. (not to mention it makes us network engineers life a royal headache when you start scaling).
There needs to be a different way to secure this.
@derrickmehaffy @lauriejim @soupette @Aurelsicoko what's worse is that from what I can tell the CSRF implementation doesn't work independent of the X-FORWARDED header. I've tried removing that X-FORWARDED header myself as a workaround, but the admin app does not send a CSRF token like it should, so I have to come up with my own CSRF solution. Part of this fix should be including the x-csrf-token header in all requests like the koa-lusca library expects.