-1

So I want a same-origin policy which only allows my API to be called from the same-origin in browser, I don't want CORs.

After hours testing whether nginx or my node web app was setting Access-Control-Allow-Origin:* , it turns out that AWS EC2 is setting CORs headers without my permission. I can override this using Nginx to remove response headers and replace (if necessary)...

However I do not believe this is how it should be done, why is AWS putting extra strain on my web server without giving me the option to customise their default "allow all origins"?

This is such an unnecessary problem AWS is creating for me and was wondering if anyone else is experiencing the same and how we should go about it?

What I've tried:

  • In local development without AWS, neither nginx nor my node app add any access control headers (without my permission) - there is no mention of it. I even disabled CORS on my node app to make sure!
  • Turning on cors in my node app to see if I can override the response that is being set by AWS EC2 downstream. This results in two separate Access-Control-Allow-Origin headers, the AWS one taking precedence over mine.
  • Using Nginx to respond to Options, so AWS knows that I have considered CORs requests and that I want to reject them... However my nginx response to Options is once again overrided by AWS downstream on the response! Additionally I would add CORs options to my responses using NGinx but they are still overrided by AWS. when I say AWS overrides my response I mean that, my response is included but so is AWS response. [example AWS with Nginx response][1] [1]: https://i.stack.imgur.com/9xnlr.png

Maybe AWS are saying something, that all API's should be accessible from all origins? just doesn't make sense to me! Btw here is what amazon have to say about cors, that it is "standardised" https://docs.aws.amazon.com/AWSEC2/latest/APIReference/cors-support.html I don't understand the difference between an EC2 instance running MY API, vs and EC2 API? my main concern is changing the AWS cors headers, which I cant find any help on!

  • EC2 servers are just virtual machines. They run whatever software you want to run on them. If something on AWS is overriding your CORS headers down-stream, then that is either some other software configured on the EC2 server that you need to update, or there is something else like AWS API Gateway or CloudFront in front of the EC2 server that you need to configure, but you haven't provided any information about that so no one here can really tell you how to fix it. – Mark B Oct 11 '22 at 12:53
  • i did think of this after reading some people with similar issues on apache! Thanks for ur help, 2 secs! – Goat Slayer Oct 11 '22 at 12:57
  • So I am running an ec2 instance linux, and running a docker compose with nginx and a simple node app API. I have never touched AWS API gateway, does it default enable? – Goat Slayer Oct 11 '22 at 12:58
  • No nothing is default enabled. There is no "magic" happening here. If you haven't enabled something, then there is just the VM with whatever default software it came with. When you hit your API do you use the IP address of the EC2 instance, or some other URL? – Mark B Oct 11 '22 at 13:01
  • such an odd problem! I have tried with custom domain, domain and IP - the header is always added to all of them although I haven't enabled cors in neither Nginx nor my nodeapp! – Goat Slayer Oct 11 '22 at 13:25
  • maybe I could try it on a different VM image if that is allowed? also I read someone had a similar problem with AWS, that on heroku everything was fine, but when they moved to EC2 this problem appeared! – Goat Slayer Oct 11 '22 at 13:27
  • Why would it not be allowed? – Mark B Oct 11 '22 at 13:28
  • running Ubuntu 22.04 ! will have a look! – Goat Slayer Oct 11 '22 at 13:32
  • So heroku also runs on 22.04, they have quite a longwinded sign up process for my setup! – Goat Slayer Oct 11 '22 at 15:09
  • Thanks for your help Mark, I will add my conclusion above! – Goat Slayer Oct 11 '22 at 15:49

1 Answers1

-1

So after playing around more and realising that the Access-Control-Allow-Origin:* is being returned only by all GET requests, and all successful POST requests (from my own domain - no CORs, as i have it disabled), I thought something has to be up (all my get requests are allowed cross domain).

This post explains it beautifully by Amazon themselves, pretty annoyed they have taken the liberty to take my web security into their own hands, but atleast we know what side they are on now! https://docs.aws.amazon.com/AWSEC2/latest/APIReference/cors-support.html

"For all simple requests such as GET & POST(simple post), the Access-Control-Allow-Origin * is returned" by AMAZON. "Therefore, Amazon EC2 allows any cross-domain origin, and never allows browser credentials, such as cookies." because " Access-Control-Allow-Credentials is never returned" - so cookies should not be at risk of cross-site attacks from this setup I hope. However this setup also encourages spam botting from any domain, which will make amazon more money - which is the only plausible reason for why they have decided to enabled CORs for all simple requests.. @jeff. If you prefer images, and so we can quote amazon on this! Simple Requests Response from EC2

Finally, Amazon EC2 even have the courtesy to accept OPTIONS requests on our behalf, for more dangerous requests - to which they send a response of:

  1. Access-Control-Allow-Origin: * "This is always returned with a * value."
  2. Access-Control-Allow-Credentials is NOT returned. Setting browser for default false which will not send any cookies with the now permitted cross origin requests.
  3. Access-Control-Expose-Headers is NOT returned. EC2 doesn't permit your browser to read response headers?
  4. Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE - "this depends on whether you use our Query API or REST" have no idea what that means but a cross site preflight for my REST API returned GET, OPTIONS, POST - thankfully.
  5. Access-Control-Allow-Headers "Amazon EC2 accepts any headers in preflight requests."

The general sense is that Amazon wants us to outsource basic CORs security to the EC2 instance? Would love to test out the pre-flight they provide better but it seems they do most of the boilerplate and let you decide if you want to accept any complex/notsimple CORs requests - as detailed here https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html

Took me a while and a bit of shock, but glad we got here!

  • 1
    Your entire post is incorrect. This: https://docs.aws.amazon.com/AWSEC2/latest/APIReference/cors-support.html is referring to "The AWS EC2 API". That is the API used to do things like provision EC2 servers. It has nothing to do with the API you happen to be running on your EC2 server. – Mark B Oct 11 '22 at 16:40
  • lol yes that is exactly what i thought when I first encountered this document! I thought I am not using "EC2 API" and ignored it. However, it clearly states afterwards "Amazon EC2 allows the request from any origin by adding Access-Control-Allow-Origin:* to all responses"... Poor documentation and user experience from Amazon's side so I get why it sounds so incorrect, but it is the only explanation for what I experienced! – Goat Slayer Oct 11 '22 at 21:55
  • 1
    No I'm sorry you are incorrect. That is specifically talking about the EC2 API for managing EC2 servers. If AWS intercepted all HTTP traffic to EC2 servers and modified headers that would be a **HUGE** security issue that would have thousands of companies upset and moving their services away from AWS. – Mark B Oct 12 '22 at 11:48