How to secure a website — starting from what actually happens

Guides to website security almost all start with the break-in: somebody finds a hole in the code and walks through it. The data for Poland tells a different story. The most common way in is a login that somebody obtained — a password phished, reused or never changed — and that reorders the whole list of tasks.

This article is about access to your website: who has an account, what protects it, and what was opened along the way and never closed. Encryption, updates, backups and the obligations that come with personal data each have their own article in this section; I point to them rather than repeat them.

What companies fear, and what actually happens

Every year CERT Polska, Poland's national CSIRT run by NASK, publishes a report on the incidents it handled. In 2025 it received 658,320 reports and registered 260,783 unique incidents, 152% more than a year earlier (CERT Polska, annual report 2025). Broken down by category, the picture is worth stopping at:

• computer fraud — 253,238 incidents, 97% of all,
• of which phishing (credential theft) — 78,391, 30% of all incidents,
• intrusions — 750, 0.3%,
• intrusion attempts — 139, 0.1%,
• attempts to gain access to mailboxes — 2,519.

The same data shows the mass impersonation behind it: of the marketplace impersonations CERT counted, 28,462 used OLX and 22,513 used Allegro. The EU's cybersecurity agency, ENISA, counts differently — it classifies intrusion vectors, not incident categories — but its Threat Landscape 2025 points the same way, with phishing the largest single route in.

Three conclusions, and each one changes something on the task list.

The break-in you imagine is real, but it is the minority. The picture from the guides — somebody finds a flaw in the code and passes through it into the dashboard — describes about three incidents in a thousand. That is not nothing, and the part of it that concerns a company website is handled by keeping software up to date. But it is not where most of the traffic goes.

The front line runs through the password. Phishing alone is 30% of everything registered in Poland, about a hundred times the number of intrusions: somebody was persuaded to hand over a login, open an attachment or run something they should not. ENISA describes the machinery behind it plainly: phishing-as-a-service platforms that clone login pages of well-known brands, so that people with no skill at all can run a convincing campaign, and kits built specifically to get past a second login factor by sitting between the victim and the real page. These are mass campaigns that you fall into by accident, not because anyone chose you.

An honest caveat belongs next to these numbers, because they do not measure everything. CERT attributes part of the 152% rise to growing awareness and to its own monitoring role, so some of it is more incidents noticed and reported, not necessarily more attacks; the proportion between the categories is what counts. And what reaches CERT leans towards what people notice and report, not towards the quiet breach of a ten-person firm with a WordPress site. For your decision, that changes little: a small company is, if anything, more exposed to the mass campaigns and less likely to be the subject of a carefully engineered exploit.

You are not a target — you are a catch. The distinction is practical, not philosophical. If the attack is not aimed at you, you do not defend against it with sophistication. You defend against it by removing the easy ways in: the account nobody uses, the password reused from another service, the dashboard without a second factor. The rest of this article is about that and only that.

Who has access to your website

The first task is not technical. It is an inventory — and it almost never exists.

Open the list of users in the website's dashboard and, for each account, answer three questions: who is this, do they still use it, and do they need these permissions? Usually several things turn up at once.

The account of the contractor from two agencies ago. It stays behind after every project, because nobody ends a collaboration by removing access. It is an administrator account, with a password you do not know and do not control.

The "admin" or "administrator" account created at installation. Its name is known in advance, so an attacker gets half of the username–password pair for free. The point is not that somebody will guess it; the point is that mass login attempts test exactly those names.

Accounts of people who no longer work for you. This is the same problem as the mailbox, and it is usually solved at the same moment — or not at all.

Everyone as an administrator. The single most common fault we see. The person who adds posts to the blog does not need permission to install plugins or change accounts. The role system exists so that taking over one account does not mean taking over the site.

On top of that come three kinds of access that the dashboard does not show and that give more than an administrator account: the hosting, the database and the domain account. Whoever holds the hosting password can bypass the site entirely. Whoever has access to the domain can send the traffic somewhere else without touching the server. All three belong on the same inventory and are usually the most neglected, because the assumption is that "the contractor has them" — which is a description of the problem, not a solution.

The inventory takes a quarter of an hour. Write it down outside the dashboard — in the same document where you keep who the domain is registered to and who can get into the hosting. When you change contractor, it is the only list that lets you close anything at all.

Three settings that do most of the work

After the inventory come three things. All of them are free, none needs a specialist, and together they close the route by which the large majority of incidents arrive.

A second login factor on the dashboard. It is the one measure that still works when the password has leaked — and with phishing behind about three intrusions in five, you have to assume that one day it will. It takes a few minutes to switch on and matters most on accounts with administrator rights.

