Website Security Checklist for Businesses: What Actually Gets Exploited

Part of our guide hub: Web development

Small businesses tend to assume nobody would bother attacking them. That is broadly true, and completely beside the point. Almost nothing is targeted personally. Automated scanners sweep the entire internet looking for a short list of known weaknesses, and anything matching gets compromised regardless of who owns it.

Here is that list, and what to do about it.

What actually gets exploited

1. Outdated plugins and themes

The single largest cause of compromised sites in Pakistan by a wide margin. A vulnerability is published, scanners start looking for it within days, and every unpatched site is found.

What to do: update within a week of release. Delete deactivated plugins entirely, because an inactive plugin with a vulnerable file is still reachable. Fewer plugins is itself a security measure.

2. Weak and reused administrator passwords

Credential stuffing takes lists leaked from other breaches and tries them everywhere. If your site administrator reuses a password from any service that has ever been breached, you are already exposed.

What to do: unique long passwords from a password manager, two factor authentication on every administrator account, and no shared logins. Remove the default admin username.

3. Unrestricted login pages

Brute force attempts against login pages run constantly. Most sites have no limit on how many times someone can guess.

What to do: rate limit login attempts, lock out after repeated failures, and add a CAPTCHA on the login form. Changing the login URL adds a little friction but is not a substitute for the rest.

4. File upload handling

Any form that accepts a file is a potential route to running code on your server. The classic failure is validating only the file extension.

What to do: validate the actual file type, not the name. Rename uploads. Store them outside the web root or in object storage. Never allow executable extensions.

5. Injection through unvalidated input

SQL injection and cross site scripting remain common in custom built applications, particularly older ones written without a framework.

What to do: parameterised queries everywhere, without exception. Escape output by context. Modern frameworks do most of this correctly by default, which is one of the strongest arguments for using one.

6. Exposed configuration and backups

Scanners specifically look for backup files, environment files and database dumps left in the web root. Finding one hands over every credential at once.

What to do: nothing sensitive inside the public directory. No .env, no database dumps, no zip archives of the site. Check today; this one is common and immediately serious.

The checklist, in priority order

This week

• Update core, plugins and themes. Delete anything deactivated.
• Two factor authentication on every administrator account.
• Remove administrator accounts belonging to people who have left, and any old developer accounts.
• Confirm HTTPS is enforced and HTTP redirects to it.
• Check that automatic backups exist, are stored somewhere other than the same server, and can actually be restored.
• Look in your web root for stray backup or configuration files and remove them.

This month

• Rate limiting on login and on any public form.
• A web application firewall, which most decent hosts and CDNs offer.
• Least privilege on user roles. Content editors do not need administrator rights.
• Database user limited to what the application actually needs.
• Security headers: content security policy, strict transport security, and the frame and content type protections.
• Turn off directory listing.

Ongoing

• Monthly update routine with a named owner.
• Quarterly review of who has access to what.
• Monitoring that tells you when files change unexpectedly.
• Annual review if you handle payments or personal data.

If you take payments or hold personal data

The bar is higher and the consequences are larger.

• Never store raw card numbers. Use a hosted checkout so card data never reaches your server. See our note on payment gateway integration.
• Encrypt sensitive personal data at rest.
• Keep an audit log of who accessed what.
• Have a written plan for what you do in the first twenty four hours after a breach, before you need it.

If you have already been compromised

1. Take the site offline or put it behind a maintenance page. Stop the damage spreading.
2. Change every credential. Hosting, database, administrator accounts, API keys, email. Assume all of them are known.
3. Restore from a backup taken before the compromise, not the most recent one.
4. Find the entry point before going live again, or you will be compromised again within days.
5. Check Search Console for a security notice, and request a review once clean.
6. Tell affected users if personal data was involved. It is the right thing and it limits the damage.

Frequently asked questions

Is WordPress insecure?

WordPress core is actively maintained and reasonably secure. Nearly all compromises trace to outdated plugins, weak passwords or poor hosting. Fewer plugins and disciplined updates remove most of the risk. See WordPress versus custom.

Do I need a security plugin?

One reputable plugin covering firewall, login limiting and file monitoring is worth having. Several overlapping ones cause conflicts and slow the site down.

How much does a security review cost?

A basic hardening review for a business site is typically 50,000 to 150,000 PKR. A full penetration test on a custom application starts considerably higher and is worth it if you handle payments or personal data at scale.

My host says they handle security. Is that enough?

Hosts secure the server. They do not update your plugins, manage your passwords or review your code. That half is yours.

Ezitech builds and maintains platforms for clients in regulated industries across 42 countries. Ask us for a security review of what you are running.