Disable CORS by default

[konklone]

Elasticsearch currently defaults CORS to being enabled for all domains.

This is a security issue for any developer running Elasticsearch locally at localhost:9200 -- any website they visit can fire off arbitrary HTTP requests to their local machine. This should be disabled by default.

I became aware of this issue during the hubbub over the dynamic scripting vulnerability in 1.1's defaults (now changed in 1.2, and scripting sandboxed in 1.3). CORS magnified the effect of that bug for developers browsing the web, but even with dynamic scripting disabled, websites can still perform arbitrary Elasticsearch actions to a local instance of ES.

When I mention to developers that localhost:9200 is accessible via any website they visit, they are very surprised, as was I. Yes, maybe it's something I and everyone should have understood going in, but that's not happening. And while it may not be unique to Elasticsearch, this isn't a problem with most databases and database-like systems developers are used to running locally.

I've seen people recommend using Elasticsearch in a VM during development, but this is overhead caused by a choice Elasticsearch makes. Elasticsearch's current default CORS setting adds convenience for some, at the expense of security for many developers.

Any plugins or support systems that depend on enabling CORS for Elasticsearch can provide instruction to enable CORS (along with a warning of serious side effects) as part of their installation.

Elasticsearch should provide a safe experience by default. The dynamic scripting issue, which took some time to be seen as a security issue, is now CVE-2014-3120. Elasticsearch should get in front of this one.

[seanherron]

+1 - I know a lot of people running Elasticsearch locally on their machine with no knowledge of these risks, and there seems to be a common (incorrect, as @konklone mentions) belief that browsers restrict requests to localhost.

Sane defaults would most help people new to using Elasticsearch who are unaware of these risks. Enabling CORS is a simple step for people to take if they need that functionality.

[kimchy]

Agreed fully!, it seems like we can preserve the good out of the box experience with matching only localhost origin out of the box, we worked on this to add it: #6923, where the next step is to change the default. We haven't done it yet, the aim is to do it for 1.4 (I will label this issue as well as such). Does that sound reasonable?

[konklone]

This sounds very reasonable, and thank you for taking it seriously!

[rashidkpc]

After some thought I'm not sure there's a strong reason to use a regex to match localhost by default. When an application developer eventually goes to production they'll need to learn about the CORS setting anyway, might as well do it early.

Regex matching is definitely an important feature, but we should probably just turn off CORS (set to null) by default, for the sake of configuration readability.

[bleskes]

+1 on implementing regex support, documenting an example for allowing localhost access an disabling it by default. The use case we want to support is plugins and CORS is not relevant for that (as they are hosted by ES). Plugin developers on the other hand need to know about this early as it may impact the choice of deployment (as @rashidkpc said)