Store two URLs on monitor (one public, one internal) #2937

New issue

Closed

opened 2026-02-28 03:12:11 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-28 03:12:11 -05:00

Owner

Originally created by @sevmonster on GitHub (Dec 19, 2023).

⚠️ Please verify that this feature request has NOT been suggested before.

I checked and didn't find similar feature request

🏷️ 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 the action 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.

Originally created by @sevmonster on GitHub (Dec 19, 2023). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ 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 the `action` 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.

deekerman

2026-02-28 03:12:11 -05:00

closed this issue
added the
feature-request

A:status-page
labels

deekerman commented

2026-02-28 03:12:16 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 19, 2023):

I am not sure how this is separate to https://github.com/louislam/uptime-kuma/issues/3991

Currently the push url is bound to the primary base url of the instance. Said issue asks if it is possible to change this for push monitors.

Closing as a duplicate of #2507

@CommanderStorm commented on GitHub (Dec 19, 2023): > I am not sure how this is separate to https://github.com/louislam/uptime-kuma/issues/3991 Currently the push url is bound to the primary base url of the instance. Said issue asks if it is possible to change this for push monitors. Related https://github.com/louislam/uptime-kuma/issues/927 Closing as a duplicate of #2507

deekerman commented

2026-02-28 03:12:17 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 19, 2023):

This makes it difficult to use/recommend Uptime Kuma for public-facing service.

Here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

@CommanderStorm commented on GitHub (Dec 19, 2023): > This makes it difficult to use/recommend Uptime Kuma for public-facing service. Here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md