Store two URLs on monitor (one public, one internal) #4254
Labels
area:status-page
Everything related to the status page
feature-request
Request for new features to be added
🏷️ Feature Request Type
UI Feature, Other
🔖 Feature description
On HTTP, push, and any other monitor with a URL field—or on monitors that have previously had a URL field set and have had their type changed, so that the
url
field is set in the database—that URL (which may be internal) is used in a number of places, including status pages, Discord alerts, and as theaction
for Ntfy notifications.In the case of status pages, you can elect to show or hide the URL. But for notifications and Discord, you cannot hide the URL; it will always be shown to the end user. There may be other places this can happen other than what I have listed.
The problem is that unless you protect your notification/integration endpoints so that only authorized users may utilize them, this can expose internal-only URLs to external users. And I imagine it would be common to use special URLs for Uptime Kuma, that bypass WAFs, authentication, or otherwise, so that they do not get in the way of monitoring the service.
If there is not a proxy sitting in front of the URL given to Uptime Kuma that can protect against external users accessing it, and if there is no network firewall that blocks sources other than Uptime Kuma and the frontend web proxy, then anyone could grab these URLs and access the underlying service, potentially without the usual protections for the public URL.
✔️ Solution
Add a public-facing URL field in addition to the existing internal URL field. This field could also point to documentation for monitors that don't have a web interface. In all cases where the internal URL field is used, the public one is shown instead. Database migrations for this change could copy over the internal URL to a new public URL column for forward-compatibility.
❓ Alternatives
Always make sure any URLs you put into Uptime Kuma are protected by a reverse proxy with basic auth/bearer tokens enabled.
📝 Additional Context
I am not sure how this is separate to #3991. It seems to me that we are talking about the same things, just in different ways.
#1793 is also relevant: It shows that a lot of potentially sensitive information is leaked out of Uptime Kuma, to anyone that is given access to notifications or potentially the status pages. This makes it difficult to use/recommend Uptime Kuma for public-facing service.
The text was updated successfully, but these errors were encountered: