• Security & Recovery · PHP

Site security: most break-ins are not an attack on you, but a bot working through everyone in turn

“Who would bother with us” is the most common and most expensive mistake. Sites are rarely targeted deliberately. They are found by a program that walks through thousands of addresses in a row and checks known weaknesses: an old platform version, a module nobody has updated in three years, an open admin panel with a weak password. It does not know what you sell and it does not care how big the business is. Security means closing what it looks for before it reaches you.

See how it works
Price
after a free audit
Guarantee
30 days after project sign-off
Focus
sites and stores, mostly OpenCart
after a free audit
Price
30
Guarantee

days after project sign-off

sites and stores, mostly OpenCart
Focus
5
Timeline

to 25 working days

free review of the current state
Start
30
Warranty

days from the date the acceptance act is signed

within 2 hours
Reply
under a written contract
Terms
What's included

Complete list of work and what you get as a result

  • a check of the versions of everything running under the site: platform, language, database, modules
  • updating whatever no longer receives security fixes, verifying the site after each step
  • closing service sections and files that should not be reachable from outside
  • limiting password guessing and bulk automated requests
  • an audit of access: who can log in, with what rights, and whether they still work with you
  • a check of permissions on files and folders where images are uploaded
  • verification that the backup actually restores rather than merely being created
  • a written list of what remains open, with the reason for each item
When this service isn't right

What's not included — so there are no surprises at delivery

  • a guarantee that the site will not be hacked — nobody gives that guarantee
  • investigating a break-in that already happened: that is separate work with a different order of steps
  • rewriting third-party modules found to contain a vulnerability
  • ongoing monitoring after the work, unless agreed separately
  • legal advice on personal data protection
Who it's for

Situations where this service delivers results

Scenario 1 of 4

A store built a few years ago and left alone

The most typical case. The site works and brings in money, so nobody updated it. Those are exactly the ones an automated sweep finds.

We'll review your situation in a free audit

Free review of the current state

We look from the outside at what is visible about your site and tell you how bad it is. Often this is a short conversation rather than a project.

What we measure

  • Platform and language versionThe simplest and the most important. If the site runs on a language version that no longer gets security fixes, everything else is secondary.
  • What is visible from outsideService files, open folders, traces of test pages. All of it is visible without any credentials — and it is exactly what an automated sweep sees.
  • How many third-party modulesEach one is somebody else's code inside your site. The question is not how many there are, but how many are still maintained by their authors.
  • How admin login is set upA standard address, no limit on attempts, one shared password for everyone. The most common way in is the simplest one.
  • Whether backups existAnd, more to the point, whether anyone has ever restored from them. A backup nobody has tested very often fails to deploy at the moment it is needed.
  • Who has accessA former contractor, a dismissed manager, a test account with administrator rights. This turns up almost every time.

What you get

  • a list of what is visible from outside and which of it is dangerous
  • an answer on what can be closed quickly and what needs real work
  • an estimate of the work broken down by stage
  • an honest answer if there are no serious problems

Timeline: 2–4 working days

Why is it free

The most important part — versions and what is visible from outside — takes an hour and no credentials. We see no reason to charge for that, and even less reason to frighten anyone without grounds.

What's next

You receive the list and the estimate. What happens next is your decision — the document stays with you.

Short form: your contact and site URL

  • Contract, act and 30-day warranty

    Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.

  • Sole proprietor & bank transfer

    The contractor is a registered sole proprietor. Payment by invoice with closing documents.

  • Rights & access — yours

    Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.

  • Client portal instead of email chains

    During the project you get access to a portal: contracts, invoices, acts and project status in one place.

  • European clients

    Among our work — projects for Norway, Bulgaria, Moldova and Spain.

  • Verifiable numbers

    Every case in the portfolio comes with a link to a live site and a technical measurement.

  • Audit first, then pricing

    There is no price list on the site intentionally: the scope of the same work differs multiples between clients.

  • We say "no" when unsure

    If the task isn't ours or the deadline is unrealistic — we tell you upfront.

What affects the price

Why two seemingly identical tasks are priced differently

  • How outdated the base isOne version up is one thing. Moving across several major versions affects modules and the theme, and that is a different amount of work.
  • Number of third-party modulesEach has to be checked for compatibility after an update. It is the modules, not the platform itself, that usually set the timeline.
  • Whether there is somewhere to testA copy of the site for testing is mandatory. If there is none, it has to be built first — a separate but necessary step.
  • State of access rightsAn audit of five accounts is quick. Thirty accounts with an unclear history means a separate conversation with you about each one.
  • Who runs the serverIf the server is yours, some measures are done there. On shared hosting some of those decisions are simply unavailable.
  • Traces of a break-inIf the review turns up files that are not yours, the task changes: cleaning up the consequences comes first, and that is costed separately.
Cases

Tasks and results in numbers — all metrics measured by us

a sample of 41 Ukrainian online stores

Task
Assess the technical base of the stores: whether there is a usable sitemap and whether the platform is being updated.
Solution
External measurement of the homepage and one product page taken from the sitemap: traces of features in the HTML, product markup, prices and attributes. Presence of the trace, not the quality of the implementation.
Result
Measured 2026-08-08, 39 stores: PHP without security support in 3 of 39; no usable sitemap in 6 of 39; sitemap pointing at a different domain in 1 of 39.