It is worth being precise about what it does not do. ENISA describes phishing kits that sit between the user and the genuine login page and pass the second factor through in real time, capturing the session once the user is logged in. A second factor does not make an account untouchable; it removes the easiest route, the one where a password alone is enough. That is exactly what we want from it here.

A unique password for the dashboard. Not "strong" in the sense of special characters, but used nowhere else. Mass attacks do not guess passwords — they replay username–password pairs taken from other services' breaches. A password reused from an online shop that leaked three years ago is, from this point of view, a public password.

Roles instead of an administrator for everyone. Three administrator accounts in a company where one person edits the site is three times the surface for no gain at all.

There is a fourth thing, cheaper than all of the above and almost always skipped: check where the password reset goes. The dashboard sends it to one email address, and that address is sometimes a former employee's mailbox, an alias nobody reads, or an account with no second factor. Taking over that mailbox gives you the dashboard without breaking anything — which is precisely the route the phishing figures describe. Securing the dashboard while the reset mailbox stays open is locking the door and leaving the window open.

What is deliberately not on this list: security plugins, web application firewalls and scanners. Not because they are useless, but because installed before the three settings above they create the feeling of having done something without closing the route people actually use. Here the order matters more than the choice of tool.

Plugins: a surface, not a bogeyman

Updating plugins has its own article, and I will not repeat it here. It is worth, however, looking at plugins as something other than a thing to update — as a surface you decide on yourself.

ENISA's report gives a concrete reason to care. It describes compromised WordPress sites being used to push information-stealing malware at their visitors, through fake "verify you are human" prompts planted on the pages. The site does not go down. It keeps working, and on top of that it becomes part of someone else's attack — and it is your customers who pay for it.

Three questions to ask once a year:

How many are there, actually? A typical company site that nobody has tidied has somewhere between ten and several dozen. Some of them were left behind after testing solutions that were never used — and they are still running.

Which of them is no longer being developed? A plugin with no update in two years is not a stable plugin; it is an abandoned one. The date of the last update is shown in the directory you installed it from.

Where did they come from? A plugin or theme from the official directory has a known chain of origin. A file sent by email, or downloaded from a site that gives away paid themes for free, does not — and that is one of the few situations in which the infection arrives together with the installation.

The cheapest action in this section: delete, do not deactivate. A deactivated plugin still sits on the server and can still be vulnerable.

There is one category worth thinking about separately, because it does not look like a plugin: scripts pasted straight into the template. The pixel from an old campaign, the chat widget, the reviews widget, a counter. They do not appear on the list of plugins, they have no version to check and nobody updates them — yet they run somebody else's code on your site. When you tidy up, look at them with the same eye, and ask whether they still serve any purpose; usually half of them belong to projects that ended long ago.

How to tell that something has happened

The split on this figure matters more than the signs themselves. What you can notice yourself requires opening the dashboard. What the world notices arrives on its own — but after the fact, and usually together with a loss of trust, because the first person to see the browser warning is a customer.

One of them deserves a sentence of its own, because for months it can be the only symptom: pages nobody wrote are often invisible to the logged-in owner and visible to the search engine. It is the classic hacked-website scenario: a company site starts showing someone else's content for search terms that have nothing to do with its business, and you find out from a message in the search engine's console or from falling rankings.

So the cheapest control habit is not buying a tool: once a quarter, check in the search engine how many pages your site has. If the number does not match what you know, you have your answer.

The second habit from the same shelf: connect the site to Google Search Console and check that its notifications go to an address someone reads. It is the only channel through which the search engine tells you it has flagged a site as dangerous, in its report on security issues — and it most often lands in a mailbox created at launch that nobody has opened since. Cost: five minutes. Difference: you learn about it the day the flag goes up, not a month later from a customer's question.

What it costs, and who does it

The question that follows the sections above is always the same: "how much do we have to spend on this?" The honest answer is uncomfortable for anyone selling security: the most effective part of this list is free, and it cannot be bought.

The account inventory, the second factor, the unique password, removing abandoned plugins, checking the reset address — that is one evening's work for a person with access to the dashboard, and it costs nothing. No tool will do it for you, because no tool knows who still works at your company.

You pay for three things, and it is worth knowing which:

For the time of somebody who reviews it instead of you. Justified if nobody in the company opens the dashboard except to add a post.

For monitoring and an alert. Sensible for a site that earns money — because the difference between "I find out within the hour" and "I find out from a customer a week later" can then be put into numbers.

For being ready to restore. That is really an item from backups, not from security, and it is described there.

What is not worth buying at this stage: "premium security" packages bolted onto the hosting when nobody knows what exactly they cover. There is one control question, and it settles the matter in a sentence: will this service alert a named person, or will it only generate a report in a panel nobody opens?

When the site is already infected

