# Security and monitoring — smaller attack surface, faster detection

URL: https://rootcr.com/security-and-monitoring/
Updated: 2026-08-23

# Security and monitoring: smaller attack surface, faster detection

> **In short:** The vast majority of websites are not hit by a targeted attack but by an automated bot trying a single known plugin flaw across millions of sites. In 2025, 11,334 new vulnerabilities were reported in the WordPress ecosystem, and 91% of them were in plugins — not in the core. On a hand-coded site that layer simply is not there: there is nothing to try. Beyond that, the server the sites run on is watched by a purpose-built monitoring system with language model support: port patrol every five minutes, decoy files, a full system check every two hours, immediate alerting. Baseline protection is included in every project at no extra cost; continuous monitoring can be ordered separately.

## Why is a hand-coded site a harder target?

Because attacking is a business, and business needs scale. An attacker is not looking for your company: they look for a flaw in a plugin used by a few hundred thousand sites, write a script for it, and run it across the internet. The return comes from the number of installations, not from your traffic.

So the risk does not depend on how "interesting" you are, but on **how much foreign code surface you run**. The numbers show it:

| What is measured | Value | Source |
|---|---|---|
| New vulnerabilities in the WordPress ecosystem, 2025 | 11,334 (+42% in one year) | Patchstack, State of WordPress Security in 2026 |
| Of those, in plugins | 91% | same |
| Of those, in themes | 9% | same |
| In the core | negligible, a handful | same |
| Severe flaws attacked within 24 hours | 45% (median time to first exploitation: ~5 hours) | same |
| What typical hosting and WAF protection actually blocked | 12% of known WordPress attacks | same |

The lesson is not that WordPress is bad. The lesson is that **the overwhelming majority of vulnerabilities come from the add-ons bolted onto it**, and the protection usually bought alongside catches a fraction of the attacks. If the plugin layer is not there, that entire class of attack drops out.

On a custom site, the code that runs is the code I wrote and can explain line by line. There are no thirty foreign packages updating themselves, and no feature whose background behaviour I do not know.

## Why is a web store a prime target?

Because money moves there, and that is where the most identical installations are. WooCommerce accounts for roughly **93.7%** of WordPress-based stores — meaning a single working attack applies to millions of shops at once. This is why card-skimming campaigns have targeted the same two systems for years: WooCommerce and Magento, because that is where the active stores are.

These attacks do not take the site down. Quite the opposite: the store keeps working, there is just an extra script running on the payment page that sends the card details away. Such an infection stays unnoticed for months — it is not the visitor who spots it, it is the bank.

In a custom store, payment happens on the payment provider's own interface or through a server-side call, the card data never passes through my code, and there is no plugin surface to plant a foreign script into. On top of that, the Content-Security-Policy blocks any script from a foreign source at browser level.

## What is built into every project, at no extra cost?

**A minimised attack surface.** No third-party plugin layer on the server. The public web root contains only what has to be visible; the source, the service code and the secrets live outside it.

**Protected forms.** Origin check, hidden honeypot field, size limit, human verification and IP-based rate limiting — server-side code, in a specific order. A live example and the reasoning behind the order: [pekarunagyker.hu case study](/case-studies/pekarunagyker/).

**File upload with real verification.** The system determines the type of an uploaded file from its content, not from the filename extension; it looks for macros and executable content, then runs a virus check. Live example: [bucipek.hu case study](/case-studies/bucipek/).

**Browser-level security headers.** Content-Security-Policy, `X-Frame-Options: DENY` against clickjacking, `nosniff`, a strict referrer policy, camera/microphone/geolocation access switched off, and HSTS with the `preload` list — meaning the browser never even tries to connect unencrypted. You do not have to take this on trust: open the network tab of your developer tools on this page.

**Privilege separation on the server.** The quote request service runs as its own ephemeral user, with read-only system files, a locked-away `/home` directory, stripped of every capability, with its own memory limit. If anything happened to it, it could not step outside its own box.

**Secrets outside the code.** The SMTP password, the API keys and other sensitive data live in an environment file with restricted permissions. There is no password in the source code — never, under any circumstances.

