Should Elasticsearch Query DSL Be Constructed on the Frontend?

Elastic Stack Elasticsearch
1

Hi everyone,

I'm developing a frontend UI for an application that uses Elasticsearch as its search engine. We're currently designing the API contracts with our backend team, and one of the key topics we're debating is where to build the Elasticsearch queries.

Our frontend includes advanced search filters that can become quite complex (e.g., boolean combinations, ranges, nested fields). One approach we’ve considered is to generate the full Elasticsearch Query DSL on the frontend and send it to the backend, which would then forward it directly to Elasticsearch.

However, we’re concerned about:

  • Security: Could this expose sensitive fields or allow query manipulation?
  • Coupling: Does embedding ES DSL in the frontend tightly couple it to backend internals and make it harder to refactor later?
  • Validation: How do we ensure only allowed fields and query types are used?
  • Flexibility: Would we lose the ability to optimize or evolve search behavior if logic lives entirely in the frontend?

The alternative is to send a simplified, domain-specific filter object from the frontend (e.g. search text, filters, sort options), and let the backend build and validate the actual ES query.

My questions:

  • Is it ever a good practice to send full ES queries from the frontend?
  • What are the recommended ways to expose flexible search UIs to users while maintaining security and backend control?
  • Are there known patterns that help in this situation?

I’d appreciate any insight or experience you can share — especially if you’ve faced similar decisions in production systems.

Thanks! :folded_hands:

2

What does "front end" mean to you?

If you mean inside the browser, then the security issue is one that you need to be careful with. It's not impossible, but you need to make sure that what the backend accepts is "safe".
Since I don't know your data or your security requirements, I can't really advise on how hard that is for you.

If your backend accepts unvalidated http requests from the browser, then your users can intercept those and change them in any way they like. In which case you need to be worried about a bunch of things such as:

  • someone removing filters
  • addition of lookup queries
  • addition of expensive queries (denial of service)
  • using multiple (repeated) queries that narrow search terms in order to determine whether particular documents exist

Generally speaking, I would not accept Query DSL from a low-trust client. In some cases, with some work, you can make it safe enough. But in other cases you can't.

2 Likes
3

Thank you for your reply.
Yes, I mean inside the browser when I refer to the frontend. I am aware of its security issues. So, is there any alternative for such complicated cases? Is there any "language" for communicating between the frontend and backend for complex queries? I have a strong sense that there is a pattern or language somewhere that I would not need to reinvent the wheel.