Service 16

Security for websites and online shops

Most attacks on websites and online shops are automated and aimed at every reachable installation with a known weakness. Whoever gets hit rarely had bad luck; they had an open door. We close it: we harden TYPO3, WordPress and Shopware, protect access and customer data, keep systems current and make sure that a clean state and a clear procedure are ready if something happens. Security is not an add-on for us. It is part of every project we build and operate.

HardeningWAFLogin protectionBackupsMonitoring

What is actually being attacked

The logs of our servers show it every day: automated requests for configuration files, backup copies and admin interfaces — from senders that have nothing to do with the company behind the site. These are not targeted attacks. They are mass checks. A script knocks on millions of domains for the same weaknesses and reports the hits; only then does someone come by. Whoever does not appear on that list stays invisible to the vast majority of attackers.

The entry points have been the same for years: extensions with a known but unpatched vulnerability, accounts with weak or reused passwords, forms that accept anything, servers on a PHP version without security updates. Online shops add the checkout to the list — manipulated scripts that skim payment data are often noticed only when customers complain.

That is why security at Sharpness does not start with a product, but with an inventory: which versions are running, which extensions are in use and still maintained, who has which access, where configuration and backups are stored. The result is a prioritised list — what must happen now, what is due in the coming weeks, and what you can skip.

Hardening: every system by its own rules

TYPO3, WordPress and Shopware each have their own settings, and we know them from the daily operation of our own and inherited installations. We close what does not need to be open, give accounts only the rights their task requires, review extensions before installation and build payment and checkout processes so that card data never touches your server. For systems on versions without vendor support we plan the update — a security plugin alone does not keep an outdated code base alive.

Beneath that is the server: current PHP and database versions, clean file permissions, configuration and credentials outside the web directory, up-to-date encryption and security headers. On our own servers in Germany this is the standard; on third-party hosting we implement what the environment allows and say clearly where it does not.

Much of what a server would have to fend off never reaches it with us. A firewall in front filters known attack patterns, slows down automated traffic and keeps scanners away — set up so that real customers, payment providers and interfaces pass without obstruction. How we do this with Cloudflare is described on our service page for Cloudflare configuration.

Updates, backups, access: the unspectacular half

Most successful attacks use gaps for which an update has long existed. That is why we install security updates for the core, extensions and server environment promptly — tested, with a way back, at fixed intervals and without you having to think about it. This is the core of our ongoing support, not a by-product.

A backup is only a backup once it can be restored. We store backups separately from the production system, keep several versions and rehearse the restore regularly. When an incident is suspected, this is the decisive question: is there a clean state from before the break-in?

And we clean up access: who can log in where, with which rights — and who left the company long ago. Admin access gets a second factor, credentials get a secure place instead of an email inbox. This is unspectacular work. It still decides the outcome.

When it has happened: a procedure instead of panic

There is no such thing as one hundred percent security, and whoever promises it has not understood it. What does exist is a rehearsed procedure: isolate the system, change access, secure the traces, find the way in, restore a clean state, close the gap. Cleaning up is not done by deleting the files that were found — the back door is usually somewhere else — but with the clean state plus all outstanding updates.

If personal data is or may have been affected, the GDPR adds a duty to notify the supervisory authority within 72 hours (Article 33). We provide the technical basis for that: what happened, since when, which data was reachable, what was done. The legal assessment stays with you or your data protection officer — we make sure the facts are available.

Frequently asked questions

What does website security cost?

That depends on what is in place, not on a price list. The inventory is a manageable, fixed-price item; what follows is listed with the effort for each measure — you decide what to commission. Ongoing security is part of our maintenance contract: updates, backup checks and monitoring belong to its fixed scope.

Can you guarantee that our website will not be hacked?

No — and nobody can do that seriously. What we do is two things: make the attack surface so small that mass attacks come to nothing, and keep the time to detection and recovery so short that an incident stays an incident and does not become a disaster. A tested backup and a rehearsed procedure are worth more than any promise.

Is a security plugin not enough?

A plugin can throttle logins and report known patterns — it cannot replace an outdated PHP version, repair wrong file permissions or close a gap in another extension. Often it is an additional attack surface itself. We use such tools deliberately, but as a complement to hardening, updates and a firewall in front — not as a replacement.

We are a small company — who would attack us?

Nobody personally, and that is exactly the point: the attacks are automated and aimed at every reachable installation with a known weakness. For a script, a small company website is the same prey as a corporate portal — as a spam relay, a phishing host or a stepping stone. Size does not protect you; the state of the system does.

What else needs attention in online shops?

Above all the payment path: card data should never touch your server but go directly to the payment service provider. That takes the most profitable target away from attackers and largely keeps the shop out of the obligations of the PCI DSS card standard. Then there are customer accounts, order data and the interfaces to ERP and payment providers — each with its own, narrowly scoped credentials.

Do you also take over websites you did not build?

Yes. The inventory works the same way for third-party projects — and is often most revealing there, because nobody remembers what is installed and why. Afterwards you decide whether we harden, take over, or only deliver the list your current agency continues to work with.

Do you also carry out penetration tests?

We check configuration, versions, access and code for known weaknesses and use automated scanners — this covers the majority of real attacks. A formal penetration test with simulated attacks and a report according to a recognised scheme is a discipline of its own; if your customer, your insurer or a certification requires it, we work with specialised testers and implement their findings.

More answers in our FAQ

Security for websites and online shops: Let us get specific.

Tell us your starting point — you get an honest assessment, not a sales pitch.

Call Start a project