How to Protect Your Business Website From Hackers: A Step-by-Step Guide for Nigerian Businesses

How do hackers actually get into business websites?

Hackers get into business websites through five entry points: vulnerable software (outdated CMS, themes or plugins), weak or reused credentials, insecure hosting configuration, unprotected forms and upload features, and access left behind by former developers or staff. Almost every SME breach traces back to one of these, and each has a direct fix.

Note what is missing from the table: nobody "breaks the encryption". If your site has HTTPS, attackers do not attack the padlock; they walk in through a door someone left open.

Step 1: Lock down the accounts that control the site

Start with the accounts, because a strong website behind a weak hosting-panel password is still a weak website. The controlling accounts are the domain registrar, DNS provider, hosting control panel, server login (SSH/SFTP), CMS administrator, payment gateway dashboard and the business email that receives password resets for all of them.

1. List every account and who can access it. Include the developer and any agency.
2. Move ownership to the business. Registrar, hosting and gateway accounts should be registered to a company email address that more than one director can reach, not to a developer's Gmail.
3. Set a unique, long password on each, generated and stored in a password manager. Reuse is the single most common cause of takeover.
4. Enable two-factor authentication everywhere it is offered, preferring an authenticator app over SMS. SMS codes are better than nothing but SIM-swap fraud exists in Nigeria as elsewhere.
5. Remove old users. Delete or disable every account belonging to former staff, interns and contractors. Do this the day someone leaves, not at the next audit.
6. Give people the lowest role that lets them work. A content editor should not be an administrator; the accountant checking orders does not need plugin-install rights.

For custom-built applications, the same applies to the code repository, cloud console and deployment tools: they are control accounts too.

Step 2: Update everything and remove what you do not use

The majority of CMS breaches exploit vulnerabilities that were already fixed by the vendor; the site simply had not applied the update. Updating is therefore the highest-value technical step, and pruning reduces how much you must keep updated.

• Update the CMS core, theme and every plugin. Take a backup first (Step 8), then update on a staging copy if the site is business-critical, then on the live site.
• Delete, do not just deactivate, unused plugins and themes. Deactivated code can still be exploited in some cases and still needs patching.
• Replace abandoned plugins. If a plugin has not been updated in a year, or its developer has gone quiet, find a maintained alternative. Check the plugin's changelog and support forum before installing anything new.
• Turn on automatic updates for minor CMS releases and for plugins with a good stability record; schedule a monthly manual review for the rest.
• Update the server software too: PHP version, database and operating system on a VPS. Old PHP versions stop receiving security fixes.

For custom applications, ask your developer for a dependency update schedule and a tool that flags known-vulnerable libraries. A modern web application can contain hundreds of third-party packages; unpatched ones are the equivalent of stale plugins.

Step 3: Harden the admin area

The admin login is the most attacked page on any CMS site, hit constantly by bots trying common usernames and leaked passwords. Hardening it removes the easy wins. WordPress and similar CMS checklist

• Rename or replace any account called "admin" and use a non-obvious username.
• Limit login attempts and lock out repeat offenders temporarily.
• Enable two-factor authentication for every user with editor rights or higher.
• Disable file editing from within the admin dashboard so a compromised account cannot rewrite theme code.
• Disable XML-RPC if nothing uses it (many brute-force tools abuse it).
• Restrict which file types can be uploaded, and store uploads outside the executable web root where the platform allows.
• Keep the site's software version numbers out of public view where practical; it is minor, but it removes a signpost for scanners.
• Consider changing the default login URL or restricting admin access to specific IP addresses if your team works from fixed locations.

Custom applications

• Enforce strong password rules and rate-limit login attempts at the application level.
• Use secure session handling: short session lifetimes for admins, secure and HTTP-only cookies, logout on password change.
• Separate the admin interface from the public site where practical, and require two-factor authentication for it.

Step 4: Put a firewall and CDN in front

A web application firewall (WAF) inspects requests before they reach your site and blocks the patterns used by bots, brute-force tools and common injection attacks. Combined with a content delivery network, it also absorbs traffic floods and speeds up delivery to visitors on Nigerian mobile networks. Free tiers from the major CDN providers are adequate for many SME sites; paid tiers add stronger rules, bot management and support, priced in US dollars. Setting it up usually means pointing your domain's DNS to the provider and enabling the proxy. Once active:

• Turn on the managed rule set for your platform (for example, the WordPress rules).
• Enable bot protection on the login page and checkout.
• Set a rate limit on the login URL.
• Hide your server's real IP address so attackers cannot bypass the firewall by going direct.

If a firewall is not possible, a security plugin with a built-in firewall provides a weaker but useful layer at the application level.

Step 5: Secure the hosting and server

Hosting choices decide how much damage a single vulnerability can do. Shared hosting on a reputable provider is fine for brochure sites; stores and applications need either managed hosting or a properly configured VPS.

• Use SFTP or SSH keys, never plain FTP. Plain FTP sends passwords unencrypted.
• Close unused ports and restrict SSH to key-based logins from known addresses.
• Run a supported PHP or runtime version and keep it patched.
• Isolate sites. Do not host five unrelated websites under one hosting account; a breach in one becomes a breach in all.
• Set correct file permissions so the web server cannot write to files it should only read.
• Ask the host in writing about server patching, malware scanning, isolation between customers and how they handle abuse reports.
• Keep a staging environment for testing updates so you are not experimenting on the live site.

Step 6: Protect forms, logins and checkout from bots

Every form on a business website is a target: contact forms for spam, sign-up forms for fake accounts, and checkout for card testing, where fraudsters run stolen card numbers through your store to see which still work. The controls are straightforward.

• Add spam protection to every form: a honeypot field, an invisible CAPTCHA, or both.
• Rate-limit form submissions and account creation per IP address.
• Validate and sanitise every input on the server, never only in the browser.
• Use a hosted checkout from your payment gateway so card details never touch your server, and enable the gateway's fraud rules (velocity checks, blocked BINs, 3D Secure where available).
• Watch for bursts of small failed transactions: that pattern is card testing and your gateway may restrict your account if it continues unnoticed.
• Require email or phone verification for new customer accounts on stores and portals.

Step 7: Monitor so you find out first

Many businesses learn of a hack from a customer, a Google warning or a blocked email; by then it has usually been live for weeks. Monitoring shortens that window from weeks to hours.

• Uptime monitoring with alerts by email or WhatsApp-compatible channels.
• Malware and file-change scanning that alerts when core files are modified.
• Google Search Console verified for the domain: it will report hacked content and security issues Google detects.
• Login alerts for new admin sessions or new user accounts.
• Log review after any suspicious activity; on a VPS, keep access and error logs for at least a month.
• A monitored inbox. Alerts sent to the former developer's email protect nobody.

Step 8: Back up and rehearse the restore

Backups are the last line of defence and the first thing you will need after a successful attack. The minimum is a daily automated backup of files and database, kept off the hosting server, retained for at least 30 days, and restored to a test environment at least once a quarter to prove it works. A backup that only exists on the same server that was hacked is not a backup. The companion guide to website backup solutions covers options and costs in detail.

Signs your website has been hacked

The most reliable early signs are a Google Search Console security warning, unfamiliar pages or foreign-language results appearing for your domain in search, redirects to other sites (often only on mobile), new admin users you did not create, and customers reporting spam or phishing that appears to come from your domain. Slowness, spikes in outbound email and altered files are secondary indicators. Check quickly by searching "site:yourdomain.com.ng" and looking for pages you do not recognise, opening the site from a phone on mobile data (some malware only redirects mobile visitors), and reviewing the user list in the CMS.

What to do in the first 24 hours after a hack

If your website has been hacked, the priority order is: contain, preserve evidence, clean or restore, secure the accounts, then communicate. Rushing to "fix it" by editing files on the live site usually leaves the attacker's backdoor in place.

1. Contain. Put up a maintenance page or take the site offline. Change the hosting-panel and CMS passwords immediately and revoke API keys.
2. Preserve evidence. Take a full copy of the compromised site and server logs before cleaning. You may need it to understand the entry point or to meet NDPC breach-reporting obligations.
3. Identify what was affected. Was customer data accessible? Were payment flows altered? Were emails sent from your domain? This determines your legal and customer obligations.
4. Restore from a known-clean backup where one exists, then apply every update before bringing the site back online. If no clean backup exists, a professional clean-up is safer than manual deletion.
5. Close the entry point. Update or remove the vulnerable plugin, remove the rogue account, fix the hosting setting.
6. Rotate every credential connected to the site, including database passwords, gateway keys and email accounts.
7. Request review in Google Search Console if the site was flagged, and ask your host to lift any suspension.
8. Communicate. If personal data may have been exposed, the NDPA 2023 requires notifying the NDPC within the Act's timeframe (72 hours as enacted) and, in some cases, affected individuals. Confirm current requirements with the NDPC or a qualified adviser. Tell customers plainly through your official channels what happened and what you did.
9. Write it down. Record the timeline, cause and fixes, then schedule the monitoring and maintenance that would have caught it earlier.

What changes for Nigerian businesses

The steps above are universal, but their priority shifts in Nigeria. Account ownership comes first because so many sites were built by a freelancer who registered the domain and hosting in a personal name; recovering control after a dispute is a security incident waiting to happen. Two-factor authentication matters more because admin work is often done from phones and shared laptops. Payment security is simpler than in markets where businesses process cards directly: with Paystack, Flutterwave, Monnify or a similar gateway handling checkout, your main duties are enabling their fraud tools and keeping your dashboard login secure. Firewall, scanning and backup services are mostly billed in US dollars, so budget for exchange-rate movement and use free tiers where they genuinely suffice. Finally, impersonation runs alongside hacking: a fraudster does not need to breach your site if a look-alike WhatsApp account can take transfers in your name, so publish your official numbers and handles and remind customers to check them.

Example (hypothetical): a Port Harcourt hotel's booking site

Example (hypothetical): a 40-room hotel in GRA, Port Harcourt takes reservations through a WordPress site with a booking plugin. The front-desk manager, the marketing officer and the original developer all use one administrator account with the password "Hotel2021!". There is no attempt limit on the login page. A credential-stuffing bot guesses the password. The attacker installs a plugin that redirects mobile visitors to a betting site and edits the booking confirmation email to show a different bank account for deposits. Two guests pay deposits to the wrong account before a third calls to ask why the account name has changed. The response, following the steps above:

• Maintenance page up; hosting and CMS passwords changed; developer asked to export logs.
• Site restored from the host's backup of four days earlier, then every plugin updated and the redirect plugin removed.
• Individual accounts created for the three users with two-factor authentication; the old shared account deleted; login attempts limited.
• A free-tier firewall and CDN placed in front with bot protection on the login page; malware scanning and Search Console alerts set up to the general manager's email.
• Guests contacted through the hotel's official WhatsApp line and Instagram with the correct account details and a warning.

The indicative cost is a day of developer time plus a maintenance plan (₦30,000–₦80,000 per month for a site of this kind). The two mis-directed deposits, the refund conversations and the reputational damage cost far more.

Mistakes to avoid

• Cleaning the live site by hand and calling it fixed. Attackers leave backdoors in places manual clean-ups miss. Restore from a clean backup or use a professional clean-up, then update.
• Changing the CMS password but not the hosting, database and email passwords. Attackers who got in via hosting keep their access.
• Relying on a security plugin as the whole strategy. Plugins help, but they cannot fix neglected updates, shared logins or a compromised host.
• Testing updates on the live site with no backup. A broken update at 4pm on a Friday with no restore point is a self-inflicted outage.
• Leaving alerts going to an inbox nobody reads. Monitoring only works if someone acts on it.
• Keeping the old developer's account "in case we need them". Create a new account when you do; do not leave a standing door.
• Assuming a small business is not worth attacking. Bots do not evaluate your revenue; they exploit whatever responds.

Conclusion

Protecting a business website from hackers is a sequence, not a product: own and secure the controlling accounts, update and prune, harden the admin area, put a firewall in front, secure the hosting, protect forms and checkout from bots, monitor, and keep tested backups. Done once and maintained monthly, these steps close the doors that automated attacks rely on. Keep the first-24-hours plan somewhere your team can find it without you, because the value of a plan is highest on the day nobody expected to need it. If you would rather have these steps done for you, Linestech can harden an existing website, set up monitoring and backups, and provide ongoing maintenance so security updates never depend on someone remembering.

Frequently asked questions

How often should I update my website's plugins and CMS?

Apply security updates as soon as they are released, ideally within days; allow automatic updates for minor releases. Review everything else at least monthly. Larger version upgrades should be tested on a staging copy first. If nobody in the business will do this reliably, a maintenance plan is the practical answer.

Is two-factor authentication really necessary for a small business website?

Yes. Credential theft and password guessing are the most common ways admin accounts are taken over, and two-factor authentication defeats both even when the password has leaked. Authenticator apps are free and take minutes to set up on WordPress and most hosting panels.

Can a hacked website affect my business email?

It can. If the site and email share hosting or credentials, or if the attacker uses the server to send spam, your domain can be blacklisted and legitimate emails to customers and banks may bounce. Keep email on a separate service where possible and treat email accounts as part of the website's control chain.

Should I pay for website malware removal or do it myself?

If you have a clean backup and the technical confidence to restore it, update everything and rotate credentials, you can handle simple cases yourself. If there is no clean backup, customer data may be involved, or the site keeps getting re-infected, hire a professional: the indicative cost of a clean-up (₦100,000–₦1,000,000+) is lower than repeat incidents.

Do I need to report a website hack to anyone in Nigeria?

If personal data was or may have been exposed, the Nigeria Data Protection Act 2023 imposes breach-notification duties to the NDPC and, in some cases, to affected individuals. Payment-related incidents may also need to be reported to your gateway. Confirm the current requirements with the NDPC or a qualified adviser rather than relying on this article.

Will a firewall slow down my website for Nigerian visitors?

Usually the opposite. A CDN with a web application firewall caches content closer to visitors and filters junk traffic before it reaches your server, so pages load faster on mobile networks in Lagos, Abuja or Kano. Configure caching sensibly and test after enabling it.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• Paystack developer documentation
• Flutterwave developer documentation
• MDN Web Docs — web platform reference
• Google Search Central Blog
• PostgreSQL documentation
• Cloudflare Learning Center