Website Security Crash Course
The Terms, the Common Mistakes and a Checklist, in Plain Words

This is the website companion to our cybersecurity crash course, which covers passwords, two-step verification, backups and scams for people in general. This page adds the layer that belongs to whoever runs a website: a blog, a small shop, a portfolio, a WordPress site or a static one. It explains what each risk is and how to prevent it, in plain words, with each claim traced to its source: OWASP (the Open Worldwide Application Security Project), MDN (the web’s reference documentation), NIST, CISA, the certificate industry’s own rules, and the platforms’ own documentation. It recommends nothing you have to buy and gives no legal advice. Figures and rules are as of September 2026.

Do these first

None of the official guides we checked (the UK NCSC’s small organisations guide, CISA’s Secure Our World and OWASP’s verification standard) puts these steps in order for a small website, so the order below is ours. It follows the evidence: in the breaches Verizon studied for its 2026 report, exploiting unpatched software was the most common way in, ahead of phishing and of stolen or misused logins.

1. Put two-step verification on four accounts: your domain registrar, your host, your site’s admin login and your code repository or deploy account. The registrar and the host come first, because they control everything else.
2. Turn updates on, and delete plugins and themes you do not use — delete, not just deactivate.
3. Back up both the files and the database, keep at least one copy away from the host, keep several dates, and test a restore.
4. Serve everything over HTTPS, renewing automatically, with an expiry alert from something other than the company that issues the certificate.
5. Give each person their own account at the lowest role that works, and remove old accounts.
6. Keep the domain safe: auto-renew with a working card, transfer lock on, a contact email you read, and no DNS records left pointing at services you stopped using.
7. Add the security headers described below.
8. Know when something changes: an uptime alert, a file-change alert, and a look at the admin-user list now and then. Verify the site in Google Search Console so Google can tell you if it finds a problem.
9. Keep nothing secret in the public folder or a public repository, and replace any key that ever was.
10. Give people a way to report a problem, with a security.txt file (see below).

The words you will meet

HTTPS, TLS and certificates

HTTPS “is an encrypted version of the HTTP protocol”. “It uses TLS to encrypt all communication between a client and a server.” TLS is the encryption layer, “formerly known as Secure Sockets Layer (SSL)”. A certificate is the file that proves to the browser that the server really is the domain it claims to be; TLS requires “the server to provide a valid digital certificate confirming its identity”.

Certificates are getting shorter-lived, which makes automatic renewal essential. The certificate industry’s rules (the CA/Browser Forum) set the maximum lifetime at 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Let’s Encrypt, the free certificate authority, already issues shorter certificates. In December 2025 it said: “We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.” The 47 and the 45 are not a conflict: one is the industry ceiling, the other is one authority’s own choice. Let’s Encrypt also stopped emailing expiry warnings on 4 June 2025, and now recommends monitoring “to alert appropriately if certificates aren’t renewed when expected.” Many hosts renew for you; check that yours does.

DNS, the registrar and registrar lock

DNS is the internet’s address book: its main job “is the translation of human-friendly domain names (such as mozilla.org) to a numeric IP address”. The registrar is the company you rent the domain from. Whoever gets into that account can move the domain away from you. A transfer lock (clientTransferProhibited) “tells your domain’s registry to reject requests to transfer the domain from your current registrar to another”. Some registries also offer a stronger registry lock; ask your registrar.

CMS, plugins, themes and the admin panel

A CMS (content management system — WordPress, Joomla, Drupal and the hosted builders) is the software that lets you edit a site without writing code. Plugins add features and themes change the look; both are other people’s code running with your site’s permissions. The admin panel is where you log in to change everything, which is why attackers go after it. Your host usually is not responsible for the software you install on top. WordPress’s own handbook: “Web hosts are often responsible for the infrastructure on which your website sits, they are not responsible for the application you choose to install.”

Dependencies and the supply chain

Your site is built on other people’s code: the CMS, its plugins, JavaScript libraries, build tools, the script a chat widget loads. A supply-chain attack is “an incident where an adversary exploits vulnerabilities in the product or service supply network of the intended target”, so the harm arrives through a trusted update.

Secrets and API keys

A secret is anything that lets a program act as you: a database password, an API key, a payment-provider key. It belongs in the server’s settings, never in code sent to the browser and never in a public repository. Deleting it later does not undo a leak: “Secrets persist in Git history even after removal from current code.” The fix is to revoke it and issue a new one; GitHub’s advice is to “rotate the affected credential immediately”.

Backups, site by site

For backups in general, see the crash course. The website point: “There are two parts to backing up your WordPress site: Database and Files.” “You need both to be able to fully restore a typical WordPress site.” Keep several dates, because a hack is often noticed late — the handbook’s example is a site “compromised on May 1st but the compromise is not detected until May 12th”.

Firewalls, CDNs, floods and rate limiting

• A web application firewall (WAF) sits in front of a site and “applies a set of rules to an HTTP conversation” to block common attacks. It is a filter, not a fix (see the myths).
• A CDN “is a group of servers spread out over many locations”, so visitors load your files from nearby. Many also cope better with heavy traffic.
• A DDoS attack is a flood of traffic from many machines meant to knock a site offline. CISA and its partners describe three kinds: “Volumetric, attacks aiming to consume available bandwidth”, protocol attacks and application attacks.
• Rate limiting is the server telling any one visitor to slow down. MDN calls asking a visitor to slow down “rate limiting”, and its error code is 429.

Security headers

Security headers are short instructions your server sends with every page, telling the browser what it may do with it. On most hosts they cost nothing to add.

Header	What it does
Strict-Transport-Security (HSTS)	Tells browsers the site “should only be accessed using HTTPS”, and stops visitors clicking past certificate errors.
Content-Security-Policy (CSP)	Lists where scripts may load from; “mainly used as a defense against cross-site scripting (XSS) attacks”.
frame-ancestors (in CSP) or X-Frame-Options	Stops other sites showing your page inside a frame, to “avoid clickjacking attacks”.
X-Content-Type-Options: nosniff	Tells the browser not to guess a file’s type.
Referrer-Policy	“controls how much referrer information” is passed on when a visitor follows a link.

One header you should not add is X-XSS-Protection, still found in old checklists. OWASP’s guidance now is: “Do not set this header or explicitly turn it off.”

HSTS preload is a genuine disagreement. OWASP’s recommended header includes preload, which signals that you consent to your domain being built into browsers as HTTPS-only; the domain is added only once it is submitted to the list. The people who run that list ask anyone who gives HTTPS configuration advice: “do not include the preload directive by default”, because “inclusion in the preload list cannot easily be undone” and removal “takes months”. Both agree HSTS itself is good. Our reading: turn HSTS on, raise its duration in stages, and treat preloading as a separate decision for later, once every subdomain works over HTTPS.

Cookie flags

A cookie is how a site remembers that someone is logged in. Secure means it is only sent over HTTPS; HttpOnly “forbids JavaScript from accessing the cookie”; SameSite limits cross-site request forgery. MDN’s warning: “Do not assume that Secure prevents all access to sensitive information in cookies”. On a CMS you rarely set these by hand; they matter when you choose software or build your own login.

Two-step logins and least privilege

For the kinds of two-step verification and why some resist phishing better, see the crash course. Every account that can publish, install plugins or change settings is a door into the site and needs its own login with two-step verification. Least privilege means restricting access “to the minimum necessary to accomplish assigned tasks”: an author does not need to be an administrator.

Logs and alerts

A log is the site’s diary of who asked for what and when. “Without logging and monitoring, attacks and breaches cannot be detected”, and OWASP adds that “great logging with no alerting is of minimal value”. Something has to tell you.

security.txt

If a stranger finds a hole in your site, how do they tell you? security.txt is a small file at /.well-known/security.txt saying who to contact. Its format is described in RFC 9116 (April 2022), which is informational rather than a formal standard. Two fields are required: Contact and Expires. The RFC’s own warning is that having no file at all “may be preferable to having stale information in this file.”

The OWASP Top 10, in plain words

The OWASP Top 10 is “a standard awareness document for developers and web application security”, not a rulebook you comply with. The current edition is the 2025 list; OWASP says “The most current released version is the OWASP Top 10 2025”. It is written for developers. In our reading, a blog or small-shop owner mostly meets numbers 2, 3, 7 and 9 — settings, plugins and dependencies, logins, and noticing trouble.

