Protect Client Websites from Hacking: Fourteen Layers to Review

A website can be compromised through an exposed application, a stolen account or a weakness elsewhere in its management chain. Protecting it requires more than hiding the login screen. Start by understanding how someone could gain access and what they could do with it.

For a client site, include the domain, hosting, CMS, email and deployment tools in that review. An attacker who controls a reset mailbox or a broad reseller account may not need to exploit the public page at all. Keep the prevention plan tied to those real entry routes.

Four entry routes to consider

Weak or reused credentials can give access when another service is breached or a password is guessed. Unsupported software can expose known vulnerabilities. Phishing and malicious downloads can compromise the people and devices administering the site. Weak platform configuration or inappropriate account sharing can widen the effect of an initial intrusion.

These are categories for a threat review, not a claim that every incident has the same cause. A small website can still be targeted by automated activity. Avoid inventing a statistic about how many attacks would be prevented by one plugin or configuration change.

1. Verify the hosting foundation

Ask which platform components are maintained, how accounts are separated and how incidents are escalated. Choose a service compatible with the application and its risk, rather than treating a reassuring brand name as a technical control.

Record the supplier’s scope and the agency’s remaining work. A reseller plan does not automatically transfer all responsibility for a vulnerable CMS to the host.

2. Strengthen credentials and login hygiene

Use unique passwords and appropriate protected storage. Review who has access and how credentials are supplied to authorised people. Reused passwords can connect otherwise unrelated clients through one compromise.

Check recovery information and sessions as well as the main password. An old contractor’s account or reset address can undermine an otherwise careful setup.

3. Add suitable multi-factor protection

Enable supported additional authentication for important administrative accounts. Cover the registrar, hosting and email service where possible, not only the visible CMS login. Choose the method in context and protect recovery options.

Test how another authorised person would regain access if the normal administrator were unavailable. Do not leave production dependent on one unrecorded device or recovery code.

4. Keep CMS core supported

Track the application version and relevant security releases. Assign update responsibility and a way to verify the resulting website. Supported software is an ongoing requirement, not a task completed once at launch.

For material changes, use a safe test and recovery process. For urgent vulnerabilities, establish how the team acts promptly instead of postponing action indefinitely.

5. Review themes and plugins separately

Extensions have their own release and support history. Remove unnecessary components and replace required but abandoned ones. Obtain packages through trustworthy sources rather than assuming a familiar name makes any download legitimate.

Review customisations that can block updates. An old theme modified directly may create a hidden maintenance dependency that the client’s ordinary dashboard does not explain.

6. Protect communication with HTTPS

Configure valid TLS coverage for the intended endpoints and monitor renewal. Check administration and recovery links as well as the public homepage. Network protection matters when credentials and customer information are transmitted.

Keep its limits clear. HTTPS does not stop a compromised extension running malicious code or prove that all information stored by the application is protected.

7. Prepare independent recovery

Define backup coverage, schedule and retention around the client’s acceptable loss. Protect copies from the same credentials or incident that could affect production where practical. Restore a representative version safely to confirm the procedure.

A backup does not prevent intrusion. A compromised restore point can also preserve malware, so investigation and selection of a known-good state matter after an incident.

8. Use filtering as an additional layer

Apply appropriate supported firewall or web application controls and review their behaviour. They may block certain abusive requests while leaving other attack paths unaffected. Keep software updates and authentication protections in place.

Check legitimate customer journeys after rule changes. A payment notification silently blocked by a filter can harm the service even if a security dashboard appears quiet.

9. Restrict administrative privileges

Separate publishing from installation and account administration. Give people the capabilities they need for their tasks, and remove access when their role ends. Review powerful reseller and deployment permissions particularly carefully.

Do not use one shared administrator account merely because it is convenient. Individual accountability helps investigate unusual changes and supports safer handover.

10. Detect unauthorised code and content

Use appropriate integrity checks, malware scanning and reviews of unexpected changes. Understand what each tool covers and who receives findings. A scan should produce an investigation route rather than a report that nobody reads.

False positives are possible, and an apparently clean result is not absolute proof. Escalate repeated unexplained changes or suspicious behaviour with useful evidence.

11. Secure client email accounts

Review the accounts used for password recovery, administration and important notifications. Apply suitable authentication and check for unfamiliar forwarding or integration access. A mailbox can be an indirect route to website control.

Verify unusual requests outside the questionable message. Do not create a new administrator solely because an email claims a senior client urgently needs one.

12. Review file access and storage boundaries

Follow the application’s supported permissions and ownership requirements. Keep backups, exports and configuration secrets out of public delivery where appropriate. Avoid making a whole application writable as a shortcut to fixing one error.

Inspect upload handling where users can submit files. A filename or extension check alone may not establish that content is safe to store or execute.

13. Monitor activity and service symptoms

Keep useful logs and alert routes for authentication, unexpected changes and failures. Monitor important business functions as well as the homepage. Correlate events using timestamps so the team can investigate patterns.

Protect operational records and choose appropriate retention. Logging can itself expose sensitive information if passwords or private content are recorded unnecessarily.

14. Prepare clients to recognise and report problems

Explain the real support and login routes, common suspicious requests and how to raise a concern. Encourage prompt reporting without blame. A client who asks about an unusual renewal message can prevent a larger problem.

Provide a short contact plan for suspected compromise. The first response should coordinate containment and evidence preservation rather than invite several people to delete files independently.

Validate the layers with a scenario

Choose a realistic scenario such as a stolen editor account. Identify what that role can change, who would notice and how access would be revoked. Repeat with an unavailable administrator or a vulnerable extension. This reveals gaps between policies and actual configuration.

Use specialist assistance when the application or incident exceeds the team’s competence. Do not test attacks against production or third-party infrastructure without proper authorisation. A safe review can establish responsibilities and controls without manufacturing a penetration-test result.

Keep prevention and response connected

Review hosting arrangements alongside the application and account chain. Record verified controls and unresolved requirements, then revisit them when the site changes. If an incident occurs, use that record to support a measured response and a safer recovery rather than assuming one missed measure explains everything.