Do not keep all eggs in one basket. A common fault that I have seen from working in this industry for companies of various sizes is that many of them (not all) have a single point of entry.
What I mean by this is if you have one place that stores critical business logic for multiple parts of your application, or even for multiple organizations, a hacker only needs to get access to one account in order to take down your entire business.
Private GitHub repositories are not safe. Keeping variables in plain text on your web host is also not safe. Password managers such as 1Password, NordPass, Lastpass, they are a good place to start, but also they are not safe if used incorrectly. Use 2FA, secure password, and use encryption for all production variables if possible.
In 2023 there is no excuse to using plain http for anything public. HTTPS encrypts any web traffic. This makes it near impossible for any middleman (hacker) to snoop. Any data that is transferred with plain HTTP can, and therefor you should assume will be used maliciously. There are many good articles on this topic, so I will not go into detail. What is HTTPS?
This might seem contradicting since this website is open source, and I am openly documenting the development process and the tech that was used. I am not claiming this is the most secure website. Open source is always a trade-off. Any mistakes I make are public for anyone to use. I do expose myself to an unnecessary security risk this way. That said, for my personal project this is worth it as I want to share.
I would never publish details about a specific customer of mine. Knowing what the code looks like, or even which services or tech is used is a point of entry for hackers. Make it as difficult as possible to find an access point.
Separate your layers of logic. Split your application into multiple parts, and obfuscate the platform you are using whenever possible. This is easiest with headless solutions, and self host all API endpoints, even if they directly communicate with a separate service and could be handled directly from your front-end.
The front-end for this website is open source, this does add its own challenges in terms of security. That said, none of my environment variables are included in the code, they never have been and never will be. I keep a separate .example.env with the required variables, but the actual variables are kept private.
The website is hosted on Cloudflare with 2FA and a secure password. Even in Cloudflare dashboard none of my variables are visible. All environment variables are encrypted. Automatic HTTPS redirects are set up so that any http traffic is automatically redirected.
I do not keep multiple business critical parts in one location.
If my GitHub got hacked, some private code would be exposed, but nothing related to this site, and no production variables are saved there.
If someone got access to my Cloudflare they could cause harm, but nothing that I cannot recover. I do not store anything private on Cloudflare.
My domain is purchased and maintained at Oderland, so if my hosting gets compromised I would change where it points to. My domain registrar only handles my domains, nothing else.