How to Check Website Vulnerability

On a site you own or are authorised to test, run checks from safest to most intrusive: malware and blacklist status, software versions, exposed files, TLS, and only then an active scan that sends test payloads. Always test the public hostname, not a bare IP, because a shared server picks the site by hostname.

1. Confirm you own the site or have written permission. Active scans against sites you do not control can be unlawful and will trigger the host’s defences.
2. Note the exact public URL visitors use, including https and www.
3. Run a public malware and blacklist check such as Sucuri SiteCheck on that URL.
4. In the hosting panel, record the CMS, plugin and PHP versions.
5. Grade TLS with an SSL test.
6. Run a passive scanner, and an active scan only on staging or in a window you control.

An uptime or HTTP status check is a different test: a site can return 200 and still run a plugin with a published flaw.

Because the flaw is already published: attackers match your plugin, theme or PHP version to a known bug and use an existing exploit, with no need to study your site. Updating or removing the component is the fix.

• Deactivated plugins are still code on disk and can still be exploited; delete what you do not use.
• A public .git folder, .env file or backup ZIP leaks passwords without any software bug.
• Shared hosting does not hide an old plugin; your account serves the files you installed.

To switch PHP versions, see change the PHP version in cPanel or in Plesk, after testing on staging.

Start with ZAP’s baseline scan, which spiders the site and reports issues from responses without attacking it; run the full active scan only on staging. Active scans submit payloads into forms and can create junk records or emails.

# passive baseline scan (Docker)
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://staging.yoursite.com

Treat every alert as a lead to verify, not a confirmed flaw: scanners report false positives, and a manual check or code review decides. Expect your host’s firewall to block or rate-limit aggressive scans against production.

Fix exposed secrets and known-vulnerable components first, configuration issues next and informational notes last, then rerun the same check to confirm each finding is gone. A finding that still appears is not fixed.

1. Remove any public backup, .env or .git path, then rotate every password and key it contained.
2. Update or delete each plugin, theme or library the report named.
3. Move PHP to a supported branch.
4. Correct TLS and security headers.
5. Rerun the malware check, WPScan and the SSL test.

Then limit the damage of the next flaw: two-factor authentication for admins (WordPress 2FA), a web application firewall (what is a WAF) and backups with one copy off the server under the 3-2-1 backup rule. None of these replaces updating. For hands-on help, WebJi® website security services handle clean-up and hardening.