How to secure a website

Where website security actually fails

Learning how to secure a website is less about exotic attacks and more about closing the doors attackers try first. On small business sites, the usual way in is one of these:

• An outdated plugin, theme or CMS with a known vulnerability.
• A weak or reused password on the admin, control panel or FTP account.
• A former employee, freelancer or agency that still has access.

And the usual reason a break in becomes a disaster is that there is no clean backup to restore.

This guide covers the controls in priority order, then explains your obligations if something does go wrong in India.

Who protects what

Security is shared between you and your host. Knowing the split stops you assuming someone else is handling it.

The hosting provider	You, the site owner
Physical servers and network	CMS, plugins and themes, and keeping them updated
Operating system and control panel patching	Passwords and two factor authentication on your logins
Server level firewalls and isolation between accounts	Who has admin, FTP and control panel access
Infrastructure backups, as listed in your plan	Your own off site copy of backups
	What you upload, install and connect to the site

1. Keep everything updated

Updates fix known security holes. Once a fix is public, attackers scan the internet for sites that have not applied it.

• Update the CMS core, plugins and themes. On WordPress, enable automatic updates for minor releases at least.
• Delete plugins and themes you do not use. Deactivated code can still be exploited if its files are reachable.
• Keep PHP on a supported version. See changing the PHP version in cPanel.
• Avoid "nulled" (pirated) premium plugins. They are a common way malware gets installed.

2. Use strong passwords and two factor authentication

Every login that can change your site is a target: CMS admin, control panel, FTP, database, registrar and the hosting client area.

• Use a password manager and a unique, long password for each account.
• Turn on two factor authentication (2FA) wherever it exists. cPanel includes a Two Factor Authentication feature where the host enables it; WordPress needs a plugin for it.
• Never share one admin login between people. Give each person their own account so you can remove them individually.
• Protect the registrar account too. Whoever controls your domain controls where your site and email point.

The help article on securing your hosting account walks through the control panel and client area settings.

3. Turn on HTTPS everywhere

An SSL/TLS certificate encrypts traffic between visitors and your server, so login passwords and form data cannot be read in transit. Browsers also mark HTTP pages as "Not secure".

• Install a certificate and redirect all HTTP traffic to HTTPS.
• Fix mixed content (HTTP images or scripts on HTTPS pages). See fixing "Not secure" and mixed content warnings.
• Once HTTPS works everywhere, consider the Strict-Transport-Security header so browsers always use HTTPS.

ODHOST shared plans include a free SSL certificate. To understand what the certificate does and does not protect, read how SSL certificates work.

4. Keep backups you can actually restore

A backup is your undo button after a hack, a bad update or an accidental deletion.

• Know what your host backs up and how often. ODHOST shared plans list weekly backups; ask support how restores work for your plan.
• Keep your own copy as well, stored off the server (your computer, cloud storage or both). Follow the 3-2-1 idea: three copies, on two kinds of storage, one off site.
• Back up more often if your site changes daily, such as an online shop taking orders.
• Test a restore once. The help article on restoring a backup in cPanel shows how. More detail is on the website backups page.

5. Apply least privilege

Give each person and each piece of software only the access it needs.

• Use an Editor or Author role for staff who write content; keep Administrator for one or two people.
• Create separate FTP accounts limited to specific folders instead of sharing the main control panel login.
• Give each website its own database user with access only to its own database.
• Remove access the day a freelancer's contract ends.

6. Set correct file permissions

Wrong permissions let attackers write files where they should not. The typical safe defaults on Linux hosting, recommended in the WordPress hardening guide, are 755 for directories (the owner can write; others can read and enter), 644 for files (the owner can write; others can read) and something tighter for the configuration file that holds your database password. With SSH access:

find public_html -type d -exec chmod 755 {} \;
find public_html -type f -exec chmod 644 {} \;
chmod 440 public_html/wp-config.php

Never use 777. If a plugin asks for it, that is a warning sign. Without SSH, you can change permissions in cPanel File Manager. The WordPress hardening guide suggests 400 or 440 for wp-config.php, so only you and the web server can read it. Some server setups need a different value; check with your host if a tighter setting causes errors.

7. Add a web application firewall

A web application firewall (WAF) filters malicious requests, such as SQL injection or login brute forcing, before they reach your site. Options include a security plugin with firewall rules, a CDN with WAF features, or server level rules on a VPS. Pair it with login rate limiting so bots cannot try thousands of passwords.

The OWASP Top Ten lists the most common web application risks and is a good reference if you commission custom development.

8. Scan for malware and watch for warning signs

• Run a malware scanner regularly, either a security plugin or a tool your host provides.
• Add your site to Google Search Console, which emails you if Google detects malware or hacked content.
• Check admin users and recently modified files every month.
• Watch for spam being sent from your domain. Mail landing in spam suddenly can mean an account has been compromised; the emails going to spam help article covers diagnosis.

If your website is hacked

1. Contain. Change all passwords (control panel, CMS, FTP, database, email) from a clean device. Enable 2FA.
2. Preserve evidence. Download logs and a copy of the infected files before cleaning, in case you need them for a report.
3. Restore or clean. Restoring a known clean backup is usually fastest. Then update everything before going live, or the same hole will be used again.
4. Inform your host. Open a ticket so the provider can check the account and server. ODHOST support is available by ticket and phone.
5. Report where required. See the next section.

CERT-In reporting obligations in India

The Indian Computer Emergency Response Team (CERT-In) is the national agency for cyber incident response under section 70B of the Information Technology Act, 2000. On 28 April 2022 it issued directions under section 70B(6) that took effect 60 days later. The key points for website owners:

• Who: service providers, intermediaries, data centres, body corporates and government organisations.
• What: cyber incidents listed in Annexure I. The list includes defacement of a website or intrusion into a website with unauthorised changes such as inserted malicious code, unauthorised access to IT systems or data, malicious code attacks including ransomware, attacks on database, mail and DNS servers, phishing, DoS and DDoS attacks, data breaches and data leaks.
• When: within 6 hours of noticing the incident or being told about it.
• How: by email to incident@cert-in.org.in, phone 1800-11-4949 or fax 1800-11-6969. CERT-In publishes reporting formats on its website.
• Logs: covered entities must enable logs of their ICT systems and keep them for a rolling 180 days within Indian jurisdiction.
• Clocks: covered entities must sync system clocks to NTP servers of the National Informatics Centre (NIC) or National Physical Laboratory (NPL), or servers traceable to them.

"Body corporate" is a broad term under the IT Act, and many businesses with a website may fall within it. This guide is general information, not legal advice. If you are unsure whether the directions apply to you, or what to include in a report, consult a lawyer and read the official directions.

In practice: keep your host's and your own logs, note the time you discovered an incident, and decide quickly whether it needs reporting.

Website security checklist

Done	Control
☐	CMS, plugins and themes updated; unused ones deleted
☐	Supported PHP version
☐	Unique passwords in a password manager
☐	2FA on control panel, CMS admin, registrar and client area
☐	HTTPS on every page, HTTP redirected
☐	Off site backup copy; restore tested
☐	Individual user accounts with the lowest role needed
☐	File permissions 755/644, no 777
☐	WAF or security plugin with login rate limiting
☐	Monthly malware scan and admin user review
☐	Incident plan with CERT-In contact details noted