If your website has been running for years "without anyone touching it," that phrase doesn't mean it's secure. It only means nobody has looked at it yet with the intention of getting in. Before you change a single line of an old website, there are three very specific things you can check in an afternoon, and one last step that decides whether the change goes well or locks you out of your own business.
The case: a ten-year-old website with the back door open
A company asked us to modernize their website, which had been running for a decade on a version of its programming language so old it no longer receives any security patches. Before building anything new, we reviewed what was already there, for a simple reason: there's no point putting a new facade on a house with the windows broken.
What we found wasn't a slow or ugly website. It was a website with three holes that had been open for years, unnoticed:
- An admin panel you could log into without a username or password. Inside were customers' banking and medical data.
- A public form you could inject code into, instead of it simply receiving what the customer typed.
- PDFs of almost every order in the website's history, downloadable by anyone who could guess the order number. No login, no session needed: just change a number in the address bar.
The number that mattered most: close to 43,000 historical orders had their PDF accessible this way, with no check on who was asking for it.
How do you know if your site has the same problem?
You don't need to be a developer to ask yourself these three questions about your own website, whoever maintains it today:
Who can get into the admin panel, and how? If the panel's address is guessable (something as simple as adding /admin to your own site) and getting in requires nothing more than a password that hasn't changed in years, or worse, none at all, then anyone who finds it is in. Have someone try it from the outside, instead of assuming "nobody knows about it."
What happens if someone types something unusual into your forms? A contact or order form should always treat whatever the person filling it in types as plain text, never as an instruction. When it doesn't, that form becomes a door for outsiders to make the website do things nobody from outside should be able to do.
Do your documents (orders, invoices, delivery notes) carry anything beyond a serial number in their address? If the address of a PDF on your own site is predictable, "order 4821" followed by "order 4822", and it doesn't check who's requesting it, anyone with enough patience can work through all of them, one by one, without your website ever noticing anything unusual is happening.
If you answer "I don't know" to any of the three, that is the answer: nobody has checked yet, and "it works fine" is not the same thing as "it's secure." They're two different things that look identical right up until the day they stop looking identical.
What comes first once you find this?
In this case, before building anything new we closed the most urgent holes directly on the live website: the panel was locked down, the form stopped accepting code, and the PDFs started checking who was requesting them. That doesn't wait for any big project: an open hole gets closed the moment it's found, not whenever it's convenient.
Why isn't fixing it enough to move on?
Because the next step, modernizing the engine that runs the whole website, is a change that touches everything at once, not one isolated piece. A website that hasn't been updated in ten years can depend on some very specific, very old detail that nobody remembers is even there, and that is exactly the kind of change that can break something without warning.
That's why the big change wasn't made directly on the live site: it was tested first, in full, on an exact copy. And that's where two bugs turned up that, had they been made live on the first try, would have left the company unable to get into its own panel or generate a single new PDF from minute one. They were fixed on the copy, without anyone outside the company ever noticing, and only then was the real change applied.
The decision rule
If you're about to touch something that hasn't been touched in a long time and that your whole business relies on at once, test it first on an exact copy. Never directly on the live system. It doesn't matter if it's a website, the software that handles your orders, or the one that handles your accounting: the longer something has been "working quietly," the more likely it depends on a detail nobody has looked at again, and that detail is what breaks when you finally touch it. Testing it on a copy first is what turns a serious failure, discovered on change day, into a calm fix, discovered a week earlier with time to spare.
We saw something similar, in a different shape, at a group of pharmacies whose platform had spent months with broken data nobody had looked at closely: you can read that case here. The lesson repeats itself: something that "has been working for a while without complaints" isn't proof of anything, it's just the absence of anyone who has looked closely.
You can see how we apply this kind of work, auditing before building, across different industries on our services page. If you want us to review what's really going on inside your website or software before someone else finds it, get in touch.
