Website security: why custom is often safer than plugin-dependent sites

Security is not a topic you raise only once something goes wrong. For an SME, a hacked website can cost days of revenue, customer trust and sometimes sensitive data. In this article we explain calmly and without scaremongering how breaches happen in practice, what the term attack surface means, and why a custom website usually keeps that surface smaller than a site that leans on many plugins. WordPress is not "bad" here: we explain in a balanced way where the real risk lies.

Why security matters for an SME

Many owners believe they are "too small" to interest hackers. That is a misconception. Most attacks are not targeted; they are automated scripts scanning the entire internet for known vulnerabilities. Your site does not need to be famous to be hit: it only needs to be vulnerable.

The consequences are concrete: a site that goes offline, sends spam from your domain, displays unwanted content or leaks customer data. On top of the direct damage there is reputational harm and, with data breaches, a possible reporting obligation. We describe the broader financial impact in the hidden costs of bad web development.

How most breaches actually happen

In films, hacking looks like a brilliant breakthrough. Reality is far duller: the vast majority of breaches abuse known, already-fixed flaws in software the owner failed to update in time. The four most common causes:

• Outdated plugins and themes: a known hole, patched months ago, that was never installed.
• Weak configuration: default settings, exposed admin pages or overly broad permissions.
• Updating too late: the patch exists, but is applied only weeks later.
• Weak authentication: simple passwords without extra verification.

The striking part: this is rarely about an ingenious attacker and almost always about maintenance left undone. Security is therefore largely a matter of discipline, not luck.

A useful frame for understanding this is the difference between targeted and opportunistic attacks. A targeted attack aims at one specific victim and requires time and motivation. An opportunistic attack is the opposite: an automated scanner tests millions of addresses for the same known weakness and strikes wherever it happens to be open. Most SME sites are hit by the second type. That is why "we are too small" offers no protection: the attacker does not even know who you are before getting in.

A concrete example of a typical breach

Picture a local construction firm with a tidy WordPress site and a contact-form plugin installed neatly two years ago. The maker has since released a security update for a flaw that allowed files to be uploaded. The owner saw the update notice but postponed it, afraid the form might break just before a busy period. A few weeks later an automated scanner found the outdated plugin, planted a hidden script and began sending spam from the domain. The result: the mail server landed on a blacklist, legitimate quotes stopped arriving, and recovery cost more than a year of maintenance would have. No genius, no targeted plot, just a deferred update. This pattern repeats every single day.

The attack surface, explained simply

The concept that ties it all together is the attack surface. Picture a house. Every door, window and cellar hatch is a possible entry for a burglar. The more openings, the more places you must lock, check and maintain. The attack surface is the sum of all those possible entries.

In software, every piece of code, every plugin and every external dependency is a potential opening. You can guard one door well. Fifty doors, supplied by thirty different makers each with their own locks and update schedules, are far harder to keep secure. Security is therefore essentially about keeping that surface small.

Every line of code you do not have is a line that cannot be vulnerable. The safest component is the one that is not there.

WordPress is fine — but the plugin ecosystem enlarges the surface

Let us be fair: WordPress is solid software that helped build the modern web, and well-managed WordPress sites can be secure. The problem is not WordPress itself, but the way it is typically used.

A typical WordPress site combines a core with a theme and quickly ten to thirty plugins from as many different authors. Each plugin is third-party software you trust, that has access to your site and that you must keep updated separately. In practice:

• A large share of vulnerabilities originate in plugins, not the core.
• Owners often update too late, or avoid updating for fear of breaking something.
• Plugins can conflict with one another, delaying updates and leaving gaps open.
• Too many plugins also hurt performance, separate from security.
• An abandoned plugin that is no longer maintained becomes a permanent risk.

The risk grows with the number of external dependencies. Not because plugins are "wrong", but because each extra component enlarges your attack surface and increases your maintenance burden. A deeper comparison is in WordPress versus custom.

How custom development reduces the attack surface

With custom development we write exactly the functionality your business needs, no more. That has direct security consequences:

Only the code you need

No dozens of plugins for features you barely use. Less code means fewer potential flaws and less to maintain.

No unknown third parties

You do not depend on the update schedule, priorities or survival of thirty external makers. The code is yours and we know it.

Secure defaults built in

Input validation, correct permissions and safe configuration are designed in from the first line, not bolted on afterwards.

Predictable maintenance

One coherent codebase is easier to monitor than a patchwork of separate parts. That means we can and dare to update on time, which removes the very cause of most breaches.

An important caveat: custom is not a free pass. Custom code can contain flaws too, and a poorly built custom site is no safer than a well-maintained WordPress site. The advantage is not a magic formula but control: we know exactly what is running, why it is there and how to update it. That control then has to be used with discipline.

Secure development in practice

Security is not a switch you flip afterwards; it emerges from how code is written. The principles below are standard in our design, and they are worth knowing when you evaluate any developer.

Input validation and output escaping

Most classic web attacks, think SQL injection and cross-site scripting, arise when user input is trusted directly. The fix is consistent: validate everything that comes in and encode everything that goes out. A search box, a contact form or a URL parameter should never reach a database query or the page unfiltered. With parameterised queries and automatic escaping you rule out an entire class of attacks before it can exist.