#	Name	In plain words
A01	Broken Access Control	People can see or do what they should not: another customer’s order, an admin page.
A02	Security Misconfiguration	The software is fine, the settings are not: defaults left on, debug pages exposed.
A03	Software Supply Chain Failures	Something you depend on is out of date or has been tampered with.
A04	Cryptographic Failures	Data that should be encrypted is not, or the keys leak.
A05	Injection	Text typed into a form is treated as an instruction instead of data.
A06	Insecure Design	The plan was flawed before any code was written.
A07	Authentication Failures	The login can be fooled or worn down by guessing.
A08	Software or Data Integrity Failures	The site trusts code or data it has not checked.
A09	Security Logging and Alerting Failures	Nobody would notice an attack.
A10	Mishandling of Exceptional Conditions	The site behaves badly when something unexpected happens.

What changed from 2021: “There are two new categories and one consolidation in the Top Ten for 2025.” The two new ones are supply chain failures, which OWASP calls “an expansion of A06:2021-Vulnerable and Outdated Components” (a new category for an old risk, widened), and mishandling of exceptional conditions. Server-side request forgery “has been rolled into” broken access control. And security misconfiguration “moved up from #5 in 2021 to #2 in 2025”.

The mistakes that let attackers in

Outdated and unused plugins and themes

On a CMS site, this is the main door. The figures come from one security company, Patchstack, which sells protection against exactly this, so read them as one company’s data rather than a census. It counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, “a 42% increase compared to 2024”; “91% of new vulnerabilities were found in plugins, and 9% were found in themes”; and only 6 were found in WordPress itself, all low priority. For the most-exploited ones, the weighted median time from disclosure to first attack was 5 hours, and “46% of vulnerabilities did not receive a fix from the developer in time for public disclosure.” Google’s own guidance agrees on the principle: “outdated or unpatched themes and plugins are a major source of vulnerabilities.” It also warns against pirated copies: “It’s a common tactic for attackers to add malicious code to free versions of paid plugins or themes.”

Updates are necessary but not always enough on their own, because a fix may not exist yet. That is why the second defence is having fewer plugins: “if you are not using a specific plugin, delete it from the system.”

Default or weak admin logins

“Default accounts and their passwords are still enabled and unchanged” is one of OWASP’s own examples of misconfiguration. Guessing is automated: “A brute force attack is the simplest way to break in: an attacker repeatedly tries username/password combinations until one works.” Two-step verification on every admin account is the answer; for passwords themselves, see the crash course.

Files left where anyone can download them

Anything inside the public folder of a site can be downloaded by anyone who guesses its name, and the guessing is done by scripts. Four common leaks: a .env or settings file holding passwords; a .git folder, which holds the project’s full history (“If these subdirectories are stored on a web server or added to an archive, then these could be used by an attacker”); a backup archive left next to the live files (“A backup file is stored in a directory or archive that is made accessible to unauthorized actors”); and directory listing switched on, which “exposes a directory listing with an index of all the resources located inside of the directory.” Keep secrets and backups outside the public folder, and switch directory listing off.

Cloud storage set to public

Amazon’s storage service, for one, now makes new storage private by default: “By default, new buckets, access points, and objects don’t allow public access.” The leak today is usually a setting someone changed to make something work: “users can modify bucket policies, access point policies, or object permissions to allow public access.”

Mixed content and expired certificates

Mixed content “refers to securely loaded web pages that use resources to be fetched via HTTP”, usually old http:// links to images or scripts left in posts after a move to HTTPS. Browsers now auto-upgrade images, video and audio and “block insecure requests for all other resource types”, so the symptom is usually something broken rather than a warning. Expired certificates are becoming more likely as lifetimes shrink; the visitor sees a full-page browser warning (below).

Roles that are too broad

WordPress’s roles run from Subscriber to Administrator, “somebody who has access to all the administration features”. Most people who write for a site need Author or Editor. Google lists “granting administrative access to users who don’t require it” among the ways sites get hacked.

Unpatched server software

If you run your own server rather than managed or static hosting, the web server, language and database need updates too. CISA keeps a catalogue of flaws already being used in real attacks, and “strongly recommends all organizations review and monitor the KEV catalog”. On 22 September 2026 it listed 1,721 of them. On managed or static hosting, the host patches the server; your part is the CMS, the plugins and the accounts.

