Allow url with embed=true and deny for other

I have setup website that uses embedded iframes embed=true in url by modifying kibana config file:


But nowI don't want any users to figure out that removing "embed=true" from the querystring will take them directly into the Kibana page with all the admin options enabled I want any requests that does not contain "embed=true" to be denied from the nginx proxy server or Kibana settings. I'm hoping this would be possible in NGINX configuration file. But I cannot figure out how. Because "embed=true" is part of querystring but not route. Or is this possible in Kibana settings somehow?

So for requests like below I want to return 403 Forbidden.



@sam12 exactly what you want isn't possible in Kibana. However, if you have X-pack with Security you should look into

Hi @Brandon_Kobel, thank you for your quick reply. Isnt it possible through nginx too? Because i am using nginx for proxy passing.


Using NGINX to enforce this type of security isn't recommended, and we make no guarantees that it will work. It's possible for the user to execute HTTP requests against the Kibana API and cause modifications if all you are doing is blocking requests that don't contain that querystring parameter.

Hi @Brandon_Kobel

Thank you for your recommendation. So right now i have blocked post request through nginx so even if user is able to see the admin menus by removing embed=true but they wont be able to edit or change the dashboard. But i want to just get rid of this loop hole to by making sure just url with embed= true are allowed. Now I am using proxy pass by rewriting url and passing on to kibana where in config file i have made changes to include embed=true now i am trying to figure out after doing an proxy pass how can i check if request made is having embed=true in url before loading the dashboard


@Sam12 using NGINX to enforce this type of security is incredibly brittle and will likely break between different versions of Kibana. I'm not sure how you're getting away with blocking all POST as we're using a POST for the _msearch call on the Dashboard.

With all this being said, feel free to proceed at your own risk, but I'd like to reiterate that this is not a supported approach.

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