Dependency management

Custom code uses external libraries too; the difference is how many and how deliberately. We keep the list short, choose widely maintained packages and scan them automatically for known vulnerabilities. Every dependency we add is a conscious choice with a maintenance obligation, not something that arrives unnoticed bundled inside a plugin.

Least privilege everywhere

Each component gets only the rights it strictly needs. The website’s database user cannot drop tables it never touches, admin accounts are limited in number, and API keys have the smallest possible scope. If one component is compromised, the damage stays contained.

Secure default configuration

Admin pages are not reachable from the open internet, error messages leak no technical detail, and security headers (such as a content-security-policy) are set correctly. Many breaches begin not in the code itself but in a forgotten default setting.

Attack surface: plugin-heavy site versus custom

The table below makes the difference concrete.

Aspect	Plugin-heavy site	Custom site
External dependencies	10 to 30+ plugins	Kept to a minimum
Source of vulnerabilities	Often in third-party plugins	One managed codebase
Update responsibility	Spread across many makers	One party
Risk of conflicts	High	Low
Unused features	Often present	Not present
Attack surface size	Large	Small
Impact on performance	Often negative	Optimised

Update discipline and the role of maintenance

Even the best custom work is still software, and software needs maintenance. The difference lies in how feasible that maintenance is. A small, coherent codebase updates smoothly and without fear; a tangle of plugins does not.

That is why security is inseparable from maintenance and monitoring. Active supervision spots anomalies early, and timely updates close gaps before they are abused. We bundle this in a maintenance package from €150 a year, including security checks: the full breakdown is in hosting for websites: what you pay and why.

Why hosting and maintenance belong together

Security does not stop at the code. The environment your site runs on shapes how secure it is. A good hosting environment keeps server software current, provides automatic TLS certificates, isolates accounts and runs a firewall that blocks malicious traffic. When hosting, monitoring and updates sit with one party, there is no no-man’s-land where nobody feels responsible, a common cause of neglected maintenance. In our package, hosting, monitoring, updates, tested backups, technical maintenance and periodic security checks deliberately belong together.

Backups you can actually restore

A backup you have never restored is a promise, not a guarantee. We keep versions from multiple points in time, separate from the production server, so a hacked or blocked site does not mean a hostage backup. Just as important: we test restores periodically, so you do not discover in a crisis that the file is unusable. A tested backup turns a potential disaster into an annoying hour of work.

What to do if you suspect a breach

If you suspect your site has been hacked, with unknown admin accounts, strange redirects, warnings from Google or complaints about spam, every step counts, in the right order. Panic reactions often make things worse. Follow these steps.

1. Preserve evidence before deleting anything: take a copy of the site and the logs. Wiping everything immediately destroys the information needed to find the hole and prevent a repeat.
2. Limit the damage: put the site into maintenance mode or take it offline temporarily, so visitors are not infected and the attacker cannot act further.
3. Change all credentials: admin, hosting, database, FTP and email passwords. Assume that anything the site could see has leaked.
4. Find the entry point: an outdated plugin, a flaw in a dependency or a stolen password. Restoring without knowing the cause guarantees a second breach.
5. Restore from a clean backup: preferably from before the infection, then apply the necessary updates so the same hole is not immediately open again.
6. Check for leftovers: hidden admin accounts, planted files or scheduled tasks the attacker left to return later.
7. Assess your reporting duty: if personal data is involved, a notification to the supervisory authority may be required within a short window. Do not delay this.

This overview is deliberately sober: in practice, a solid, tested backup together with monitoring is the difference between a brief interruption and an expensive crisis. If you would rather not face this alone, we take this process off your hands.

A practical security checklist

Whether your site is custom or platform-based, this baseline should always be in order:

1. HTTPS/TLS: encrypt all traffic with a valid certificate. No exceptions.
2. Timely updates: apply patches quickly; most breaches abuse known, fixed holes.
3. Tested backups: regular, automatic and tested for restore.
4. Least-privilege access: give every user and component only what it strictly needs.
5. A firewall (WAF): filter malicious traffic before it reaches your site.
6. Strong authentication: solid passwords and two-factor verification for admin access.
7. Reduced attack surface: remove unused plugins, accounts and features.
8. Monitoring: know when something deviates, ideally before the visitor notices.

What WKD Solutions does

For us, security starts at design: we build only what is needed, with secure defaults baked in and without unnecessary external dependencies. After launch we keep the site secure with monitoring, timely updates, tested backups and periodic security checks through our maintenance package.

Unsure whether your current site is well secured? We are happy to run a website audit and review your attack surface, your update status and your backup strategy. More on our approach is on our services page.

Conclusion

Most breaches are not a masterpiece of hacking but the result of outdated components and deferred maintenance. The larger your attack surface, think many plugins from many makers, the harder it is to keep that surface secure. WordPress is not bad, but the plugin model enlarges that surface. Custom development inverts the logic: only the code you need, one managed codebase and predictable maintenance. Combined with monitoring and a solid checklist, that delivers a demonstrably safer site.

Want to know exactly where your website stands? Request a no-obligation security audit and we will map your risks together.