a niche store of dental materials with a content section (podcast, educational material)

Task
Combine a store of dental materials and instruments with a content section for the professional community in one site — so that the podcast audience walks into the catalogue and the catalogue stays compact and fast.
Solution
An OpenCart store (UniShop2 theme) behind Cloudflare. The sitemap is built as a proper sitemapindex of four files (homepage, categories, products, information pages) with no duplicates. Payment by cash on delivery at a Nova Poshta branch and by card, delivery to a branch or by courier, free delivery from UAH 5,000. Content distribution: Apple Podcasts, YouTube, Telegram, Instagram, TikTok.
Result
96 products and 21 categories — 123 URLs in the sitemap with zero duplication (for comparison, another project in the same sample had duplication up to 3.9×). TTFB 0.44 s at 103 KB of HTML — the second lightest page among the 16 measured portfolio sites. Measured 31.07.2026.

Did not find your case?

Describe how it works on your side — we will tell you whether “Protecting a site from being hacked” fits and what it means in your situation. No brief and no call: one question, one answer.

Process steps

Transparent stages with approval at every step

Total duration:5–25 days

  1. Outside view

    1–2 working days

    We look at what is visible about the site without credentials: versions, open files, service addresses. Exactly what an automated sweep sees.

  2. Inside review

    2–4 working days

    With credentials we check modules, file permissions, accounts and logs. This is where it becomes visible what already happened and went unnoticed.

  3. A copy to test on

    1–3 working days

    We build a separate copy of the site. Updating a live store blind is not an option: module compatibility is only ever proven in practice.

  4. Updates

    3–10 working days

    We update what is outdated step by step, verifying the site after each one. Anything that cannot be updated without losing a function we discuss with you separately.

  5. Access and limits

    1–3 working days

    We remove accounts nobody needs, limit password guessing, and close service sections. The cheapest measures with the largest effect.

  6. Backups and handover

    1–3 working days

    We restore from a backup in a test environment to prove it works, and hand over a written list of what remains open and why.

Technologies & integrations

What we build on and what it connects to

Stack

  • PHP
  • MySQL
  • MariaDB
  • nginx
  • Apache
  • Linux
  • OpenCart
  • WooCommerce
  • WordPress
  • Next.js
  • Git
  • SSH

Integrations

  • Cloudflare
  • Let's Encrypt
  • Google Search Console
  • Telegram
  • Email
Close the known risks in advance, or deal with it after a break-in

How this option differs from the alternative

When you find out about the problemduring the review, calmly
State of the site during the workrunning; updates are tested on a copy
Scope of workpredictable
Costplanned
When it can waitoverkill for a brochure site with no data and no payments
What we need from you

We can't start without this — best to prepare in advance

  1. access to the server or hosting and to the site admin panel
  2. a list of everyone with access, and what each of them needs it for
  3. which third-party modules and themes are installed and where they came from
  4. whether there have already been suspicious events: complaints, warnings from the host
  5. whether backups exist and whether anyone has tried restoring from them
  6. who on your side signs the work off

If something is missing — let us know, we'll help you gather it or do it as a separate task.

FAQ

Most frequently asked questions — with concrete answers

We are a small site, who would bother with us?

Nobody in particular — and that is exactly why it does not save you. Sites are found by a program that walks through addresses in a row checking known weaknesses. It does not care how many orders you get: it is looking for an old version and an open admin panel. The size of the business affects how much you lose, not the odds of it happening.

Do you guarantee we will not be hacked?

No, and anyone who guarantees that is lying. We close what is known today and reduce the probability. Tomorrow a new weakness will be found in a platform or a module — that is the normal course of things. This is why checking backups is part of the work: a plan for when something does happen after all.

Will the update break the site?

It can, if done blind on a live store. That is why we always build a separate copy and check module compatibility there. Sometimes it turns out a module does not work on the new version and its author no longer maintains it — unpleasant, but far better to find out on the copy.

What do we do if the site has already been hacked?

That is a different task with a different order of steps, and we do not mix it with this one. There you first have to understand what was done, when, and whether traces remain, and only then close the holes. If our review turns up files that are not yours, we say so immediately and re-estimate the work.

Why do you insist on backups so much?

Because a backup nobody has ever restored from is an assumption, not a backup. We regularly see configured backup routines that spend years producing files which cannot be deployed. That is why the work includes an actual restore in a test environment, not a check that a file exists.

How long does it take?

From 5 to 25 working days. Limiting access and closing service sections takes days. The timeline is set by updates: if the platform has to move across several major versions, every third-party module has to be checked separately.

Will you keep an eye on the site afterwards?

Not as part of this work — it is a one-off. Ongoing monitoring, updates and response are maintenance, a separate agreement with its own rules. We do not switch it on silently and invoice for it later: if you need it, we agree on it openly.

Can we do only part of the work?

Yes, and it is often sensible. The cheapest measures give the most: update what is already unsupported, close open service files, remove other people's access and verify the backup. That can be done quickly, with the deeper work postponed. On the review we split the list exactly that way.

Let us look at what is visible about your site from outside

We will check versions and exposed spots without any credentials and tell you how serious it is. The review is free, we reply within 2 hours.

From measured cases96 products and 21 categories

View cases
  • Reply within 2 hours
  • No commitment
  • We work under a contract

There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.