Losing the domain

Three separate mistakes. First, a registrar account with no two-step verification and no transfer lock. Second, letting the domain expire: for most generic endings, “ICANN policy requires registrars to send you two renewal reminders approximately one month and one week before expiration”, which only help if the contact email works; after the grace periods the name is “released and made available for registration on a first-come-first-served basis”. Third, a dangling DNS record: a subdomain still pointing at a service you stopped using, which someone else can then claim so that your subdomain shows their content. OWASP’s summary: an attacker can “claim and take control of the victim’s subdomain.” Delete DNS records when you stop using what they point at.

What the warnings and error codes mean

“Your connection is not private”

The browser checked the certificate and something did not add up. Chrome’s own description: “there’s a problem with the site, the network, or your device.” Three common codes, with the meaning Chrome’s source code gives:

• NET::ERR_CERT_DATE_INVALID — the certificate has expired or is not yet valid. For an owner, the likely cause is a failed renewal, though a visitor’s wrong clock causes it too: “3. Our clock is wrong.”
• NET::ERR_CERT_COMMON_NAME_INVALID — the certificate is for a different name, for example it covers www. but not the bare domain: “The server is misconfigured and responding with the wrong cert.”
• NET::ERR_CERT_AUTHORITY_INVALID — signed by an authority the browser does not trust, or self-signed.

Do not tell visitors to click through. With HSTS on, the browser will not let them, by design.

“Not secure” and the red warning page

“Not secure” beside the address means the page loaded over plain HTTP: “Someone may be able to view and change the information you send and get through this site.” It is not an accusation; “the site owner must secure the site and your data with HTTPS.” A full-page red warning is different: “If you get a full-page red warning screen, the site is flagged as unsafe by Google Safe Browsing”. For an honest owner, a hack is one of the likely causes; Search Console’s Security issues report says which problem Google found.

HTTP error codes

Code	Name	In plain words
401	Unauthorized	You need to log in first.
403	Forbidden	The server “understood the request but refused to process it” — often a security rule or a file permission.
404	Not Found	Nothing at that address.
429	Too Many Requests	Slow down: rate limiting.
500	Internal Server Error	A catch-all for problems on the server; only the owner can fix it.
502	Bad Gateway	A middle server, such as a CDN, got a bad answer from the real one behind it.
503	Service Unavailable	“down for maintenance or overloaded” — meant to be temporary.

A detailed error page that prints file paths or software versions is itself a leak; OWASP lists “a lack of central configuration for intercepting excessive error messages” as a misconfiguration.

Google Search Console’s “Security issues”

If Google decides a site is hacked or harmful, its pages “can appear with a warning label in search results or an interstitial warning page in the browser”. The details are in Search Console under Security issues. Once every affected page is fixed, you ask for a review. “Fixing the issue on just some pages will not earn you a partial return to search results”, and “a review can take from a few days to a few weeks to complete.”

Myths, checked

Myth “My site is too small to be attacked.” Many website attacks are automated: “Many WordPress attacks are carried out autonomously by malicious software bots.” Nobody has to choose your site; being reachable is enough. The UK NCSC puts it plainly: “if you think your business is too small to be a target, think again.”

Myth “HTTPS means my site is safe.” HTTPS protects data on its way between the visitor and the server. It says nothing about whether the server, the CMS or the plugins are secure, and “hacks are often invisible to users, yet remain harmful to anyone viewing the page”. This agrees with the padlock myth in the crash course, seen from the owner’s side.

Myth “A security plugin is enough.” It is a useful layer. It does not update your other plugins, secure your registrar or hosting login, or make a backup you have tested, and it is itself a plugin. WordPress’s own handbook: “What security is though is risk reduction, not risk elimination.”

Partly true “Static sites can’t be hacked.” A site made of plain files has no login page, no database and no plugin code on the live server, so the most common way CMS sites are hacked is simply absent. This site is one. But the risk moves rather than vanishes. The browser runs code too. A page’s own scripts can still be open to injection, which OWASP defines as untrusted input “sent to an interpreter (e.g. a browser, database, the command line)”, and a page that loads third-party scripts inherits their risk: OWASP calls “a compromise of the third party JavaScript server” “the single greatest risk” of such scripts. The hosting account, the code repository and the registrar all have logins, and whoever takes one over can replace the whole site. And the build process pulls in dependencies. No standards body states this verdict in one sentence; it is our reading of those parts.