**Daily backups, with restoration proven.** The backup runs daily, encrypted and versioned. A backup is only a backup if you can restore from it: I do not assume this, I periodically restore a file for real and check that it is identical.

**A closed firewall.** By default every inbound connection is denied; only explicitly permitted services are reachable from outside.

## Continuous monitoring: a purpose-built watch system

I do not buy server monitoring off the shelf. I wrote my own system for it, which interprets the state of the machine with a language model and speaks up immediately when something deviates from the usual. This is running right now, continuously:

| What it watches | How often | What it does when something is wrong |
|---|---|---|
| Externally reachable ports, against a declared allowlist | every 5 minutes | Alerts, and **keeps repeating while the port is open** — it does not forget |
| Full system state: load, memory, disk, services, logins, firewall | every 2 hours | Alerts with the specific deviation and the suggested command |
| Canary files: decoys that look like password files | continuously, on filesystem events | If anyone touches or opens one: **immediate alert**, because there is no legitimate reason to |
| Availability of watched sites and the state of the backend service | every minute | Alerts with the error code if the site does not answer or the backend crashed |
| Certificate expiry | on schedule | Alerts well before expiry |
| New, unknown processes and port openings against the baseline | continuously | Alerts, and the system names the process that opened it |

The alert does not land in a dashboard nobody looks at: **it goes straight to my phone**, and the system can be asked about the state of the machine in plain language. Logging runs with rotation, the system has an emergency stop, and it reports on its own operation too.

On top of that, every site I build runs its own project-level check: on rootcr.com, for example, I verify every ten minutes that the quote request notification actually went out — if it did not, an alert arrives, rather than the missing reply from a prospect revealing it.

<div class="tldr"><strong>The baseline is included, monitoring is available separately.</strong> The protection layer above is standard equipment in every project, at no extra cost. Continuous, alert-driven monitoring — including adding your site to the per-minute availability check and a monthly status report — can be ordered as a standalone service, priced to the size of the site and the system. <a href="/#contact">Request a quote for it</a>.</div>

## What I do not promise

There is no unbreakable system, and anyone who promises one either does not understand it or is not telling you what they are selling. Three things can be seriously committed to, and I commit to them:

1. **A small attack surface.** What is not installed cannot be broken into.
2. **Fast detection.** The size of the damage usually depends not on whether they got in, but on how long they were inside unnoticed.
3. **Restorability.** Daily encrypted backups that the system genuinely comes back from — because it has been tried.

## Frequently asked questions

### Does this mean a custom site cannot be hacked?

No. It means the automated mass attacks — which make up the vast majority of attacks — find no grip on it, because it does not carry the plugin layer they are looking for. Against a targeted, manual attack, what protects you is the small surface, strict privileges, fast detection and a working backup.

### Will you monitor my existing WordPress site?

Monitoring on its own can be done for it, but let us be honest: watching does not repair the system, it only speaks up earlier. If the site is being kept alive with plugins, the first thing to look at is how much of it is patching and how much is rebuilding — a separate article on that: [taking over an abandoned website](/guides/taking-over-an-abandoned-website/).

### What does monitoring cost?

The fee depends on the size of the monitored system (how many sites, how many services, whether a monthly report is needed), so it goes by quote. What I can state as fixed: the protection built into the project — form protection, file verification, security headers, privilege separation, backups — is not a separate item, it is included in the [prices](/pricing/).

### What happens if something does go wrong?

First I close the way in, then I restore the service — not the other way round, because a restored system would be reinfected immediately through the same hole. Then comes the log review: when, from where, what they reached. At the end, a written summary, including what made it possible.

### Where do you store the backups?

Encrypted, separated from the running system, versioned — so older states are available too, not just yesterday's. Restoration is proven to work: not in theory, but tried.

### How much does security add to the project?

Nothing. What is listed here is part of the build, not an option. In a template system you would have to buy and maintain plugins for the same thing — there it shows up as a monthly fee, and as shown above it catches a fraction of the attacks.