Website Security Essentials for Every Site Owner

Good website security doesn't start with complex tools. It starts with basic habits: keeping software updated, strong passwords with two-factor authentication, limited permissions, an encrypted connection, backups you've actually restored, and careful handling of everything visitors send you. Many attacks on business websites aren't aimed at you personally; they're automated programs scanning large numbers of sites for an outdated plugin or a weak password. This article sets out principles and good practice for site owners and their teams. It's general guidance, not legal advice.

How websites usually get hacked

Knowing the usual entry points tells you where to put your effort. The most common ones:

• Outdated software: the CMS, theme, plugins or server language version, when they contain published vulnerabilities that attackers know about and scan for automatically.
• Weak or reused passwords: if a team member's password leaks from another service, bots try it on your admin panel and email, a technique called credential stuffing.
• Phishing: a message that looks like it's from your host or domain registrar asking you to "confirm your account" through a fake link.
• Insecure code: especially in custom builds, such as SQL injection, cross-site scripting (XSS) and unrestricted file uploads.
• Misconfiguration: backup or configuration files left in a public folder, exposed admin pages, or error messages that reveal internal details.
• Third parties: a script or plugin from a supplier who has been compromised themselves.

What an attacker wants is usually not your site as such but its resources: publishing spam pages that exploit your domain's search reputation, redirecting your visitors to scams, sending spam from your server, stealing customer data, or defacing your pages.

Updates: the simplest and most neglected defense

• Update the core platform, themes, plugins and server software regularly, and apply urgent security patches as soon as they're released.
• Delete unused plugins and themes. A deactivated plugin whose files are still on the server can remain an open door.
• Choose components that are actively maintained, and never use pirated copies of paid themes or plugins, which are a common way of planting backdoors.
• Take a backup before any major update, and try the update on a staging site where possible.
• Follow the security advisories for your platform and its main plugins.

If your site runs on a hosted platform, the platform updates the core for you, but your team's accounts and any apps you add remain your responsibility. The guide to content management systems explains what you carry with each option.

Passwords and two-factor authentication

• Use long, unique passphrases for every account, and give the whole team a password manager.
• Turn on two-factor authentication (2FA) for your domain registrar, hosting, admin panel, company email, and analytics and ad accounts. Start with email, because password reset links for every other account land there.
• Prefer authenticator apps or physical security keys over text messages where they're available.
• Limit repeated login attempts, and avoid predictable usernames such as admin.
• Never share one account between several people. Everyone gets their own, so you know who did what and can remove one person's access without locking out everyone.
• Don't send passwords in plain text over WhatsApp or email; use your password manager's sharing feature.

The principle of least privilege

Least privilege means every person and every system gets only the access it needs for its job, and only for as long as it needs it:

• A content writer needs an editor or author role, not full administrator rights.
• An agency or freelancer gets a separate account that is removed when the project ends, not the administrator password.
• When an employee leaves, their accounts are disabled the same day, and any shared passwords they knew are changed.
• The database user your site connects with has only the permissions the site needs.
• API keys are narrowly scoped, rotated periodically, and never written into published code or a public repository.

Keep a simple account register: the account, its owner, who has access, whether 2FA is on, and the date of the last review. Go through it every quarter. And make sure the domain and hosting are registered in the company's name and accounts, not in someone's personal account.

HTTPS and SSL certificates

HTTPS encrypts data between the visitor's browser and your server, so nobody on the same network can read what's sent through forms or login pages, and browsers warn visitors about unencrypted pages. Many hosts provide certificates free with automatic renewal; make sure renewal is actually working, because an expired certificate shows your visitors an alarming warning. Redirect all HTTP addresses to HTTPS and fix mixed content, meaning images or scripts still loaded over HTTP. The details are in choosing hosting, a domain and an SSL certificate.

Backups, and testing the restore

A backup is your rescue plan when every other defense fails, but it only helps if it is complete, recent, stored away from the server and genuinely restorable:

• The 3-2-1 rule: three copies of your data, on two different types of storage, with at least one off-site.
• What to include: files, database and configuration together. Files without the database won't bring a site back.
• How often: in line with how often things change; daily for sites that receive orders or content constantly, weekly for mostly static sites.
• Retention: keep older copies for several weeks, because a breach may be discovered late, by which time recent backups are infected too.
• Where: away from the server and its account. If the server is compromised or the account is closed, backups stored on it are gone.
• Restore: restore a full copy to a staging site every quarter, and document the steps and the time it took.

Remember that your host's backups are a bonus, not a plan. Know their terms and retention period, and keep your own copies.

Input validation and secure code

This section applies to custom-built sites, and it's what to ask your developer about if you don't code yourself. The first rule: trust no input, whether it comes from forms, URL parameters, cookies, uploaded files or other systems.

