Website security basics: HTTPS, headers and access

Website security is not a feature you switch on once: it is a set of habits and settings. Most incidents on small sites do not come from sophisticated attacks, but from weak passwords, outdated software or access that nobody reviewed. Reducing those risks is cheap compared with recovering from a compromised site.

This technical guide goes over the essentials: HTTPS encryption, security headers, access, updates, forms and backups. It is not a full audit, but it covers the basics that every site should have.

Website security: HTTPS everywhere

HTTPS encrypts the communication between the browser and your server and verifies that the site is who it says it is. Today it is the foundation and a requirement for almost everything else.

• Valid certificate with automatic renewal. An expired certificate shows warnings that scare visitors away.
• Redirect all HTTP to HTTPS, with a permanent redirect (301).
• Avoid mixed content: HTTPS pages that load images or scripts over HTTP.
• HSTS: the Strict-Transport-Security header tells the browser to always use HTTPS with your domain. Turn it on when you are sure everything works over HTTPS; MDN documents it.

Security headers

They are instructions that your server sends along with every page and that harden the browser's behavior. A reasonable basic set:

The most powerful and the most delicate one is Content-Security-Policy: a policy that is too strict can break legitimate scripts. Implement it gradually and test carefully. The full reference is in MDN on CSP.

Access and passwords

Most problems start with a compromised credential:

• Long, unique passwords for each service (hosting, domain, website panel, email). Use a password manager.
• Two-step verification on everything that offers it, especially domain, hosting and email.
• Principle of least privilege: each person gets the access they need and no more. Remove access for whoever no longer works with you.
• Change default credentials and do not share accounts between several people.
• Review periodically who has access to what.

Updates

Software that is not updated is the most common way in. This includes the server system, the content management system if you use one, plugins, your project's libraries and dependencies.

• Update regularly and prioritize security patches.
• Remove what you do not use: forgotten plugins, themes, accounts and services are attack surface.
• Test before publishing big updates, so you do not break the site.
• In projects with dependencies, tools such as the package manager's vulnerability alerts help detect known problems.

Forms and user data

• Validate data on the server, not only in the browser.
• Protect yourself from spam with submission limits and anti-bot controls.
• Store the minimum necessary and protect what you store. If you collect personal data, state it in your privacy policy and comply with the rules that apply.
• Never store passwords in plain text. If your site has user accounts, use a proven authentication system.

Backups

A backup is what saves you when everything else fails.

• The 3-2-1 rule: three copies, on two different types of media, one of them away from the main location.
• Automate them and define how often: it depends on how frequently your site changes.
• Test restoring. A backup that has never been tested is a hope, not a backup.
• Keep the copies with restricted access: they contain everything.

Monitoring

• Downtime alerts so that you find out before your customers do.
• Certificate alerts for expiry.
• Review the logs for odd behavior, such as many failed login attempts.
• Search Console warns you if Google detects security problems on your site; connect it by following the guide on Google Search Console.

References

For a general view of the most common risks in web applications, the OWASP Top 10 list is the most widely used reference. And for the technical documentation of browser headers and mechanisms, the web security section of MDN.

Minimum checklist

• HTTPS with redirect and a certificate that renews itself.
• Basic security headers on.
• Unique passwords and two-step verification.
• Updates up to date and no plugins or accounts that are not used.
• Automatic, tested backups.
• Downtime alerts and certificate expiry alerts.

Frequently asked questions

Is my site too small to be a target?

No. Attacks are usually automated and look for any site with a known weakness, regardless of its size.

Does good hosting solve everything?

It helps a lot with the infrastructure, but it does not replace strong passwords, updates or backups, which depend on you and on whoever manages your site.

What do I do if I suspect my site has been compromised?

Change the passwords from a trusted device, tell your provider and do not delete anything before understanding what happened. Restoring from a clean backup is usually the safest option.

What to do next

If you would like us to review the security of your site or set up periodic maintenance, take a look at monthly maintenance or get in touch. And for email security, the guide on SPF, DKIM and DMARC.