The order matters here, and it is not the one instinct suggests. "Remove the virus" is step four, not step one — because cleaning up an infection without closing the way in ends with a second infection within a week.

1. Change the passwords and cut off access. Dashboard, hosting, database, FTP accounts, and the mailbox that receives the password resets. Remove any accounts you do not recognise while you are there. If there was a second factor, check that it is still tied to your device.

2. Preserve a copy of the current state. Yes, the infected one. You will need it to establish what happened and when — and restoring a "clean" copy without taking it first erases the only trace.

3. Establish when it started. File modification dates and the hosting logs are enough to point to a day. That decides which copy you can restore — yesterday's is sometimes already infected.

4. Only now, clean up or restore. On a typical company website, restoring a copy from before the date in step three is faster and more certain than hunting down the changes one by one.

5. Report it if personal data was affected. This is a separate obligation, independent of the technical repair. Under the GDPR, a personal data breach has to be notified to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it (Article 33), unless it is unlikely to result in a risk to the people concerned. We cover what that involves in the article on the GDPR and your privacy notice.

6. Ask for a review. The browser warning and the search engine's flag do not disappear on their own — you have to submit the site for a new check, and that takes at least a few days.

One step falls between the fourth and the fifth and is often skipped: working out how they got in. If you do not know, the only thing you know for certain is that the route is still open.

The free checks that almost nobody uses

There is one in Poland. CERT Polska runs Artemis, a system in use since 2023 that scans websites and other systems for vulnerabilities and configuration errors. It was built mainly for public bodies, but since 2024 anyone can order a check of their own domains and networks through moje.cert.pl; the results go to the administrator and are not published. It is free, state-run, and applying takes a few minutes. Like everything below, it will not check accounts, passwords or a former contractor's admin rights.

Three more free things sit alongside it, and the first is not the one people expect.

Somebody may try to tell you. When a site is compromised and starts sending spam or serving malware, reports about it reach the hosting provider and the contact address registered for the domain. Security researchers and incident response teams send them there as a matter of routine. The message only helps if it arrives somewhere: check which address is listed as the technical contact with your domain registrar and your hosting provider, and which one appears in the site's legal notice. If it is the mailbox of a former contractor, the warning will end up in a folder nobody opens.

Google Search Console, mentioned above, in its report on security issues: this is where the search engine tells you that a site has been hacked or is being used to distribute malware.

The site's status in Google Safe Browsing, which anyone can look up in Google's Transparency Report: enter your address and you will see whether the site is currently flagged as dangerous — it is that list that triggers the full-screen warning in browsers.

It is worth being honest about what these checks do not do: they do not look at who has an account in the dashboard, they do not assess passwords, and they will not notice the former contractor who is still an administrator. They do not replace the first two sections of this article — they add to them from the side you cannot see from the dashboard.

Four sentences we hear most often

Each one sounds reasonable, and each one leads to putting off the one thing that needs doing.

"We are too small for anyone to be interested in us." True and irrelevant at the same time. The phishing campaigns that make up most of the intrusions do not pick targets — they replay credentials from breaches and test well-known account names on everything that answers. Being small is no protection, because nobody checks the size of a company before trying to log in.

"We have a certificate, so the site is secure." A certificate encrypts the connection between the browser and the server. It has nothing to do with who knows the dashboard password — and that is where the front line runs. The padlock speaks about the transport, not about the contents; we go into this under SSL certificates.

"The hosting takes care of that." The hosting provider is responsible for its own layer and usually does that well. It is not responsible for the accounts in your dashboard, for abandoned plugins, or for the person you gave access to three years ago. The boundary is sharp, and it is worth knowing before an incident rather than during one.

"We will do it at the next redesign." The most expensive of the four, because the list in this article has nothing to do with a redesign — these are settings, not a project. Putting them off until the next big job usually means two years of open access in exchange for nothing.

What the four have in common: each of them shifts responsibility onto something external — the size of the company, the certificate, the supplier, the calendar. The list that actually works is entirely internal, and that is why it is often the hardest to start.

What this article deliberately leaves out

Five subjects, each because it has its own article in this section or its own audience.

• Encrypting the connection and certificates — SSL certificates, including the deadlines that fall regardless of your plans.
• Software updates — separately, including what happens after support ends; this is where the 0.3% of intrusions lives.
• Backups — separately, with the question of who last restored one, not whether copies exist.
• Obligations towards personal data — the GDPR and the privacy notice on your site.
• The company layer — email, devices, phishing aimed at staff, password managers. That is company data security, not website security, and it runs on different habits.

The shortest summary: start with the list of accounts, not with a security plugin. The data says people come in where it is open, not where they would have to make an effort — and the list of accounts is the one thing in this article that nobody will do for you.