How to Secure Your Website From Hackers: 5 Best Practices for 2026

As the Founder and CEO at Acquaint Softtech, I want to describe what a real website compromise looks like, because it is nothing like the version in most security articles. Nobody was targeted. An automated scanner found an outdated plugin on a site that had not been updated in eleven months, installed a backdoor, and began serving spam pages to search engines. The owner found out six weeks later when a customer asked why Google was flagging their domain. There was no ransom note and no dramatic moment. Cleaning it up took longer than the original build had, and that pattern is why support and maintenance services exist at all.

That is the shape of the overwhelming majority of incidents: automated, opportunistic, discovered late. It matters because it tells you where to spend. You are not defending against a determined expert who has chosen you specifically. You are trying not to be the easiest site the scanner found that week, and the measures that achieve it are unglamorous, cheap and mostly things you can finish this month.

---

The article version of this article gave five practices: update your software, use a strong password, install an SSL certificate, prevent SQL injection and keep backups. Four of those are still correct and the SQL injection section was genuinely well written, so it is preserved and extended below.

The password advice, however, has been reversed by the people who wrote the original guidance, and repeating it now would make your site less safe rather than more. That correction leads the article, along with the control the original never mentioned and which prevents more compromises than everything else combined.

Rank Your Risks Before You Spend Anything

Security budgets get wasted on the wrong layer, so start by working out which of these describes you. The rows are ordered by how often we see each one cause a real incident.

Your situation	What is most likely to hurt you
Admin logins without MFA	Stolen or reused credentials
CMS or plugins months behind	Automated exploit of a known flaw
Nobody owns updates	Silent drift into vulnerability
Custom code, little review	Injection and logic flaws
Backups on the same server	Losing everything at once
Secrets committed to the repo	Keys leaking through code history
No logging or alerting	Discovering a breach weeks late
Already compromised	Ongoing access and data loss

The third row is the quiet one. Most compromised sites we are called into were not neglected deliberately; responsibility simply belonged to nobody in particular after a developer moved on or an agency engagement ended. Naming an owner costs nothing and prevents more than any tool you can buy.

The Advice That Changed Since 2018

Three pieces of standard 2018 security advice are now considered outdated, and one is actively counterproductive. Here is what changed and why. 

2018 advice	Status in 2026	What to do instead
Change passwords regularly	Reversed by NIST	Change only on evidence of compromise
Require symbols and mixed case	Deprecated	Priorities length and a breach check
Buy an SSL certificate	Outdated	Use free, auto-renewing certificates
Update your software	Still correct	Automate it, especially plugins
Prevent SQL injection	Still correct	Parameterize every query
Keep backups	Correct but incomplete	Test that you can restore them

Why forced password changes were dropped

The reasoning is behavioral rather than technical. When people are forced to change passwords on a schedule, they make small predictable modifications, exactly as the original article warned against while still recommending the practice. 

The NIST digital identity guidelines now advise against requiring periodic changes and against arbitrary composition rules, favoring longer passphrases checked against lists of known-breached credentials. Change a password when you have reason to believe it has been exposed.

Turn On Multi-Factor Authentication

This is the single highest-impact control available and it was missing from the original article entirely. A password alone can be stolen, phished, reused from another breach or guessed. A second factor makes all of those insufficient on their own.

Where to apply it, in order

Your domain registrar first, because losing the domain loses everything downstream. Then your hosting and DNS control panel, your CMS administrator accounts, your email, your code repository and your payment provider. Registrar and DNS are the two people forget, and they are the two where an attacker gains the most leverage in the shortest time.

Which second factor to choose

An authenticator application is the sensible default for most teams. Hardware security keys are stronger and resist phishing outright, which makes them worth the cost for administrators of anything handling payments or personal data. SMS codes are the weakest option because of number-porting attacks, but SMS is still enormously better than nothing, so do not let the search for the ideal factor delay switching something on this afternoon.

