Most attacks on small business websites are not a decision against a particular company. They are a sweep. Programs probe address ranges around the clock, try known paths, test known vulnerabilities and move on when nothing fits. Whoever gets hit was rarely singled out — they were simply reachable. This article takes a sober look at which parts of a website can actually be attacked, where the attack surface comes from and which decisions make it smaller. Without alarmism, without jargon and without the promise that nothing can happen afterwards.
Why small businesses get hit
The idea that a craft business with eight employees is too insignificant to be attacked assumes a human attacker who picks targets. At scale, nobody works that way. The normal case is an automated sweep: a program queries thousands of addresses per minute, identifies the software in use from response patterns, matches it against a list of known vulnerabilities and, on a hit, immediately tries the next step. The raw material keeps arriving. For the reporting period from July 2024 to June 2025, Germany's Federal Office for Information Security counted an average of 119 new software vulnerabilities per day, around 24 percent more than in the previous period (BSI, The State of IT Security in Germany 2025). Vulnerabilities of medium and high severity rose by roughly 20 percent, while critical ones remained almost unchanged at minus 2 percent (BSI, The State of IT Security in Germany 2025).
The same survey is clear about who is affected: of 950 reported ransomware attacks in the period, around 80 percent hit small and medium-sized enterprises (BSI, The State of IT Security in Germany 2025). The digital association Bitkom, surveying more than 1,000 companies, puts the annual damage to the German economy from analogue and digital attacks at 289.2 billion euros, of which 202.4 billion euros come from cyberattacks alone (Bitkom, Wirtschaftsschutz 2025). 87 percent of the companies surveyed report incidents at all, and 34 percent were specifically affected by ransomware — in 2022 the figure was 12 percent (Bitkom, Wirtschaftsschutz 2025). For a business without an IT department, one conclusion matters most: the probability depends less on how well known you are than on how much technical surface you put online. What role the chosen setup plays is laid out in the comparison of approaches.
Not selected, just found
Step 1: mass scan
Automated programs check address ranges and typical paths. Headers, file names and error messages reveal which software and which version is in use.
Step 2: matching
The detected version is matched against publicly documented vulnerabilities. Because new ones appear daily, this comparison ages in the attacker's favour, not the operator's.
Step 3: monetisation
Only after a hit does interest in this particular site arise: as a dispatch point for spam, as storage for foreign content or as a starting point for extortion.
What can actually be attacked on a website
The term attack surface sounds abstract but can be written down very concretely. Attackable is everything that is reachable from outside and does something in response: a login screen, a form, an upload, an interface, a piece of code that starts on every request. Not attackable in the same sense is everything that is merely delivered — a finished HTML file can be requested, but it cannot be persuaded to execute something unforeseen. Every decision about how a website is built moves between these two poles. The BSI describes the typical requirements for web applications in module APP.3.1 of the IT-Grundschutz Compendium, among them a secure baseline configuration and the rule that security-relevant details must not leak through error messages (BSI IT-Grundschutz Compendium, APP.3.1).
Login area
Every publicly reachable login screen is a permanent target for automated credential guessing. It is the most frequently and most cheaply attacked point of any website.
Code and database
If a page is assembled on every request, interpreter, framework and database queries all run. Each of these building blocks can contain a flaw that is reachable from outside.
Extensions
Add-on modules come from different vendors with different maintenance quality. They extend the feature set and, at the same time, the amount of foreign code running in your name.
Forms and uploads
Anything that accepts input processes data from an unknown source. Without proper validation this turns into spam, abuse of your mail path or a place to store foreign files.
Accounts and roles
Old employee logins, shared team passwords and agency accounts with full access are attack surface without any return. They only become visible once they are used.
Environment
Hosting, domain management, certificates and mailboxes are part of the surface too. A hijacked domain account weighs more heavily than a single compromised page.
Two topics are deliberately left out here. Data protection and consent are a discipline of their own with their own requirements; they are covered in GDPR and cookie consent done properly. And load time is a quality topic, not a security topic, even though both questions hang on the same architectural decision. This article is about operational risk only: how likely an incident is, and how long it hurts.
Executed or delivered: the decisive difference
There are two fundamentally different ways a page reaches the browser. In the first, the work begins with the request: the server starts an interpreter, loads a framework, connects to the database, queries content, navigation and settings, lets extensions apply their filters and finally emits HTML. In the second, the page was finished earlier and sits on the server as a file; the request only triggers delivery. What this means for load time is described in PageSpeed and static delivery. In security terms the difference is even more fundamental: what is not executed cannot be made to execute something else.
Scroll table sideways
| Aspect | Generated on every request | Delivered as a finished file |
|---|---|---|
| Code in the request path | interpreter, framework, extensions | no application code in the delivery path |
| Database | reachable on every page view | not part of public delivery |
| Public login | content system reachable on the web | editing separated from delivery |
| Foreign code | depends on extensions and themes | limited to what is needed |
| Recovery | files and database together | republish from the build |
| Typical maintenance | ongoing, spread across many vendors | centralised in one place |
This is not a free pass. A statically delivered site has attack surface too: the domain, the hosting, the form backend, the access to the editing tool. The difference is one of magnitude. Instead of a permanently exposed system with dozens of foreign components, a few clearly named points remain that you can actually keep track of. That is exactly what the XICflow setup is designed for; how the path from draft to published page works is shown in how XICflow works.
The shortest rule of thumb
Extensions: the most common entry point
Add-on modules are the reason many websites work at all — and at the same time the place where most incidents begin. The mechanism is mundane: a module solves a small problem, gets installed once and is then forgotten. At some point its vendor stops maintaining it, a vulnerability is published, and from that moment the site is on a list. At an average of 119 new vulnerabilities per day (BSI, The State of IT Security in Germany 2025) that is not a rare event but the normal state of affairs. In module OPS.1.1.3 of the IT-Grundschutz Compendium, the BSI explicitly recommends assessing, prioritising and applying available patches promptly and documenting those decisions in a traceable way (BSI IT-Grundschutz Compendium, OPS.1.1.3).
- Write down the inventory: which extensions are installed, which are actually used, and who is the vendor?
- Remove unused ones rather than disabling them: disabled code still sits on the server and often remains reachable.
- Check the maintenance status: when was the last update released? A module untouched for two years is a decision, not a detail.
- Apply updates with a way back: back up first, then click through the most important pages and forms afterwards.
- Justify every new module: each additional component enlarges the surface. The benefit should justify the permanent maintenance effort.
- Resolve duplicates: two modules for the same job double the risk without doubling the benefit.
Every extension is foreign code running under your domain name. Choosing a module is therefore a decision about maintenance effort, not only about features.
Access, passwords and the shared team login
The second big block is unspectacular and therefore easily skipped: who may log in, with what, and what happens when someone leaves? In module ORP.4, the IT-Grundschutz Compendium sets out two ground rules that work without an IT department. Basic requirement ORP.4.A1 states that every user ID must be uniquely assigned to one person. ORP.4.A2 requires rights to be granted on the basis of necessity, following the principle of least privilege, and withdrawn when staffing changes (BSI IT-Grundschutz Compendium, ORP.4). A shared editing password passed around the team violates both at once: it cannot be attributed to anyone, and it cannot be revoked selectively when someone leaves.
- One individual login per person, even if only two people work on content.
- Two-factor authentication for every account that can change content or settings.
- Roles granted by need: whoever maintains text does not need rights over technology, payments or user management.
- A password manager instead of sticky notes, spreadsheets or reused passwords.
- Time-limited access for service providers, removed once the project ends.
- A review of the account list twice a year, deleting everything nobody needs.
Two-factor is the single most effective step
That there is ground to make up here is not a guess. Small and medium-sized enterprises meet on average only around 56 percent of the basic IT security requirements (BSI, The State of IT Security in Germany 2025) — and access control is regularly among the open items. Working on this improves your position with what you already have, without buying a single tool. Free support exists: the Alliance for Cyber Security, a BSI initiative with 8,898 participants (Allianz für Cyber-Sicherheit, as at 22 July 2026), provides recommendations and checklists at no cost.
Forms: spam, abuse and foreign mail
A contact form is the one point where an otherwise lean website accepts foreign input. That is precisely why it is a popular target — rarely to break into the website, mostly to use it. The typical patterns are bulk sending through the form's mail path, injecting links into notification emails and attempts to change the recipient address. The damage is invisible at first and surfaces later in an unexpected place: your domain ends up on blocklists, and suddenly ordinary business email stops arriving. How a form stays both effective and lean is described in contact forms that generate enquiries.
Protect without puzzles
Server-side validation, a hidden extra field and a minimum time between opening and submitting reliably filter out automated sending without burdening people.
Fix the recipient
The destination address belongs in the server configuration, not in a field that travels with the request. That way the mail path cannot be redirected or used for foreign post.
Cap the volume
A limit per time window and sender address prevents a single call from triggering thousands of messages. Unusual spikes become visible as a result.
The same applies to uploads, only more strictly. Wherever visitors can upload files, the server side decides what happens next: storage outside the publicly reachable area, checking the actual file type rather than the extension, fixed size limits and no execution rights in the target directory. A single upload field without these rules can turn an otherwise unremarkable site into a storage place for foreign content.
Backups you can actually restore
The difference between a backup and a restore is usually noticed only in an emergency. A backup proves that data was copied. A restore proves that a working state can be produced from it — with date, duration, target environment and outcome. With ransomware, it is precisely the second piece of evidence that determines whether there is any alternative to paying. Among affected companies, 15 percent paid a ransom (Bitkom, Wirtschaftsschutz 2025); a proven way back is what spares you that decision. The BSI describes the requirements for a data backup concept in module CON.3 of the IT-Grundschutz Compendium, naming encryption of backup data and regular restore tests among them (BSI IT-Grundschutz Compendium, CON.3).
Scroll table sideways
| Question | Backup exists | Restore evidenced |
|---|---|---|
| What is proven? | a copy exists | a working state can be produced from the copy |
| When do errors surface? | in an emergency | during the trial run |
| Storage | often in the same place | at least one copy separate from operations |
| Time required known? | usually unknown | measured and recorded |
| Typical mistake | database saved, files forgotten | becomes visible in the trial run |
The trial run is the real test
With a statically delivered website this point becomes noticeably simpler, because the published state comes from a defined build. Republishing is therefore not a rescue operation but a routine procedure. How that plays out in day-to-day operation and what is included is set out in the overview of features and in the plans.
HTTPS and security headers: the basics
Encrypted transmission is no longer an optional extra but a prerequisite. More than 95 percent of browser traffic now runs encrypted (Google Transparency Report), and browsers actively flag unencrypted form pages as insecure. The right expectation matters: HTTPS protects the transport path between browser and server. It says nothing about whether the site itself is clean, whether the software is maintained or who can log in. The padlock in the address bar is proof of transport, not a seal of quality.
Beyond that, there are response headers the server sends along to tell the browser what is allowed on the page. They cost nothing and are still rarely set: only around 22 percent of all hosts serve a Content Security Policy at all (HTTP Archive Web Almanac 2025), and more than 92 percent of sites with such a policy allow inline scripts within it, largely cancelling a central protection (HTTP Archive Web Almanac 2025). The picture for enforced encryption is similar: around 31 percent set Strict-Transport-Security (HTTP Archive Web Almanac 2024).
Scroll table sideways
| Header | What it does | Practical benefit |
|---|---|---|
| Strict-Transport-Security | enforces encrypted requests | prevents falling back to unencrypted connections |
| Content-Security-Policy | defines allowed sources for scripts | limits the damage of injected scripts |
| X-Content-Type-Options | stops the browser guessing types | prevents files from being executed as scripts |
| Referrer-Policy | controls the origin data sent along | leaks fewer internal addresses outward |
| Permissions-Policy | switches off browser features | camera, microphone and location stay blocked |
The reason for these low numbers is rarely ignorance; it is ownership. Headers are server configuration, and in many small projects that sits in no man's land between agency, host and business. Where technology and delivery come from one source, this is a one-off setting instead of a recurring dispute. How data protection and consent fit alongside without filling the page with foreign scripts is described in the article on GDPR and consent.
The underrated part: reputation and domain
When damage is discussed, the conversation usually revolves around downtime and recovery costs. The heavier part is often a different one: a hijacked website is rarely switched off, it is kept in use. It gains additional subpages with foreign content, hidden redirects aimed at search engines or a login page that harvests other people's credentials — all of it under your domain name. To visitors, search engines and mail providers, none of this is distinguishable from your own offering.
- Browser warnings: visitors see a security warning before they even reach the page — including long-standing customers.
- Loss of visibility: foreign content and redirects can move rankings; recovery takes considerably longer than the clean-up.
- Email delivery problems: if the domain lands on blocklists because of form-driven sending, quotes and invoices are affected too.
- Loss of local trust: for small businesses, a site flagged as unsafe travels faster by word of mouth than any advertising campaign.
- Effort at the wrong end: the clean-up consumes exactly the time that is already scarce in daily business.
Visibility today is no longer a matter of classic search results alone. How local businesses show up in AI-assisted search is described in visibility in AI search for small businesses — and the very domain that is meant to be cited there as a source carries foreign content once it is compromised. How addresses, redirects and rankings stay stable during larger rebuilds is shown in relaunch without ranking loss.
What security cannot deliver
This is where an honest assessment belongs. Absolute security does not exist, and any promise in that direction is dubious for one simple reason: new vulnerabilities keep appearing — an average of 119 per day in the reporting period (BSI, The State of IT Security in Germany 2025). What does exist are two quantities you can genuinely influence: the amount of attackable surface and the time to recovery. Together they decide whether an incident is an annoyance or a business problem.
Two quantities that count
For businesses without an IT department this yields a practical order: first shrink the surface, then tidy up access, then rehearse the way back. That is unspectacular and still works better than any additional protective component that has to be maintained in turn. How a website comes about in the first place, and which decisions are made early, is described in building a website with AI.
The emergency sequence when it happens
In an emergency, people rarely act wrongly for lack of knowledge; they act wrongly for lack of an order. The most common mistake is to clean the site quickly and put it back online without knowing the cause — after which the same route is used a second time. This sequence fits on one printed page next to the screen.
- Take the site offline or switch to a maintenance notice. That limits the damage for visitors and stops foreign content from spreading.
- Lock down access: change all passwords for editing, hosting, database, domain management and mailboxes, enable two-factor, remove unknown accounts.
- Preserve the state: copy the compromised state including log files before anything is changed — otherwise the cause cannot be reconstructed later.
- Check the backup: pick a state from before the incident and restore it in a separate environment rather than over the live installation.
- Determine the cause: outdated component, stolen access, form or server configuration? Without this answer, the clean-up is only a pause.
- Close the gap, then publish: update, remove, harden — and watch the site closely for a few days afterwards.
- Check notification duties: if personal data is affected, separate deadlines apply; that belongs in expert hands.
Do not delete first
Anyone who has written such a sequence down once wins back the most valuable two hours in an emergency. And anyone who also knows where their credentials are, how to reach the host and when the last backup ran shortens an outage from days to hours. Beyond availability, one thing holds: the smaller the surface was beforehand, the shorter this list becomes.
For a small business, security is not a question of specialist knowledge but of a few fundamental decisions: how much runs on every request, who may log in, and how quickly a clean state is available again. The same decision keeps paying off elsewhere — a lean website is also the one that can be extended calmly, for example with a careers page that attracts skilled staff. What that looks like in practice is shown by the demo websites; the differences between the approaches are set side by side in the comparison. And if your own situation is unclear, a short review via the contact form is the fastest route to a reliable answer.
Sources and studies