Backups and integrity: every published file checked against its fingerprint
When you publish, Anticode copies the version being replaced into a backup and records a SHA-256 fingerprint of every file it publishes. A scan then rechecks each site about once a day. A file that no longer matches its fingerprint, or that fails the security gate, is put back from the newest good backup, or taken down if no good copy exists.
What could go wrong with a published file
Most website compromises don't change the design; they slip a script or a redirect into a page that otherwise looks normal, and the owner finds out weeks later from a customer or a browser warning. Classic hosting leaves you to notice. Anticode's pages are stored files with no CMS or plugins running beside them, which removes the usual way in, but storage can still go wrong and the safe assumption is that one day something will. Website backups and integrity monitoring are the answer to "how would we know, and how would we put it right?"
Backups at every publish
Just before a publish replaces a live site, every file the site had is copied into a new backup version, stamped with the time. The last ten versions are kept; when an eleventh is made, the oldest is deleted. A site published before fingerprints were recorded gets one computed for each file as it's backed up, so older sites join the same scheme on their next publish.
Fingerprints and the daily scan
At publish, the SHA-256 hash of each file is written to the site's record in Anticode's database, which is kept apart from the files themselves. Whoever might be able to alter a file can't also alter what it's checked against.
Every hour a scan picks a batch of the sites that were checked longest ago, so each site comes round about once a day. For every file it:
- Hashes the file again and compares it with the fingerprint recorded at publish.
- Runs it through the security gate once more: a page through the same checks as publishing, an app's code through the app code gate's security checks.
- If the file is unchanged and passes, moves on.
- If it changed, fails a check, or isn't a file Anticode published at all, looks through the backups from newest to oldest for a copy that matches the published fingerprint (or, for files from before fingerprints, one that passes the gate) and puts it back.
- If no backup will do, deletes the file, so a tampered page stops being served rather than staying live.
| Result | What it means | Shown as |
|---|---|---|
| Clean | Every file matches its fingerprint and passes the gate | Clean, with the time of the scan |
| Restored | One or more files were put back from a backup; the detail names each file and why | Repaired |
| Taken down | A file had no good backup and was removed; any files that were restored are listed too | Taken down |
The latest result appears in the integrity section of the site's public security report, so a client or visitor sees the same thing you do.
Backups and version history are different things
These backups protect what's live. They're used by the scan, and there's no button to roll the published site back to one of them by hand. If you want an earlier version of your site back, that's what version history is for: it keeps saved versions of the project you edit, lets you preview and restore one, and then you publish again. The guide to rolling a website back to a previous version walks through it.
Limits
- Daily, not instant. A file changed between scans could be served until the next one, up to about a day later.
- It checks against what you published. If you publish a mistake yourself, the scan treats it as correct. It guards against changes after publish, not against your own edits.
- Files, not form data. The backups cover the published pages and app code. Form submissions are stored separately and aren't part of these versions.
- Unpublishing removes them. Take a site down, or delete the account, and its backups are deleted with it.
- Ten versions. Older published versions beyond that are gone; keep anything you need in version history or an export.
Questions people ask
How many backups of my published site are kept?
The last ten published versions. Each publish adds one and removes the oldest beyond ten.
Can I restore the live site from one of these backups myself?
Not directly. They're used by the integrity scan. To go back to an earlier version, restore it from version history and publish again.
How would I know if a file was repaired or taken down?
The result and the files involved are shown in the integrity section of your site's security report, along with when the last scan ran.
Do I need a security plugin?
There's nothing to install. Published pages are plain files with no CMS or plugins to patch, and the checks run on Anticode's side.