The common attacks on websites

Who attacks a small website

Over the last three and a half days, the log of this very site recorded 950 requests that were not trying to read a page at all. They came from 107 distinct addresses and they all had one shape: try a path, take the 404, move to the next path. In the same window 659,375 requests reached this server, so those 950 are a fraction of one percent. But the number never drops to zero.

Nobody sat down and chose this site. Most of those requests come from cloud provider address ranges rather than from somebody home computer: you rent a machine, hand it a list of domains, and walk away. Trying one address costs approximately nothing, so there is no such thing as being too small to be worth the trouble.

How those 950 requests break down is itself the lesson.

The most interesting group is not the one hunting for a vulnerability. It is the one hunting for somebody else backdoor. Names like alfa.php and up.php and db.php are files that previous attackers leave behind on sites they have already broken into, and the scanner is checking whether this site is already compromised so it can use work someone else has done. 254 requests from 44 addresses, for that one question.

The next group is just as telling. 259 requests were looking for a configuration file, under 49 different names for one file: .env, .env.backup, .env.old, and so on down the list. Whoever wrote that list knows developers leave a backup of their settings next to the original, and that this file holds the database password and the service keys. There is no attack here; only a good guess about human habits.

So being small is not a defence. Your site is not a target, it is a line in a list, and the scanner neither knows nor cares what you sell.

Password guessing, the attack that needs no vulnerability at all

The simplest attack is the one that needs no vulnerability at all. The attacker just knocks on the front door and tries passwords until one answers. It is called a brute force attack, and in practice it comes in two shapes.

The first shape is the one everybody pictures: trying common passwords against the username admin. The second is more dangerous and is called credential stuffing. The attacker takes email and password pairs from earlier breaches and tries those on your site. Nothing is being guessed here: if your administrator still uses the password they made on a forum three years ago, the attack succeeds on the first try.

On this very site, the security plugin has recorded 210 brute force events since March 2025 and has locked out an address 22 times. The current settings: five failed attempts from one address, or ten against one username, inside a five minute window, then a fifteen minute lockout and a seven day blacklist if it repeats.

In the same three day window, login attempts were the most widely spread group: 127 requests, but from 49 distinct addresses. For comparison, the 233 server information probes came from only 10 addresses. The reason is plain; guessing a password is cheap enough that everybody does it.

The standard defence has two layers and everyone knows the first one: rate limiting. It takes the attack from thousands of tries a minute down to a few tries a quarter of an hour, and at that rate guessing a real password moves out of reach.

And this is where it usually goes wrong. Rate limiting does not make a weak password strong; it only buys time. If your password is in the leaked lists, the attacker does not need thousands of tries, they need one, and rate limiting has nothing to say about one try. The second layer, the one that actually closes the problem, is two factor authentication: something the attacker does not have even with the right password.

When what a user typed turns into an instruction

SQL injection and cross site scripting sit on separate lines in every list, but they share one root. Text a user typed reaches somewhere that reads it as an instruction instead of as data.

With SQL injection that somewhere is the database. The program builds a query and pastes the form value into the text of that query; if the value itself looks like part of a query, the database draws no distinction and runs it. The result is rows being read that were never meant to be seen.

With cross site scripting that somewhere is another visitor browser. Text a user wrote in a comment or a profile field is printed unchanged inside the HTML of a page; if that text looks like code, the browser treats it as code, because it has no other way to tell. The code runs in the victim browser with exactly the permissions that person has.

The defence for both has the same logic and sits in two different places.

For the database, the answer is the parameterised query: the shape of the query is sent separately from the values, so a value can never become a keyword no matter what it contains. In WordPress that is what prepare does. For the browser, the answer is escaping on output: any value that came from a user is made harmless at the moment it is printed, in a way that fits where it lands. WordPress has a function for each position; one for plain text, one for an attribute, one for a URL, and one for text that has to keep a little HTML.

