Security - how to avoid exposing app search keys (searchKey,host identifier,engineName) in search ui

I'm using app search with search ui GitHub - elastic/search-ui: Search UI. Libraries for the fast development of modern, engaging search experiences.

Everything looks great about search ui except security. All keys Credentials (searchKey,host identifier,engineName) are visible in api call.

I thought to move Connectors key logic to backend.

So the flow will be like 1.search ui call backend api. 2 backend will call app search-api and return response as it is to show result on ui.
is the right way to go?

I haven’t found any way to give own api call from search-ui.

How can I do this?

Hey @Swapnil_Ghorpade. We consider it safe to expose Public Search Keys. They have limited, read-only access. Did you have a specific concern around that?

There are instructions and an example for using Search UI with other back ends here: https://github.com/elastic/search-ui/blob/master/ADVANCED.md#implementing-handlers-without-a-connector.

@JasonStoltz yeah documents are private thats why...
If anyone get these keys then he can easily access documents without logging which I don't want.

Could you please suggest any better way to handle this?

PFA : search-ui default demo-examples

@Swapnil_Ghorpade You could set up a thin proxy to our API that handles authentication and injects the correct authentication token, and then point Search UI at your proxy server. There is an endpointBase configuration option that lets configure the URL where the App Search API is located.

hey @JasonStoltz I didn’t get that.
could you please elaborate a bit , how to use this ?

If you need to protect search and put it behind a login, then you'll need to make the API requests to App Search server-side. One way to do that, would be to create your own search endpoint that just proxies our App Search API.

Browser -> Your Server -> App Search API

Your server could just pass through App Search API requests through to the App Search API. Your server though, would be responsible for authentication. Additionally, your server would append the correct API Key to the request before forwarding the request, so that it is never exposed in the browser.

Does that make sense?

@JasonStoltz thanks for the responding.
yes..it's look like this will work.

hey thank you @JasonStoltz I have a question,

I think it will add unnecessary load on own server to just forward request to app-search on every time users do search?

is there any other way to handle this case?

1 Like

@Swapnil_Ghorpade If your documents are private, then I think you must make these calls on the server side, behind your authentication. I don't think there's any way around that.

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.