If I have an app that is facing the web on port 443, what can I do to harden my app and server?
Is it possible for an attacker to access unauthorized pages by knowing the name of them?
What strategy do you use?
First page should be a login page and it doesn’t go anywhere if the login is wrong. Do NOT use a simple password lookup - use salted encryption to get the password hash and you compare the calculated hash of the login against the hash created when creating the user record. To make it a little harder I use a different salt for each user record so someone cracking one login doesn’t help them with anything else.
After that you control pretty much all aspects of the Xojo web app. If you can deal with named pages using HandleURL then you’ll have to check for proper login on each page. Otherwise you can control access to every page.
FWIW an old security-firm client really liked Xojo web apps because they are really secure. They have a 20-step test and their tests crash Xojo web apps at step 8. Most websites leaked information at step 3 so it was really good. And this was 5 or 6 years ago and I know some steps were taken to make it even more secure.
I think you need to play around with Xojo a bit more to see how it works in the browser and see if you can go to named pages by knowing the name.
Thanks Bob, this is great advice!
Unlike Bob’s experiences I have quite bad experience with Xojo CGIs and Standalone Apps. Without another Webserver as Reverse Proxy before, I would not recommend to let run Xojo Apps in the web. My suggestion based on own experiences is an hardend Debian with Apache in minimal configuration. TLS 1.2/1.3 + correct chipers, HSTS and CSP are mandantory.
Credentials in the web should be always secured with 2FA. In fact I do not use any Webservice without RFC 6238 support (TOTP) - Xojo Customer Login is the last one without…
Some Checking Tools:
https://observatory.mozilla.org/
https://www.ssllabs.com/ssltest/
https://webbkoll.dataskydd.net/
You may run these tools against your web. As reference you may take my Website (not a xojo web, just plain html site). I am proud for my A+ ratings 
One of the easiest ways to protect a cgi yet robust, is to use the good old directory protection offered by Apache.
The main problem with Xojo web apps is the ease with which a tiny DOS attack can knock them down (or slow them down significantly), because each connection to the web app’s home page generates a complete server-side session creation (before the user identifies himself), even if it is a bot.
To avoid this, it is necessary to make a login page separate from the web app. It is a simple HTML/javascript page sent by Apache for example. Opening this page does not open the xojo web app on the server side.
If there are many connections/attacks on this login page, it will be more resistant, because Apache can manage many more connections than the Web App and it is a simple web page that is sent, there is not need to consume many resources to open the compiled web app, make it work to create a session, send to the client all the Xojo framework and all your HTML/CSS/Javascript code generated by Xojo.
It is only when the user fills in his login credentials (with possible basic controls, captcha, etc.) and valid, that they are sent to the Xojo Web App (via handleSpecialURL). If the credentials are ok, the Xojo web app is then open, so only then. That’s how it should work. If someone sells a code of this type, I think there would be buyers.
Translated with www.DeepL.com/Translator
I too would pay for something like this.
How would you block a direct connection to a cgi or standalone app until the auth part has been processed?
I am not sure if it has something to do with the general question of harding Xojo Apps. As written, the best place of any Xojo App is behind a reverse proxy. Your question dives deeper and in fact you’re asking how to prevent DOS and how to do Authentification.