Website security basics: what to check before something goes wrong

Website security discussions tend to jump straight to sophisticated attacks, which is not where the risk is for most sites. The overwhelming majority of small and mid-sized site compromises come from two mundane causes: a dependency that was not updated, and a credential that ended up somewhere public.

So this is the boring list, which is the useful one.

HTTPS everywhere, and no mixed content

HTTPS on the homepage is not the same as HTTPS on the site. Mixed content, where a secure page pulls an image, script or stylesheet over plain HTTP, either gets blocked by the browser or triggers a security warning users definitely notice.

• Redirect all HTTP traffic to HTTPS at the server, not in JavaScript.
• Search your codebase for `http://` in asset URLs.
• Check third-party embeds, which are a common source of mixed content.
• Set HSTS once you are confident HTTPS works everywhere.

Security headers, which cost nothing

A handful of response headers meaningfully reduce your exposure and take minutes to add. They are skipped mostly because nobody checks for them.

Update your dependencies

This is the single highest-value security habit and the most commonly neglected. Known vulnerabilities in popular packages get published, then scanned for automatically at scale. You are not being targeted; you are being swept up.

Keep secrets out of the repository

API keys, database passwords and tokens committed to a repository are a persistent problem, and deleting them later does not help because git keeps history. Use environment variables and a secrets manager, and if something did get committed, rotate the key rather than just removing the line.

Worth restating a related point: Base64 encoding is not encryption. Encoding a secret does not protect it, since anyone can decode it instantly.

Password storage, if you handle accounts

Plain hashes are the wrong tool. MD5 and SHA-1 are broken, and even SHA-256 is unsuitable because it is fast, and fast is what an attacker wants when testing billions of guesses. Use bcrypt or Argon2, which are deliberately slow.

Access control and backups

Two things people postpone until they matter enormously. Remove accounts for people who have left. Use least privilege rather than giving everyone admin. And test that your backups actually restore, because an untested backup is a belief, not a backup.

Automating the check

Every item above can be verified by hand, and none of them will be verified by hand a second time. siteIQ includes security checks alongside its SEO, performance and accessibility auditing, which makes a monthly re-check realistic.

For the infrastructure side, secrets management, hardened deployments, CI/CD that does not leak credentials, CodeAiMan's cloud and DevOps practice covers it, and CodeAiMan builds these defaults into new projects rather than adding them after an incident.

Frequently asked questions

Referenced in this article