Securing Dashboard Apps?

[nickmonad]

We started to use the dashboard app functionality to integrate with other tooling APIs we use for customer orders, shipping information, etc.

Everything works great, but we have a bit of a concern security wise. We would ideally like to keep our hosted dashboard app accessible by support agents and other employees only, by making the domain accessible via a private network, the same where our self-hosted chatwoot instance is hosted. (For example, the kubernetes cluster DNS)

Unfortunately, chatwoot seems to use an embedded iframe element to render the dashboard app, which forces the browser to make the request to the app, instead of the chatwoot server instance itself. This means the support agents must either be on the same VPN as the chatwoot server instance, or we have to make the dashboard app publicly available in our DNS records. This isn't really an option for us, as we have an endpoint in that dashboard app that allows searching for customer orders via email, and we don't want that discovered and abused in the wild.

How are people thinking about security for dashboard apps? If the customer information is provided to the dashboard app from chatwoot, it must be doing some kind of API request(s) against backing customer data stores, which means that either:

1. no security - dashboard apps are public and the endpoints used to search for data based on context provided by chatwoot is completely in the clear

Or,

2. dashboard apps should have their own authentication and force support agents to login (kind of a pain, as it means we have to roll our own auth there)

I personally am not a huge fan of either of these approaches (1 is obvious why not).

This could be resolved if chatwoot itself made the HTTP request and just rendered out the dashboard app internally, or had a different model entirely that could support that, but that doesn't seem likely in the near future (unless the team is working on this issue already).

Any thoughts / suggestions? Thanks!

[pranavrajs]

@nickmonad Thanks for starting the discussion here.

Does the basic auth work here? You can embed the application with a basic auth so that even though it is available in the public network it would still ask for the user name and password, whereas on the dashboard app you can pass this in the URL params.

Let me know what you think.

[pranavrajs]

Missed this, yes this is the best option. We will consider adding headers in future iterations.

[nickmonad]

Thanks! I think having the option for the chatwoot server instance itself to make the HTTP request and render the HTML back out to the browser might be ultimately a more secure solution, since then the dashboard app just needs to be resolvable on the same internal network as the server. (Again, thinking about a kubernetes bases deployment where the dashboard app would just use cluster DNS)

If that's not feasible, or has it's own security risks involved I'm not aware of, perhaps the chatwoot server could make an API request to an internally resolvable service that returns JSON, and the dashboard app uses an HTML template (based on jinja or something similar) uploaded as part of the configuration step. Then the server just maps that JSON response into the template, to render back out to the user.

In any case, thanks for all the work on chatwoot!

[MichelN89]

Hi @nickmonad, I just came across this message and I'm trying to get my head around the same issue. Have you found a good solution yet?

[nickmonad]

The best we came up with was using long, random sub-paths that our chatwoot app server responds too, as well as a long, random "api key" passed via query parameters (you could argue only one of these is necessary, especially since we access the dashboard app over HTTPS and all paths and query parameters are encrypted over-the-wire, but we just haven't changed it since)

So for example,

https://our.chatwoot.app.com/abbe9e3287af9d6adbd74f51a83d4015ed92ec4aa6b20eff818b0ceabf6e6bdd?key=96a74df505dceeeeee7b392a0e265fd7

gets configured as the dashboard app URL in the chatwoot admin settings. https://our.chatwoot.app.com/ just returns a 404.

The server reads these values from our secrets management tool at runtime and configures them as part of the web framework routing. Rotate them as desired.

[nickmonad]

This also works for "sub-apps", if you only want to host a single dashboard app server, just do something like,

https://our.chatwoot.app/<random value>/app1/
https://our.chatwoot.app/<random value>/app2/