Alongside this, use a password manager so every service gets a long unique password nobody has to remember. Reused credentials are the mechanism behind a large share of account compromises, and a manager removes the incentive to reuse without requiring anyone to change how they work.

Patch Fast, Especially Plugins

The original was right that updating is the foundation, and the detail worth adding is where the risk actually concentrates. On CMS-based sites the platform core is usually well maintained; the extensions are not.

The plugin problem

Every plugin is code from a third party running with full access to your site, and the majority of disclosed vulnerabilities in the WordPress ecosystem originate in plugins rather than in WordPress itself. The practical controls are simple: install fewer plugins, prefer ones with recent commits and multiple maintainers, remove anything deactivated rather than leaving it in place, and check quarterly whether anything you depend on has been abandoned. Deactivated plugins still sit on disk and can still be exploited.

Automate what you safely can

Enable automatic updates for security releases, keep a staging environment for anything larger, and make sure someone receives the notification when an update fails. An automatic update that silently stopped working three months ago is worse than manual updates, because everyone believes it is handled. Teams that hire WordPress developers for ongoing care usually get this monitoring as part of the arrangement rather than as an extra.

Get HTTPS Right, and Understand Its Limits

HTTPS is now the baseline rather than an upgrade, and it costs nothing. The original advice to buy a certificate as a one-time purchase is out of date in two ways.

Certificates are free and short-lived now

Services such as Let's Encrypt issue certificates at no cost, and modern certificates are deliberately short-lived and renewed automatically. That is a security improvement rather than an inconvenience, since a stolen certificate is useful for a much shorter window.

The practical requirement is that renewal is automated and monitored, because an expired certificate takes your site down as effectively as an outage.

What TLS actually protects

It protects data in transit between the visitor and your server. It does not protect data stored in your database, it does not make your application code safe, and the padlock says nothing about whether a site is trustworthy.

This distinction matters because a false sense of completeness around HTTPS is common, and because the original phrasing suggested it secures your website data generally rather than in transit specifically.

Finish the job with headers

Redirect all HTTP traffic to HTTPS, enable HSTS so browsers refuse to downgrade, and set a Content Security Policy to limit which scripts can run. Those three take an afternoon and close off a category of attack that certificates alone do nothing about.

Defend Against Injection and Input Attacks

The original article's SQL injection explanation was correct and is worth keeping. Injection remains one of the most consequential vulnerability classes catalogued in the OWASP Top Ten, and the fix is still parameterized queries.

The rule, restated

Never build a query by joining strings with user input. Pass the input as a parameter so the database treats it as a value rather than as instructions. In PHP with PDO that looks like this.

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email'); $stmt->execute(['email' => $userInput]);

The same principle applies in every language and framework. If your query contains a variable inside the SQL string itself, it is a candidate for review regardless of how well you think the input is filtered.

The trap in modern frameworks

Using an ORM does not automatically protect you. Most frameworks provide an escape hatch for raw SQL, and that is exactly where injection reappears in otherwise modern codebases. Search your project for raw query methods and check each one, which is a routine part of how our teams review a codebase when clients hire Laravel developers to take over an existing application.

Injection is not only SQL

Cross-site scripting happens when user input is rendered into a page without escaping, letting an attacker run JavaScript in your visitors' browsers. Command injection happens when input reaches a shell. Both follow the same underlying rule: validate what you accept, escape on output according to context, and never trust that a value is safe because it arrived from your own form.

Keep Backups You Have Actually Restored

An untested backup is a belief, not a control. The original correctly warned against storing backups on the same server, and the more common failure we encounter is that the backup exists and does not work.

The rule worth adopting

Three copies of your data, on two different media or services, with one held somewhere separate from your production environment. That separation is what protects you when the server itself is compromised, and it is why a backup sitting in the same hosting account is only partial insurance.

Test the restore, on a schedule

Once a quarter, restore into a scratch environment and time how long it takes. You are checking three things: that the backup is complete, that you know the procedure, and that the elapsed time is acceptable to the business. Discovering during an incident that a restore takes eleven hours is a materially worse day than knowing it in advance and planning for it.

