Elasticsearch-js: Details on lack of browser support?

[ablakey]

Hello:

I'm curious about the security concerns regarding Elasticsearch use in the browser. If I have an auth story (such as apikey or user/pass) then what additional security concerns are there? Hypothetically I could ask a user for credentials and then perform vanilla HTTP calls to the API with those. What additional security issues does including this client library expose?

The suggestion to write a proxy makes broad sense, but it's also a huge wrench to throw into various applications of Elasticsearch (eg. I don't have a managed server to build a proxy into, I have web applications hosted statically and an elastic.co account).

I'd love to understand this better and then supply a minor addition to the README to flesh out the Browser section if you'd permit that.

Thank you!

[delvedor]

Hello!
Having a secure connection established does not mean that you are safe from attacks.
Let's say that you have a robust way of getting the credentials, and anyone in the world (I assume it's a public website) can send requests directly to Elasticsearch. How can you be sure that they are not sending malicious requests, for example, dropping indices or using the admin APIs for causing any sort of problems?
You could create a user with very low permissions, but even if you have search only permissions, a user could craft a complex enough query to cause an overload of Elasticsearch, resulting in an unresponding server.
I think we can summarize all the reasons in one sentence: never trust user input.
If your Elasticsearch instance is exposed to the world, you have no way to validate the user input.
Would you ever expose MongoDB, MySQL, or PostgreSQL?

[ablakey]

Thanks for responding. Yes I see exactly what you're talking about now. So when the docs suggest a proxy, they're suggesting a layer that provides an opportunity to do things like input validation, throttling, and anything else you'd want when public users get to submit any kind of data (like this comment on GitHub).

Given that my use case includes a small subset of trusted users (company employees) I think I can weigh the risk that they'll go into the code, grab the ApiKey, and begin posting spam. But as a best practice, I can see the need for a proxy or some sort of "web server" equivalent.

I think my mental gap came from my lack of perspective that this connection to Elasticsearch is basically akin to the connection between a web server and a Postgres instance. You wouldn't in a million years write a web UI that connected directly to the Postgres instance.

[delvedor]

Given that my use case includes a small subset of trusted users (company employees) I think I can weigh the risk that they'll go into the code, grab the ApiKey, and begin posting spam.

You can, but we are not testing in any way the compatibility of this library with the browser environment, so I can't guarantee it will work.
Anyhow, I strongly recommend avoiding doing it even if it is an internal project, better safe than sorry™ :)

I'll send a pr to update the README to explain better why it is not recommended to connect to Elasticsearch from the browser, thank you for the issue!

[fabiocarneiro]

@delvedor I would like to ask the following to be considered:

• This library is being pointed out as a newer version of the elasticsearch.js. Unfortunately, this is not true, as it is only compatible with node.js. Perhaps renaming the old one to elasticsearch-browser and keeping the support alive would make more sense.
• On Elasticsearch library/language index page https://www.elastic.co/guide/en/elasticsearch/client/index.html says "Javascript" library but on the destination Node.js (which would be the correct term to describe this library)
• This library working on the browser doesn't mean anyone will expose their full Elasticsearch with all features to the outside world. Every day there are more robust solutions (Kubernetes, IaaS) that allow only some endpoints to be exposed to the outside world. Assuming that the only way to be safe would be to use this library and write a proxy service by hand does not make sense.
• The responsibility of protecting Elasticsearch does not belong to library authors. Informing the user with proper documentation is better than preventing the user to do something he wants, for reasons that he might understand better than the authors, and that is very hard to anticipate.