Top 12 Website Security Practices

By George Mutune   Published: 11/02/19   Updated: 09/25/26   10 min read
Cybersecurity

Updated September 2026. We rewrote this guide for how websites get attacked today. It now covers modern TLS and the move to shorter certificate lifetimes, patching plugins against fast mass exploitation, MFA on admin accounts, web application firewalls, backups, and a new section on Content Security Policy (CSP) and security headers. We removed outdated 2012–2018 statistics.

Most website attacks aren’t targeted. Bots scan the internet for outdated plugins, weak admin passwords and misconfigured servers, then break in automatically. The 12 practices below close the gaps they look for. They apply to any site, whether it runs on WordPress or another CMS, a custom application, or a hosted site builder.

Common website security risks

Top 12 website security practices

1. Use HTTPS everywhere with modern TLS

Serve every page over HTTPS and redirect all HTTP traffic. Support TLS 1.2 and 1.3 only, and disable old SSL and TLS 1.0/1.1. Add an HTTP Strict Transport Security (HSTS) header so browsers always use HTTPS (MDN).

Automate certificate renewal. Under a CA/Browser Forum decision, the maximum lifetime of public TLS certificates dropped to 200 days for certificates issued from March 15, 2026, and will fall to 100 days in March 2027 and 47 days in March 2029 (CA/Browser Forum). Manual renewals won’t keep up, so use automatic renewal through your host, CDN or an ACME client with a free certificate authority such as Let’s Encrypt. HTTPS relies on public-key cryptography; our asymmetric encryption guide explains how it works.

2. Patch your CMS, plugins and themes quickly

Plugins are where most CMS vulnerabilities live. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, up 42% from 2024. 91% were in plugins, only six were in WordPress core, and 46% weren’t fixed by the developer when they were disclosed. For heavily exploited flaws, the median time to mass exploitation was 5 hours (Patchstack).

3. Require MFA on every admin account

Turn on multi-factor authentication for CMS admins and editors, and also for the accounts that control your site from outside: hosting control panel, domain registrar, DNS or CDN provider, and the email accounts used for password resets. Passkeys or security keys are the strongest option. Use long, unique passwords stored in a password manager, and limit login attempts. See our guide to multi-factor authentication.

4. Apply least-privilege access

Give each person their own account with the lowest role that does the job: most contributors don’t need admin rights. Remove accounts when people leave, review admin users regularly, and change default admin usernames and URLs where possible. In your own code, enforce authorization checks on the server for every request; broken access control was also the most exploited vulnerability type in Patchstack’s 2025 data.

5. Put a web application firewall (WAF) in front of the site

A WAF filters malicious HTTP requests such as SQL injection, cross-site scripting and known exploit attempts before they reach your application (Cloudflare). Cloud WAFs from CDN providers also absorb DDoS traffic and block bad bots, and many offer “virtual patching” rules that block attacks on a newly disclosed plugin flaw before you can update. A WAF supplements patching; it doesn’t replace it.

6. Keep backups you can actually restore

Back up files and databases automatically, at least daily for active sites. Keep copies off the web server and at least one offline or immutable copy that an attacker with your hosting login can’t delete. CISA recommends offline, encrypted backups and regular restore tests (CISA). Test a full restore to a staging site a few times a year.

7. Set security headers and a Content Security Policy

Security headers tell browsers how to handle your site and block whole classes of attacks. See the next section for a starter set.

8. Validate input and write secure code

Treat all user input as untrusted. Use parameterized queries to prevent SQL injection, encode output to prevent cross-site scripting, validate file uploads by type and size, and protect forms with CSRF tokens and rate limits. The OWASP Top 10:2025 lists the most critical web application risks, including injection (A05) and the new “Mishandling of Exceptional Conditions” (A10).

9. Control third-party scripts and dependencies

Every external script you embed, such as analytics, chat widgets, ads or tag managers, runs with full access to your pages. OWASP ranks software supply chain failures #3 in its 2025 Top 10. Keep an inventory of scripts and packages, remove what you don’t need, use Subresource Integrity (SRI) for scripts loaded from CDNs (MDN), and restrict script sources with CSP. If you take card payments, PCI DSS 4.0.1 requirements that became mandatory March 31, 2025 require an authorized inventory of payment-page scripts and monitoring for unauthorized changes to them and to security-impacting headers (PCI SSC).

10. Secure your hosting, domain and DNS

Choose a host that isolates accounts, patches servers, offers malware scanning and keeps logs. Turn on registrar lock and MFA at your domain registrar, keep domain contact details current so renewal notices reach you, and consider DNSSEC if your registrar and DNS provider support it. Don’t expose admin panels, databases or file-transfer services to the whole internet when you can restrict them by IP or VPN.

11. Log, monitor and alert

