Grafana Reverse Auth Proxy has failed to load its application files


I am trying to show grafana dashboard or charts in my web application,

I read a lot of topics in Grafana community about this issue and nothing fixed my issue.

Below are my configurations and my full implementation.

I get 200 Ok response and I can see below info in the response.

Below is my nginx configuration

map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;

server {
    root /usr/share/nginx/html;
    index index.html index.htm;

    server_name  localhost;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-WEBAUTH-USER $remote_user;
        proxy_pass http://localhost:3000/;

     if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        # Custom headers and headers various browsers *should* be OK with but aren't
        add_header 'Access-Control-Allow-Headers' '*' always;
        # Tell client that this pre-flight info is valid for 20 days
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
     if ($request_method = 'POST') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' '*' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
     if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' '*' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
 location /api/live {
    rewrite  ^/(.*)  /$1 break;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header Host $http_host;
    proxy_pass http://localhost:3000/;

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/localhost/fullchain.pem; # managed by 
    ssl_certificate_key /etc/letsencrypt/live/localhost/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot



cookie_secure = true
cookie_samesite = none
allow_embedding = true

enabled = true

enabled = true
header_name = X-WEBAUTH-USER
header_property = username
auto_sign_up = true
sync_ttl = 60

my frontend html code (angular)

 <div [innerHTML]="grafanaData" >

service.ts file(angular)

 getGrfanaData(url:string) {
     return this.http.get(url, {
    headers: new HttpHeaders().set("X-WEBAUTH-USER", this.username)
     .set("Content-Type", "application/json"),responseType:'text'


Please don’t send me the generic links. please paste your answer below.

It works on my computer™:

Seriously, you are giving away your Grafana admin access, data, … :person_facepalming:.

I think you don’t understand security consequences. I was cautious and I didn’t publish any private details, but black hat guys won’t give you any chance.

:joy: you want to discuss security issues with someone you are engaging with in a forum? Though a very qualified person (=> @jangaraj) You are asking to be ransomed for sure.

Why this particular config is dangerous.

1.) auth.proxy config in the Grafana means that proxy must handle authentication/authorization - Grafana trusts blindly to the value, which is in the X-WEBAUTH-USER header
2.) nginx is not performing any authentication in this case or any checks

Attacker will set own custom header X-WEBAUTH-USER on their side. For example there are plugins for the browsers, where you can define custom header per domain - plugin will add configured header to all domain requests.

But which username should we use? There is default admin user with Admin role (it is configurable, but I guess 99.999% of Grafana instalations use this default admin username for admin user). So attacker will configure header X-WEBAUTH-USER:admin and load targeted Grafana instance in the browser - attacker will be admin user there instantly.

I know that “Holy Grail” of all SPA devs is to have seamless Grafana integration. But you need to keep security in the mind.

For the record: my recommendation GitHub - jangaraj/grafana-iframe