How Do You Secure a Website You Did Not Build?
Inheriting a website means inheriting its access list, its unpatched dependencies and its undocumented code. Work in this order: know what you have, take the keys back, prove the backup restores.
On This Page
You have been handed a login, a domain and a deadline. The person who built the site left eighteen months ago. There is no documentation, the hosting invoice goes to someone in finance who has never seen the control panel, and a plugin on the site was last updated during a different government. Nobody has asked you to make it secure. They have asked you to change the pricing page by Thursday.
This is the ordinary case, and inherited website security is a different discipline from securing something you designed. You are not choosing controls. You are reconstructing decisions someone else made, some deliberate and some accidental, with no way to tell which is which. The instinct to start hardening immediately is wrong, and it is wrong in a specific way: hardening a system you have not inventoried is how sites go offline on a Friday for reasons nobody can trace.
What follows is the sequence we work through in the first week of taking over a site. It is deliberately unambitious. No penetration test, no rewrite, no platform migration. It covers the five things that account for most of the risk in most inherited sites, in the order that makes each step cheaper than it would have been on its own. The same sequence sits under every website maintenance engagement we start, whatever the platform turns out to be.
What you actually inherited
You inherited three things, and only one of them is code. The first is an access list: every human, service and key that can change the site, including the ones nobody remembers granting. The second is a dependency graph, most of it written by strangers and pulled in at some point by someone who needed one feature from it. The third is a set of assumptions, none of them written down, about what the site is allowed to do and who it is allowed to do it for.
The access list is where the real exposure usually sits. Code gets attention because it is visible; credentials do not, because a stale account looks exactly like nothing at all. And the attacker on the other side is rarely targeting you personally. Most compromises of small sites are opportunistic and automated, which is worth internalising early because it changes what you prioritise. If you have not read it, why small sites get attacked at all explains the economics: nobody chose your site, a scanner found a version string and moved to the next step of a script.
Day one: you cannot secure a list you do not have
Write the inventory before you change anything. Not a diagram, not an audit document, just a plain list in a file the whole team can read. The point is not completeness on the first pass. The point is that every subsequent decision has something to check itself against, and that the gaps become visible as gaps rather than as things nobody thought of.
What the list has to contain
- The registrar, and who controls it. Domain control outranks everything else. Whoever can change the nameservers can take the site, the mail and the certificates, and no amount of server hardening touches that.
- DNS, and where it is actually hosted. Frequently not at the registrar. Record every entry, including the ones pointing at services nobody mentioned.
- Hosting, and the layer above it. Server or platform, plus any CDN, proxy or firewall in front of it. A rule you do not know about is a rule you will eventually fight.
- The application and its version. Platform, theme, every plugin or package, and where the source of truth for that list is meant to live.
- Every integration holding a key. Payments, mail delivery, analytics, forms, chat, shipping, anything with an API token sitting in a config file.
- Every account that can log in anywhere. Application admins, hosting panel, database, deploy keys, third-party dashboards, and the shared mailbox those password resets land in.
How to find what nobody mentioned
Three sources fill most of the gaps. Billing records tell you which services are being paid for, which is the fastest way to discover a monitoring tool or a form provider nobody named in the handover call. The DNS zone tells you what the domain points at, including subdomains for staging sites that were never taken down. And the page source of the live site tells you what is actually loading in a visitor’s browser, which is occasionally a script from a vendor whose relationship ended two years ago.
Everything unexplained looks like waste and some of it is load-bearing. Record it, mark it unknown purpose, and leave it running until you can say what breaks without it. The exception is anything actively dangerous, such as a publicly reachable database admin tool, which comes off immediately.
Day two: take the keys back
Now that you have the access list, work it. This is the highest-value day of the week and the one most likely to be postponed, because rotating credentials is tedious and nothing visibly improves afterwards.
The shared login problem
Inherited sites almost always have one administrator account that several people use. It is the hardest thing to fix politically and the most useful thing to fix technically, because a shared account destroys attribution. Once two people share a login you can no longer answer who made a change, which means you can no longer investigate anything at all. Give every person their own account, at the lowest role that lets them do their job, and turn multi-factor authentication on for anyone who can publish or install.
The accounts that outlive the people
Then work down the list looking for accounts belonging to nobody: the former agency, the contractor who did one landing page, the intern, the plugin support engineer who was given admin during a ticket and never removed. The account nobody remembers creating is the one that gets used. Disable rather than delete on the first pass, so that if something breaks you can restore access while you work out why, and check the site still functions before you finish the day.
Rotate the machine credentials in the same pass: database passwords, deploy keys, API tokens for payments and mail. A token that sat in a public repository for a week is a token you must treat as known, and the awkward truth is that you will rarely be able to prove it was not copied. Rotation is cheap. Certainty is not on offer.
Day three: a backup is not a backup until you have restored it
Almost every inherited site has a backup arrangement, and almost none of them have been tested. The failure modes are boringly consistent: backups covering files but not the database, backups stored on the same server as the site, backups that stopped silently when a disk filled in March, retention so short that a compromise discovered in week three has already overwritten every clean copy. We have written up the whole pattern in the backup strategy you only value once, and the summary is that an untested backup is a belief rather than a control.
Restore the most recent backup onto a scratch host that is not the production server, then log in and check that the database, the uploaded media and the configuration all arrived. Write down how long it took. That number is your actual recovery time, and it is usually several times whatever anyone estimated.
Do this before you patch anything. A tested restore converts every later step from risky to reversible, which is exactly why it belongs at day three and not at the end of the month. It also leaves you with a clean reference copy of the site, which turns out to matter enormously once you reach the code you cannot explain.
Day four: patch level, and what a version number will not tell you
Now compare what is installed against what is current, and against what has known published vulnerabilities. Core platform, theme, every plugin, the language runtime, the web server, the database. For a WordPress site this is mostly a matter of reading the updates screen honestly, then checking the plugins showing no update available because they were abandoned rather than because they are current. An abandoned plugin is worse than an outdated one: it will never be fixed, and its last release is the last release.
Patch in order of exposure rather than in order of version distance. Anything reachable without logging in comes first: the front end, the form handlers, the login page itself. Anything that processes uploads comes next. Administrative tooling only staff can reach comes after that. Patch one thing at a time and load the site between each, because a batch of eleven updates that breaks the site tells you nothing about which one did it.
The harder discipline is knowing what a clean signal does not cover. Handover conversations are full of reassurances that mean less than they sound like, and it helps to be explicit about the gap between each one and the thing you actually need to know.
| What you were told | What it does establish | What it leaves open |
|---|---|---|
| The platform is on the current version | Someone applied at least one update | Whether plugins, themes and the server are current |
| A malware scan came back clean | Nothing matched today’s signatures | Whether a valid admin account was quietly added last year |
| The site has HTTPS | Traffic is encrypted in transit | Whether the admin area is reachable by anyone who finds it |
| There have been no incidents | Nothing was noticed | Whether anything was ever logged or retained |
| There is a firewall on the hosting plan | A product is being paid for | Whether its rules were ever tuned, or still sit at defaults |
| The dependency file is in the repository | What was intended at build time | What is actually running on the server right now |
| Deployment uses a key | How releases reach production | Who else holds a copy of that key |
Day five: the code nobody can explain
Every inherited site has some. A custom plugin with a name like site-functions. A theme with three hundred lines added straight into its functions file. A snippet pasted into a settings box by someone solving a problem in 2019. This is where the real work is, and where most handovers quietly give up.
Triage without reading every line
You do not need to understand all of it in week one. You need to know which parts touch three things: user input, authentication, and anything that writes to disk or executes a command. Search for the patterns rather than reading top to bottom. Look for places that build a database query by joining strings, places that read a request parameter and use it in a file path, places that handle uploads, and places that decide whether someone is allowed to do something. The rest can wait.
When it is minified, obfuscated or simply beyond you
Obfuscated code on a site nobody maintains is a finding in itself, and it deserves a specific response rather than a shrug. Establish where the file came from and when it appeared. If it is newer than the last legitimate release of the component it lives inside, treat the site as compromised until proven otherwise and stop making changes. If it turns out to be a licensing wrapper from a commercial plugin, note it and move on. The distinction is discoverable in almost every case, and guessing is the one option that is never acceptable.
When nobody knows how it was built
Sometimes there is no repository, no build process anyone can describe, and no person left to ask. The site exists, it serves pages, and the only record of how it got there is the running server itself. This is more common than the industry admits, and it has a defined answer.
Treat the production server as the source of truth, and then make it one properly. Take a full copy of the files and the database. Put the files into a repository, unmodified, as a single first commit with a message saying exactly that: this is what was running on this date, provenance unknown. That commit is not good code. It is a baseline, and from that moment every change is visible, attributable and reversible, which is the property you have actually been missing.
You cannot audit a system with no history. Give it one, starting today, and the second month becomes a different kind of problem from the first.
Then resist the rewrite. The urge to replace an undocumented site with something you understand is strong and usually premature, because a rewrite trades a known set of unknowns for an unknown set of them, and it does nothing about the credentials or the backups that were the actual risk. Rebuilding is a legitimate answer when the platform is unsupported or the code cannot be made safe, and that belongs in a proper build conversation rather than in a first-week reflex.
The week, in order
Compressed into a sequence you can hand to someone else. The order matters more than the pace, because each step makes the next one cheaper or safer.
- Inventory. Domain, DNS, hosting, platform, plugins, integrations, accounts. One plain file. Mark the gaps as gaps rather than leaving them blank.
- Credentials. Individual accounts at minimum roles, multi-factor for anyone who can publish, shared logins retired, machine tokens rotated, dormant accounts disabled.
- Backups. Restore one to a scratch host, confirm the database and the media arrived, and record how long the whole thing took.
- Patch level. Update in order of exposure, one change at a time, checking the site between each. Flag abandoned components for replacement rather than for updating.
- Unknown code. Find what touches input, authentication and the filesystem. Date anything obfuscated against the release it claims to belong to.
- Write it down and hand it on. A page describing what you found, what you changed, and what is still unknown. The next person inherits your notes instead of your silence.
Turning a pile of findings into something anyone will fund
By Friday you will have a long list, and a long list is not a plan. The trap is presenting it in discovery order, which makes everything look equally urgent and gets the whole thing deferred. Severity describes how bad an issue is in the abstract. Priority describes what to do first here, on this site, with this budget. They are different, and our parent company has taken that difference apart in the anatomy of a finding, which is worth reading before you write anything up for a client or a board.
The write-up wants three columns and little else: what is wrong, what it lets someone do, and what fixing it costs. Tooling helps with that translation step, and there is a category of product built for exactly it. Prooflin works this way, resolving findings, severities, priorities and recommendations into a report someone can actually review. Whatever produces it, the document has to survive being read by a person who will never look at the site, because that is usually the person deciding whether the work happens.
One thing to settle before the list gets long: what you will do if the inventory turns up evidence that something already happened. Have that plan written while nothing is on fire, because the first hour of a suspected compromise is when people improvise badly. What to say while you still do not know covers the communication side, which is the part that damages reputations long after the technical problem is closed.
And the reversal, stated plainly, because it is the most common way this week goes wrong. If someone offers to book a penetration test in month one, decline it. A test against an unpatched site with shared admin logins produces a report whose contents you already knew, at a price that would have funded the fixes. The argument for doing the obvious first is set out in penetration test or fix the obvious, and the ordering holds for nearly every inherited site. Once the five steps above are genuinely done, a test starts telling you things you could not have found yourself, and that is when it becomes worth buying. If you are midway through a handover and unsure what to do with what you have found, describe the site to us and we will say which step we would take next.
Common questions.
What should you do first when taking over someone else’s website?
Build an inventory before changing anything. List the registrar, DNS host, hosting account, platform and version, every plugin or package, every integration holding an API key, and every account that can log in anywhere. Without that list you cannot tell whether a change is safe, and you cannot see what is missing. Inventory takes a few hours and makes every later step cheaper.
How do you check whether an inherited website has been hacked?
Look for evidence rather than running only a scanner. Check the administrator list for names nobody recognises, compare file modification dates against the last legitimate release of the platform, review recently changed files in upload directories, and read whatever server and application logs still exist. A clean malware scan means nothing matched known signatures today, not that the site is untouched.
Should you rotate all passwords when you inherit a site?
Yes, and rotate machine credentials as well as human ones. That means database passwords, deploy keys and API tokens for payments, mail and any other integration, alongside every administrator login. You cannot prove that a credential held by a departed contractor was never copied, and rotation costs far less than the investigation you would otherwise have to run later.
What do you do with custom code nobody can explain?
Triage it by risk rather than reading it end to end. Identify the parts that handle user input, decide who is authorised, or write to the filesystem, since those carry almost all the exposure. Date anything obfuscated against the release of the component it sits inside; a file newer than that release should be treated as a possible compromise until you establish where it came from.
Is it better to rebuild an old website than to secure it?
Rebuilding is right when the platform no longer receives security updates or the code cannot be made safe, and premature in most other cases. A rewrite trades known problems for unknown ones and does nothing about credentials, backups or access control, which is where most inherited risk actually sits. Complete the first-week sequence first; it also tells you what a rebuild would need to preserve.
How often should an inherited site be patched after the handover?
Set a fixed cadence rather than patching when something feels urgent. A monthly window for routine updates, with an out-of-band path for anything reachable without logging in, works for most small sites. Keep updating one component at a time and checking the site between each, and keep a tested restore available so a bad update stays an inconvenience rather than an incident.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.