Log logins, admin actions, file changes and errors, and send alerts to someone who will act on them. OWASP renamed its logging category “Security Logging & Alerting Failures” in 2025 to stress that logs without alerts are of little value. Add uptime and file-integrity monitoring, and register your site in Google Search Console to get notified if Google detects malware or hacked content (Google).

12. Have a plan for when the site is hacked

Write down who to call (host, developer, payment provider), how to take the site offline or into maintenance mode, where clean backups are, and how to rotate every password and API key. After cleanup, find and fix the root cause, usually an outdated plugin or stolen password, before bringing the site back, then request a review in Search Console if the site was flagged.

Security headers and CSP basics

These response headers are a good starting point. Most can be added at the web server, CDN or through a security plugin (OWASP HTTP Headers Cheat Sheet; OWASP Secure Headers Project).

HeaderStarter valueWhat it does
Strict-Transport-Securitymax-age=63072000; includeSubDomains; preloadForces HTTPS for two years. Start with a shorter max-age and add preload only when every subdomain supports HTTPS.
Content-Security-PolicySee belowRestricts where scripts, styles, frames and other resources can load from, which limits cross-site scripting and injected skimmers.
X-Content-Type-OptionsnosniffStops browsers from guessing file types, which prevents some content-injection attacks.
Referrer-Policystrict-origin-when-cross-originLimits how much of your URLs are shared with other sites.
CSP frame-ancestors (or X-Frame-Options)frame-ancestors 'self' or X-Frame-Options: DENYPrevents other sites from framing yours (clickjacking). frame-ancestors supersedes X-Frame-Options in modern browsers.
Permissions-Policycamera=(), microphone=(), geolocation=()Turns off browser features your site doesn’t use.

OWASP recommends turning off the old X-XSS-Protection header (X-XSS-Protection: 0) rather than relying on it; modern browsers have dropped that filter, and CSP does the job better.

How to roll out a Content Security Policy

CSP is the most powerful header and the easiest to break a site with, so introduce it in stages (MDN):

  1. Start with Content-Security-Policy-Report-Only so the browser reports violations without blocking anything.
  2. Begin from a strict baseline and add the sources your site really needs, for example:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'
  1. Review the reports for a week or two, add legitimate sources and remove unused scripts.
  2. Switch to the enforcing Content-Security-Policy header. Avoid 'unsafe-inline' and 'unsafe-eval' for scripts where you can; nonces or hashes are the stronger option.
  3. Re-test after adding plugins, tags or embeds.

You can check your headers with your browser’s developer tools (Network tab, then Response Headers) or a free online header scanner.

Website security checklist

For the rest of your organization, use our full cybersecurity checklist and our password policy best practices.

Plugin and CMS vulnerabilities get exploited within hours. The CyberExperts Daily Brief flags the ones worth patching each weekday.

Frequently asked questions

What are the most important website security practices?

Keep your CMS, plugins and themes updated, require MFA on admin accounts, use HTTPS with automatic certificate renewal, run a web application firewall, keep tested off-server backups, and set security headers including a Content Security Policy.

How do most websites get hacked?

Mostly through outdated plugins and themes with known vulnerabilities, and through stolen or weak admin passwords. Patchstack found 91% of new WordPress ecosystem vulnerabilities in 2025 were in plugins, and heavily targeted flaws were mass-exploited within a median of 5 hours.

Do I still need an SSL certificate?

Yes, though it’s really a TLS certificate. It enables HTTPS, which browsers expect and search engines favor. Public certificates can now last at most 200 days, falling to 47 days by 2029, so set up automatic renewal.

What is a Content Security Policy?

A CSP is an HTTP header that tells the browser which sources of scripts, styles, images and frames your site allows. It limits the damage from cross-site scripting and injected malicious scripts. Roll it out in report-only mode first.

Is a web application firewall worth it for a small site?

Usually, yes. Cloud WAFs are inexpensive or included with many CDNs and hosts, block common attacks and bots, and can block exploits against newly disclosed plugin flaws before you patch.

How often should I back up my website?

At least daily for sites that change often, and before every update. Keep copies off the web server, including one an attacker can’t delete, and test restoring them regularly.

Which security headers should every website have?

Start with Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, frame-ancestors (or X-Frame-Options) and Permissions-Policy.

Sources

Stay Current

Newer CyberExperts coverage on this topic

This article still works as background. If you want the current picture, start with the freshest related coverage below and today's brief.

Latest Daily Brief

Friday’s brief: FortiMail due Saturday, then BoKS, vm2, Satellite

The fastest way to catch up on what changed after this article was published.

Read Today's Brief

George Mutune

I am a cyber security professional with a passion for delivering proactive strategies for day to day operational challenges. I am excited to be working with leading cyber security teams and professionals on projects that involve machine learning & AI solutions to solve the cyberspace menace and cut through inefficiency that plague today's business environments.