We have an app which runs off of a private API. We have a server which hosts the API, as well as an admin panel where staff can log in and make changes to the app's content. The API and admin panel run on the same web domain. Let's pretend the domain is
appname.com and the URLs are
Originally, there were no public web pages on the server or domain. However, we added a password reset page at
appname.com/resetpassword so that app users who have forgotten their password can request a password reset email.
Immediately after we added the password reset page, the project head (who is not a technical person) became concerned that putting the password reset page on the same domain as the API and admin site could expose the server to hackers, who might not otherwise be aware of the domain since it has no other public pages. They asked that we put the password reset page on a different domain so that hackers wouldn't know how to find the primary domain.
This logic doesn't make sense to me, for several reasons:
- I've never seen anyone else do something similar to this, although it's hard to think of direct parallels
- The domain name of the backend isn't hard to guess even when there aren't any public pages on the site
- If we add a public web site in the future, it would logically be located at the same domain, at which point the domain would no longer be a secret anyway
- Any hacker sophisticated enough to break through the security measures on the server could easily find the API URL, and thus the site domain, by following packets sent from the app.
However, the project head is adamant that the password reset page cannot be on the primary domain. What strikes me as the easiest solution is to set up a domain alias, something like
appname-passwordreset.com, which points directly and exclusively to the password reset page. However, will this buy us anything?
appname-passwordreset.com would have the same IP address. Would using the latter alias realistically prevent a hacker from finding or breaking into the server?
Note: I realize that an alternative is to only let the user request a password reset email from within the app. However, the password reset email has to have a link to a webpage, thus taking us back to the original problem