• Validate on the server: type, length, format and allowed values. Browser-side validation improves the experience but doesn't protect you, as HTML, CSS and JavaScript basics explains.
• Prepared statements: keep data separate from the database command, which prevents SQL injection.
• Output encoding: any user-supplied data displayed on a page must be encoded to prevent script injection. Modern template engines do this by default, so don't switch it off.
• CSRF tokens on forms that change data.
• File uploads: allow specific types, check the content and not just the extension, limit the size, rename files, and store them where they can't be executed.
• User passwords are stored using a hashing algorithm designed for the job, such as bcrypt or Argon2, never in plain text or with old, fast algorithms.
• Error messages: generic for visitors, with the details in logs only the team can see.
• Spam protection: rate limits, a hidden honeypot field that catches bots, and a human verification tool if needed.

Here's a PHP example showing the difference between a dangerous query and a safe one:

// Unsafe: user input is glued into the query
$sql = "SELECT id, name FROM clients WHERE email = '" . $_POST['email'] . "'";

// Safe: a prepared statement keeps data separate from the query
$stmt = $pdo->prepare('SELECT id, name FROM clients WHERE email = ?');
$stmt->execute([$_POST['email']]);
$client = $stmt->fetch();

In the first case an attacker can type text into the email field that changes the meaning of the query itself. In the second, the query is sent first and the data passed separately, so it's always treated as data, never as commands.

The OWASP Top 10

OWASP is an open, non-profit community that publishes free web application security resources. Its best-known output is the OWASP Top 10, an awareness document listing the most critical categories of web application security risk, updated every few years. Categories that recur across editions include broken access control (for example, a customer changes the order number in a URL and sees someone else's order), injection, security misconfiguration, vulnerable or outdated components, authentication failures and cryptographic failures.

You don't need to memorize the list, but it's a useful shared language with developers. Ask whoever builds your site how their code handles the OWASP Top 10 risks, and check the current edition when you commission a large custom project.

Security headers

Security headers are instructions your server sends with each page telling the browser to switch on extra protections. The most important:

• Strict-Transport-Security: makes the browser always use HTTPS for your domain. Enable it only once every subdomain works over HTTPS, because the browser will refuse anything else for the set period.
• Content-Security-Policy: defines where scripts, styles and images may be loaded from, a strong defense against script injection. It needs careful tuning, so start in report-only mode before enforcing it.
• X-Content-Type-Options: stops the browser from guessing a file's type differently from what the server declared.
• X-Frame-Options, or the frame-ancestors directive in the content policy: prevents your site from being embedded in a frame on another site to trick visitors into clicking.
• Referrer-Policy: controls how much of the URL is passed to other sites when a visitor follows a link.
• Permissions-Policy: switches off browser features your site doesn't need, such as the camera, microphone and location.

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

These are common starting values, not a ready-made recipe for every site. Free online scanners will show which headers your site sends and which are missing.

Monitoring and early warning

• Uptime monitoring, so you know immediately if the site goes down.
• Alerts when a new administrator account is created or someone logs in from an unusual location.
• Regular file scans for changes or malicious code, from your host or a reputable security tool.
• A web application firewall (WAF), offered by many hosts and CDNs, which blocks known attack patterns before they reach your site.
• The Security Issues report in Google Search Console, which alerts you if Google detects hacked content or malware on your site.
• Server logs kept for long enough, since they're the first thing you'll need to understand any incident.

What to do if your site is hacked

1. Don't rush to delete things: record what you see with screenshots and times, and copy the files, database and logs before cleaning up. They're your evidence of what happened.
2. Contain the damage: put the site into maintenance mode or take it offline if it's spreading malware or stealing data, and tell your host.
3. Change every password from a clean device: hosting, admin panel, database, email and domain registrar. End open sessions, revoke API keys, and look for administrator accounts you don't recognize.
4. Find the entry point: an outdated plugin? A stolen password? An uploaded file? Unless you close it, the attacker will come back.
5. Clean or restore: restore a clean backup from before the breach, then update everything and close the hole before going live again, or bring in a clean-up specialist. Check for backdoors left behind.
6. Repair your reputation: if Google flagged a security issue, request a review after cleaning up; if spam was sent from your server, check the email blocklists.
7. Personal data: if customer data may have been exposed, data protection rules in your country or your customers' countries may require you to notify an authority or the people affected within a set time. Speak to a legal adviser early.
8. Review what happened: write down what occurred, how it was fixed and what you'll change, so it doesn't happen again.

Practical checklist

Monthly:

• Apply platform, theme and plugin updates.
• Confirm backups are running and the latest one completed.
• Review users with high-level permissions.
• Check Search Console reports and monitoring alerts.

Quarterly:

• Test a full restore on a staging site.
• Review the account register and remove anyone who has left.
• Review plugins and third-party scripts, and remove what isn't needed.
• Check your security headers and the certificate's expiry date.

If your site is a store handling customer data and payments, continue with online store security and customer data protection. To see where security fits in building and maintaining a site, go back to building your business website.