In 2018, British Airways found out their payment page had been compromised. Not from a security scan. Not from a monitoring alert. From customers calling to report card fraud.
The attack had been running for 15 days. The page looked exactly right. The form worked. Nothing was broken. A 22-line JavaScript file was quietly copying every card detail entered and sending it somewhere else. 500,000 customers were affected before anyone on the security team knew anything was wrong.
That is what website defacement looks like when it is done properly.
The version nobody pictures
When most people imagine a defaced site, they picture the homepage covered in a hacker's tag. That kind of attack gets fixed before lunch. It is designed to be seen, which is exactly why it gets caught fast.
The attacks that run for weeks are designed not to be noticed. The visual change is there. It is just subtle enough that nobody looks for it, and targeted enough that the wrong people never see it.
What actually changes on a compromised site
Payment overlays are the most damaging. A transparent layer sits over your checkout form, intercepts keystrokes, and sends them off before your own code touches them. The form looks right. It works right. It passes every functional test. The only evidence is fraud hitting your customers a few days later.
Below that, there is a range of changes that are visible if you are specifically looking but easy to miss if you are not. A link in your navigation pointing somewhere you did not add. A banner on a product page with low traffic. Footer text hidden with CSS, stuffed with pharmaceutical or gambling keywords that your visitors never see but search engines index. An exit popup routing people to a different domain.
Then there are the redirects that only fire for mobile visitors, or people arriving from Google. Log in and browse your own site and you see nothing unusual. Your customers see something else entirely.
When did you last look at your checkout page, not to test it but just to look at it, and check whether anything was there that should not be?
Why your current tools miss this
The core problem is baseline. Without a record of what your site looked like before, you have nothing to compare against. Could you identify a transparent overlay on a payment form? A script tag that was not in your source last month? Most people cannot, not because they are careless, but because they have never tried.
Attackers plan for this gap. Cloaking hides changes from logged-in admins and known security tools, so the person most likely to check sees the clean version every time. Supply chain attacks inject code through third-party scripts, so your own files stay untouched. A file integrity check comes back clear because the malicious code is running from someone else's server.
Your uptime monitor sees 200 OK. Your server logs look normal. The attack runs regardless.
What actually catches it
You need to check what your site delivers to a browser, not just what your server sends. For supply chain attacks especially, those are different things. Your server can be completely clean while your visitors are getting something malicious.
ScanTower runs four checks built directly for this class of attack.
Visual defacement monitoring takes a screenshot of your page on every scan and compares it against the stored baseline. Perceptual hashing handles normal dynamic content like rotating ads and live pricing without triggering on it, but a structural change to your layout or an injected element flags immediately. You get an alert with a before/after screenshot so you can see exactly what shifted.
Script monitoring tracks every script loaded by the page. If a script appears that was not there on the previous scan, that is a detection. New scripts appearing without explanation is one of the clearest signals that a supply chain compromise is in progress.
Subresource Integrity checking flags externally hosted scripts that are missing SRI attributes. SRI is how you tell the browser to verify a script before executing it. Without an integrity hash, if the CDN serving that script is ever compromised, your visitors receive the malicious version with no warning and nothing to stop it. A significant number of sites are running dozens of unprotected third-party scripts right now without realising it.
Card skimmer detection runs behavioural analysis in a real browser, looking for JavaScript that intercepts form input and exfiltrates it. It is the check that would have flagged what was running on the British Airways payment page.
None of this requires installation. Point ScanTower at your site and it scans from the outside, exactly as a visitor would see it. The first site is free, no credit card needed.
Worth asking
The BA payment page ran compromised for 15 days because nobody was watching what visitors actually saw. File monitoring, uptime checks, server logs: none of them answer the right question.
The question is not whether your server is responding. It is whether your site looks and behaves the way you built it. If it handles payments, stores user data, or carries your reputation, that is worth knowing.