Retention matters against ransomware

Keep enough history to recover from a compromise you did not notice immediately. If your only backup is from last night and the site was backdoored three weeks ago, you will faithfully restore the backdoor. Thirty days of retention is a reasonable floor for most businesses, and immutable or write-once storage is worth the small extra cost.

Two Things the Original Article Missed

Two controls do more for a typical site than anything above and appeared nowhere in the 2018 version. Both are ordinary engineering hygiene rather than security products.

Get secrets out of your code

Database passwords, API keys and tokens should live in environment variables or a secrets manager, never in the codebase and never in version control. Once a key has been committed it exists in the repository history even after you delete the line, so it must be rotated rather than removed. Scanning your own history for accidentally committed credentials is a worthwhile afternoon on any project older than a year.

Log enough to notice

The reason breaches are discovered weeks late is that nothing was watching. Record authentication attempts, administrative actions and server errors, keep them somewhere an attacker cannot edit, and set alerts on the handful of signals that matter: repeated failed logins, a new administrator account, unexpected file changes, or a sudden traffic pattern. Configuring that properly is standard work for whoever you hire DevOps engineers to look after infrastructure, and it converts a six-week discovery into a same-day one.

Rate limiting belongs in the same category. Limiting login attempts and expensive endpoints defeats credential-stuffing and much automated abuse without any additional software, and it is a configuration change rather than a project.

What to Do in the First Hour of a Breach

If your site is compromised right now, work through this order rather than starting with the cleanup. Most of the lasting damage comes from acting in the wrong sequence.

1. Take the site offline or into maintenance mode to stop ongoing harm to visitors.

2. Preserve evidence: copy logs and take a disk snapshot before changing anything.

3. Rotate every credential, including database passwords, API keys and all admin accounts.

4. Identify how they entered, because restoring without knowing means being compromised again.

5. Restore from a backup predating the compromise, then patch the entry point before going live.

6. Check your obligations: personal data breaches carry notification duties in the UK, EU and Australia.

That fourth step is the one people skip under pressure, and skipping it is why sites get re-compromised within days. Restoring a clean backup onto an unpatched vulnerability simply resets the clock for the attacker. If you handle personal data, treat the notification question as urgent rather than administrative, since the timelines in several jurisdictions are measured in days rather than weeks.

What Website Security Costs

Preventive security is inexpensive and predictable; incident recovery is neither. These are prevailing market ranges rather than fixed quotes.

Location	Senior engineering rate	Relative cost
New York, USA	USD 110 to 200 / hour	Highest
United States (national)	USD 90 to 170 / hour	Very high
Australia	AUD 110 to 200 / hour	High
United Kingdom	GBP 65 to 130 / hour	High
Europe (EU)	EUR 70 to 140 / hour	High
India (Acquaint Softtech)	USD 25 to 49 / hour	Up to 40% lower

Work	What it covers	Estimated cost (USD)
Security audit	Versions, access, config, exposure	1,500 to 6,000
Hardening sprint	MFA, headers, rate limits, secrets	3,000 to 12,000
Code review for injection	Query and input handling review	4,000 to 18,000
Backup and restore setup	Off-site, retention, tested restore	2,000 to 8,000
Breach cleanup and recovery	Forensics, removal, hardening	8,000 to 60,000+
Ongoing monitoring	Per year, patching and alerting	6,000 to 30,000

Compare the first row against the fifth and the argument makes itself. An audit costs a fraction of a cleanup, and the cleanup figure excludes the parts that hurt most: lost sales during downtime, search rankings damaged by injected spam pages, and the customer trust that takes far longer to rebuild than the site does. For how security work fits inside a wider budget, our guide to web application development cost covers the surrounding line items.

If you take card payments, security also becomes a compliance obligation rather than a choice, which changes both the scope and the frequency of the work, and it is one of the first things we scope in ecommerce development engagements.

Frequently Asked Questions