And now the part that gets written down least and breaks most: the temptation to clean the input once, on the way in, and stop worrying. It feels safer and it is worse, because whether an escape is correct depends on the destination, not on the origin. A value prepared for HTML turns out wrong the day it goes into an attribute, a URL or a JSON response, and sometimes opens a fresh hole right there. The rule that survives contact with real code is this: store the data as it arrived, and prepare it at the moment of printing, for the exact place it is printed into.

This section is written for whoever writes the code. If you own a site and write none, your share of these two attacks arrives through the plugins you install, which is what the last section of this lesson is about.

Knocking a site over, and the thing that looks exactly like it

A denial of service attack has a simple logic: send enough requests that the real ones cannot get through. It comes in two shapes and their defences are not the same.

The volumetric shape fills the pipe: millions of meaningless requests from thousands of machines. Your server never gets a chance to think, so the defence has to stand in front of the server, at the network edge, where the capacity to absorb is larger than the capacity to attack. That is exactly what a CDN does.

The second shape is cleverer: few requests, each of them expensive. A search page that reads the database on every hit can put a server on the floor with a few hundred requests a minute while the bandwidth stays untouched. The defence there is not bandwidth, it is caching; a request answered from a ready made file costs approximately nothing.

And now the most honest thing that can be said about this. The largest flood of traffic this server has ever seen was not an attack.

On 8 August 2026 two crawlers, GPTBot and meta-externalagent, walked into a loop that the login and register pages of this site had built themselves: every link put the address of the current page inside a return parameter, and that address then went inside the next parameter in turn. The tree never terminated. By the time it was stopped, 10 GB of logs had been written and the disk had reached 96 percent.

The fix was one rule in the web server configuration that recognises the signature of the problem. A healthy return parameter is encoded exactly once, so an encoded percent sign never appears inside it; if one does appear, that address can only have come from inside the loop. Such a request is closed with no response at all and PHP never runs.

A month later the same pattern still arrives. In the three day window this lesson takes its numbers from, 564,365 requests out of 659,375, which is 85.6 percent of everything that reached this server, were closed before they got to PHP.

Our position: what separates that story from a real attack is intent, not effect. A server going down under load does not care whether the load came from malice or from carelessness, and the defence for both is the same. Which is why most of the attacks a site owner reports turn out, once you open the log, to be a badly behaved crawler.

When the front page changes, where did the attack actually happen

When the front page of a site changes and a stranger message appears on it, what you are looking at is not the attack. It is the result of an attack that already succeeded.

Whoever changed that page already had permission to write. Either they had the administrator password, or they uploaded a file through a vulnerable plugin, or they used an account with more access than it needed. Defacement is simply the loudest sign anyone could leave, and as it happens the kindest: an attack that is after money never announces itself.

Which is what makes restoring a backup, on its own, the wrong move. The backup brings the site back and does not close the way in. A site that is restored without the entry point being found usually sees the same thing again within days, and this time the owner concludes the backup was faulty.

The right order has three steps. First keep a copy of the compromised state, because that is the thing that shows how they got in and it disappears the moment you restore. Then restore the backup. And before you open the site again, change every password and key that lived in that copy; they are not yours any more.

The signs that show up before a front page changes are collected in a separate piece on this site: seven signs that a website is at risk.

Which of these five actually applies to you

These five attacks do not apply to you equally, and nobody says so plainly because the complete list looks more professional.

If you run a WordPress site and write no code, the real order of risk is this: a plugin that has not been updated, then a password that is also used somewhere else, then everything else. SQL injection and cross site scripting are a first order problem for whoever writes the code; they reach you through code other people wrote and you installed. Which means your most important security decision does not look like a security decision at all: which plugin you install, and whether it is still maintained.

The OWASP list says the same thing. In its 2025 edition, broken access control is first, security misconfiguration is second, and third is the entry that means something direct to a WordPress owner: software supply chain failures. Your supply chain is your plugin list. Injection moved from third place in 2021 to fifth in 2025, which means it got smaller, not that it went away.

The thing that changes the most from today is the next lesson in the security track: the real order in which a WordPress site gets hardened. And if you have a site and do not know what state it is in, that review and hardening is what we do for clients under website security.