# Hitting Security API Endpoint **URL:** \ **Category:** Kibana\ **Tags:** elastic-stack-security\ **Created:** [July 21, 2020, 1:31am UTC](https://discuss.elastic.co/t/hitting-security-api-endpoint/241952 "2020-07-21T01:31:18Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![tylersmalley](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tylersmalley/32/8833_2.png) [@tylersmalley](https://discuss.elastic.co/u/tylersmalley)\ **Post date:** [August 12, 2020, 7:24pm UTC](https://discuss.elastic.co/t/hitting-security-api-endpoint/241952/6 "2020-08-12T19:24:26Z")
I am not sure how else you could accomplish this other than using a proxy at this time until we have [anonymous access](https://github.com/elastic/kibana/issues/18331). > [@Auto-authenticating to iframe-embedded Kibana dashboard](https://discuss.elastic.co/t/auto-authenticating-to-iframe-embedded-kibana-dashboard/46091/4): > > You can pass the Authorization header as Joe suggests using an nginx proxy. Here is the relevant section of my nginx.conf: server { listen 4443 ssl; # the default was port 443 server\_name tim-virtual-machine.local; ssl\_certificate /home/tim/domain.crt; ssl\_certificate\_key /home/tim/domain.key; ssl\_session\_cache shared:SSL:1m; ssl\_session\_timeout 5m; ssl\_ciphers HIGH:!aNULL:!MD5; ssl\_prefer\_server\_ciphers on; location / { … You mentioned that is not possible in this scenario. Why is that? You should be able to inject a different authorization header based on the path or some factor to account for these different instances. --- _[View the full topic](https://discuss.elastic.co/t/hitting-security-api-endpoint/241952)._