coralproject / talk

A better commenting experience from Vox Media
https://coralproject.net
Other
1.88k stars 355 forks source link

Put admin dashboard and used graphql queries/mutations on separate domain/path #4563

Closed ideallical closed 6 months ago

ideallical commented 6 months ago

Currently both the client code as the backend code is hosted on the same domain. E.g. talk.example.com However, it would be nice to be able to put the admin part behind VPN, e.g talk-admin.example.com This is of course possible with some routing tricks, however, the admin still uses the same graphQL endpoints as the public client which have to stay public, so the admin would still not be fully behind VPN.

I'd like to increase security, by being able to host the admin part of coral talk and it's queries/mutations separately from the client part.

Search Terms

admin, cms, security, route, routing, domain, subdomain, vpn, internal network

Suggestion

Make it easy by given separating the graphql into 2 parts, one for the admin and one (slimmed down one) for the public. You can still use both on one domain, but if preferred you now have the choice to host the admin part more secure behind VPN/whitelisted ips.

Use Cases

To only allow access to the admin of talk if you're on an internal network of a company.

Now that I finished writing this, its probably still security through obscurity, as yes, you won't able to access the admin without vpn, but there are still endpoints public that have write access.

What are your thoughts on this?

nick-funk commented 6 months ago

Putting the admin UI behind a VPN will unfortunately not add any security to your setup.

Both the admin and client speak to the graphql API which must remain public. Even if the Admin UI is hidden behind a VPN, all of the admin API functions in graphql would still be public as the API must remain public for the stream to function. As well, the stream has moderation actions that can be performed while a mod/admin is logged in stream side, so the public stream, has to have API access to moderation abilities, which again, must be public.

The most common attack vector for Coral is not the admin UI, but the API itself. We would have to refactor the entire Coral monolith into two separate graphql API endpoints to truly create the security blanket you are wanting. That would take an incredible amount of work, and it is far easier for us to just have a public graphql API and perform thorough pen tests (which we do regularly) to ensure that none of Coral is vulnerable to attack instead of trying to rely on a VPN to protect the data.

I hope that answers why Coral is architected the way it is and why we can't put the admin behind a VPN.