Myth “Hide the admin URL and you’re safe.” Moving the login page is obscurity, not a lock. NIST’s principle: “System security should not depend on the secrecy of the implementation or its components.” WordPress’s handbook agrees that “Security through obscurity is generally an unsound primary strategy”, while allowing it a small role, such as not calling your admin account “admin”. It is no substitute for two-step verification and updates.

Myth “A firewall replaces patching.” A WAF rule can block a known attack while you wait for a fix, and OWASP values that time: “50% reduction in 10 minutes is better than 100% reduction in 48 hrs.” But it is explicit that “the number one remediation strategy” is fixing the software itself, and that “Code level fixes and Virtual Patching are NOT mutually exclusive”.

If your site has been hacked

Google’s step-by-step guidance for site owners is the most complete public guide we found; the steps below are drawn from it.

1. Confirm it. Check Search Console’s Security issues report and the example pages it lists. Hacked content is often hidden from the owner: “Cloaking makes cleaning a site more difficult by showing different content to different types of users.”
2. Tell your host. “Your hoster can make sure their other customers weren’t affected, and they can potentially help recover your site.”
3. Take the site offline properly, with the offline notice served “from outside your compromised server or site”. Blocking search engines is not enough: “Using a robots.txt disallow is also insufficient because it only blocks search engine crawlers.”
4. Lock the accounts. Remove any accounts the attacker created, and “change the passwords for all site users and accounts” — hosting, file transfer, database and CMS — and revoke and reissue any API keys and tokens the site uses, as with any leaked secret.
5. Find how they got in, and keep looking after the first hole. Check the admin’s own computer too: “On an administrator’s virus-infected computer, the hacker might have installed spyware”.
6. Think before deleting anything if visitors’ personal data may have been taken: “consider any business, regulatory, or legal responsibilities before you begin cleaning your site or deleting any files.” Rules vary by country; this is not legal advice.
7. Clean up. “First, check that your backup was created before your site was hacked.” Otherwise do a clean installation — “Upgrades can leave files from a previous version” — and bring back only known-clean content. Update everything and remove what you do not use.
8. Ask Google for a review once every page is clean, and describe what you fixed. Asking too early “will only prolong the period of time that your site is flagged”.
9. Report it and tell the people who need to know. Where to report depends on where you are; the crash course has the list.

Sources

• OWASP: Top 10:2025 (introduction and the ten category pages) and the project page; Top 10:2021; cheat sheets on HTTP security headers, virtual patching and third-party JavaScript; Web Application Firewall community page; Web Security Testing Guide (subdomain takeover).
• MDN Web Docs: HTTPS, TLS, DNS, CDN, mixed content, Set-Cookie, Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Referrer-Policy, and HTTP status codes 401 to 503.
• CA/Browser Forum, TLS Baseline Requirements and Ballot SC081v3 (April 2025); Let’s Encrypt, “Expiration Notification Service Has Ended” (June 2025) and “Decreasing Certificate Lifetimes to 45 Days” (December 2025); hstspreload.org.
• NIST CSRC glossary (supply chain attack, least privilege); NIST SP 800-123, Guide to General Server Security (2008).
• CISA: Known Exploited Vulnerabilities catalogue (version of 22 September 2026); “Understanding and Responding to Distributed Denial-of-Service Attacks” (March 2024).
• MITRE CWE-527, CWE-530 and CWE-548; ICANN, EPP status codes and domain renewal FAQs; IETF RFC 9116 (April 2022).
• UK NCSC, Small organisations guide to cyber security (2026).
• WordPress Advanced Administration Handbook (hardening, backups, brute force) and Roles and Capabilities; GitHub Docs (secret leakage and secret scanning); Amazon S3 documentation (block public access); Google Chrome Help; Chromium source (net_error_list.h); Google Search Console Help (security issues report); Google web.dev hacked-site guides.
• Verizon, 2026 Data Breach Investigations Report, executive summary.
• Patchstack, “State of WordPress Security in 2026” (February 2026) — vendor research.

Checked September 2026.

Related: Cybersecurity crash course · Web design resources