Website Security: A Practical Guide for Site Owners

A secure website needs more than an up-to-date CMS or an HTTPS connection. Protect the accounts that control it, the software it runs, the information it stores and the backups you would need after an incident.

Identify your responsibilities before changing settings

List your domain registrar, administrative email, hosting account, CMS, payment service and backup provider. Record who can change each one and who can help you recover access. Your domain and email may be needed to recover the website, so they need protection even if another company maintains the site.

A managed service does not automatically include every plugin or application you install. Check the support agreement and obtain a named contact for urgent incidents.

Protect the accounts that can take over your website

• Use unique passwords, a reputable password manager and multi-factor authentication for email, domain, hosting, CMS and backup administrators. Prefer phishing-resistant options such as security keys or passkeys when the service supports them.
• Use individual administrator accounts rather than a shared login. Give editors and contractors only the permissions their work requires, and remove access when that work ends.
• Keep recovery codes and backup authentication methods in a secure place separate from the account. Test the recovery process without locking out the administrator.
• Review recovery email addresses, active sessions, connected applications and API credentials. An attacker may keep access through an integration after a password is changed.

Enrollment in two-step verification requires the account holder to register their own method. Do not send passwords, one-time codes or recovery codes to a support agent or an unsolicited caller.

Reference: FIDO Alliance: passkeys and phishing-resistant sign-in.

Update the CMS, extensions and runtime as separate systems

Inventory the operating system, CMS, themes, plugins, libraries and runtimes. Include parked domains, staging sites, old forms and scheduled jobs. A WordPress dashboard that says “up to date” does not establish that the web server’s PHP has been patched.

Prioritize security fixes that apply to an exposed component. Take a usable backup, check compatibility in a restricted staging environment and schedule the necessary restart or reload with the responsible administrator. Then verify the version actually serving requests and test important functions.

Obtain updates from the product’s official distributor or your supported operating-system repository. A vendor may backport a fix into an older-looking package number; confirm the package advisory and the relevant CVE rather than relying on the number alone. Removing a version banner or adding a WAF rule does not repair the runtime.

Check the PHP vulnerability notices and update checklist →

Limit what forms, files and accounts can expose

Collect only the information your service needs and define how long it is retained. Restrict access on the server, not just by hiding a button or guessing that a long URL will remain private. Check what an anonymous visitor, a normal customer and an administrator can retrieve.

Keep database exports, backups, configuration files and private uploads outside public download locations. Developers should validate uploaded files, restrict their size and type, prevent uploaded content from executing, and enforce authorization for every request. Do not place real customer data in an openly accessible test site.

Technical references: OWASP authorization guidance and file-upload guidance.

Use WAF, HTTPS and traffic protection for their different purposes

Test a protective rule against normal sign-in, forms, checkout, search, uploads and authorized integrations. Use a narrowly scoped exception only after you know which request is being blocked. Do not disable the whole WAF, block a country or ban shared networks solely because traffic increased.

Include advertising tags and connected services in the review

Record who controls analytics, advertising, chat, payments, tag managers and other third-party scripts. Protect those accounts, remove obsolete integrations and review changes. A script included on your website can affect visitors even when your own application code has not changed.

Introduce browser security policies carefully with your developer. A strict policy deployed without testing can break checkout, sign-in, advertising or consent controls. Review the required sources and test in an appropriate reporting or staging workflow before enforcement.

Reference: OWASP: third-party JavaScript management.

Make sure a backup can be restored without restoring the attacker

Back up both the files and database, plus the configuration needed to rebuild the service. Keep a protected copy outside the production account, restrict backup deletion and check that the schedule is succeeding. An attacker who controls production should not automatically be able to erase every recovery copy.

Test restoration in an isolated environment. Record how much data you could lose between backups and how long recovery takes. After a suspected intrusion, identify a trustworthy recovery point and close the entry path before restoring. A successful restore test does not establish that the most recent backup is clean.

Reference: CISA: ransomware prevention and response.

If compromise is suspected, contain it and preserve evidence

1. Contact the responsible team. Give the host or incident responder the affected domain, time zone, symptom, screenshots and recent changes. Use a known contact method.
2. Contain the affected system. Have the team restrict access or isolate the affected service while preserving logs and relevant copies. Coordinate the impact on customers and business operations.
3. Do not destroy evidence. Avoid bulk deletion, repeated resets or restoring over the only remaining evidence. Preserve timestamps, access logs, account changes and provider messages securely.
4. Recover through a trusted environment. Assess accounts, sessions, API tokens and connected systems as well as files. Rotate affected secrets and revoke unauthorized access under the response plan, then verify the clean service before reopening it.
5. Assess notification duties promptly. Ask the responsible privacy or legal adviser to determine which authorities and individuals must be informed. The applicable countries, sector and facts determine the requirements; there is no single worldwide reporting deadline.

For a provider outage without evidence of compromise, first match the service, region and error on the outage page or the status monitor. Do not treat a missing status notice as proof that your own site is safe.

Keep a short checklist with an owner and evidence

A message you can send to your host or maintainer

Please confirm which web runtime and server packages serve this domain, whether the relevant security fixes are installed, and who is responsible for remaining updates. Include staging sites and scheduled jobs. Please provide the update or containment plan, backup and rollback arrangements, and the results of sign-in, form, checkout and integration checks.

Further guidance: WordPress security hardening and CISA resources for small and medium businesses.