- Transparency is a dependency of trust; if it's not transparent (e.g. open source), then it's not trustworthy, full stop

- Read the latest NIST guidelines on software security; whether or not you trust the U.S. government (you shouldn't), NIST still has very solid security advice, and a lot of the rest of the stuff in this list is derived from NIST guidelines

- Establish a mandatory security policy for your website/organization

- Make regular backups, and store them on a separate server; test your backups regularly (e.g. by restoring them to a staging/test server identical to production)

- Stream log entries (or routinely back up log files) to a separate server

- Don't use Windows

- Don't use (non-LTS) Ubuntu, Fedora, Arch, or any other Linux distro which prioritizes the "latest-and-greatest" features over stability; prefer more stable distros like (open)SUSE, RHEL/CentOS, Debian, or an LTS release of Ubuntu (though I'd personally wait a year or so after an LTS Ubuntu release or an openSUSE release to give Canonical/SUSE (respectively) time to shake out the inevitable bugs)

- Never install software unless it's absolutely necessary

- Never install software from untrusted sources

- Never allow the use of passwords for SSH logins; always use key-based authentication (or disable SSH entirely)

- Never try to roll your own authentication unless you really know what you're doing (or you really want to learn what it takes and have no interest in using it in production) and it's absolutely necessary; 99 times out of 100, there's a library for your language that already does it with a much more comprehensive threat model than the one you're envisioning (and in the remaining 1 in 100 cases, there are at least plenty of smaller libraries that handle individual components of an authentication system)

- If you do roll your own authentication, at least try to use something like OAuth via an existing identity provider so that you don't have to store credentials (and that so that you can lean on that provider's expertise)

- If you do roll your own authentication and your own credential storage, make sure all passwords are hashed (SHA2 at minimum) with per-password-unique salts

- If you do roll your own authentication, play it safe and force the use of HTTPS site-wide

- If you do roll your own authentication and your own credential storage, try to provide some kind of multi-factor authentication, preferably one compatible with Google Authenticator; no, security questions don't count

- If you do roll your own authentication and your own credential storage, allow and encourage users to use long passphrases

- If you do roll your own authentication and your own credential storage, don't force users to reset their passwords every $NUM days; only force a reset if there's reason to believe that the user's account is compromised

- If you do roll your own authentication and your own credential storage, don't require users to include certain character classes in their passwords

- Have it in writing that nobody working on behalf of your website will ever ask users for their passwords

- You can't have a data breach if you don't have any data; only store sensitive user data if you absolutely know for sure that you need it (hint: if it's for "analytics" or ads, then you don't need it)

- If you do need to store sensitive data, ensure that it is encrypted (most full-featured SQL databases support encryption at various levels of granularity; for NoSQL databases or non-full-featured SQL databases, you'll want to make sure data is only sent to the database in an encrypted state)

- If you do need to store sensitive data, play it safe and force the use of HTTPS site-wide

- Hell, might as well just force HTTPS no matter what; it ain't like TLS certs are expensive (thank you, Let's Encrypt!)

- Routinely audit things like GitHub/Bitbucket/GitLab/$SOURCE_CODE_HOSTING_SITE repositories, Slack channels, AWS/Heroku/$APPLICATION_HOSTING_PROVIDER accounts, etc. to ensure that only the people who should have access do have access

- Make sure all persons involved in developing and maintaining the site use long passphrases and multi-factor authentication wherever possible (most source code hosting sites and cloud providers offer 2FA, and quite a few - like AWS - can even enforce it on all your organization's accounts)