Pre-launch: ScanBastion is in development. Features and prices may change before launch. Join early access

ScanBastion Free Security Check

Learn

WordPress security assessment checklist for agencies: external and plugin checks

By Chris Kerger · · 4 min read

A WordPress security assessment for a client is two jobs: what you can check from inside the site with admin access, and what anyone can see from outside. Most agencies do the first well because a plugin does it for them, and skip the second. This checklist covers both, in the order that finds the most for the least time, and ends with what to put in front of the client.

Before you start, make sure you are authorised in writing to assess the site, and that the client knows which checks you will run. For external scanning, verifying control of the domain is the cleanest proof; see how DNS TXT verification works.

1. External checks: what visitors and attackers see

Run these first. They need no access, take minutes, and often surface the issues the client's previous agency never looked at.

  • HTTPS everywhere. http:// redirects to https:// with a 301, on both the bare domain and www. No mixed-content warnings on key pages.
  • TLS configuration. TLS 1.0 and 1.1 refused; certificate trusted, matching both hostnames, with the full chain and automatic renewal. If the site is behind Cloudflare or another CDN, check the edge and, separately, that the origin is not reachable directly by IP.
  • Security headers as delivered. HSTS, Content-Security-Policy (report-only is a fine start), X-Frame-Options or frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. The free headers and TLS checker covers this and the two items above in seconds.
  • Cookies. WordPress and WooCommerce session cookies carry Secure and HttpOnly; SameSite=Lax where the theme allows.
  • Version disclosure. The generator meta tag, ?ver= query strings on core assets, readme.html and license.txt at the root, and Server or X-Powered-By headers with version numbers.
  • Exposed files. Backups (.zip, .sql, wp-config.php.bak), .git/, debug.log in wp-content, directory listings in wp-content/uploads.
  • Exposed endpoints. /xmlrpc.php reachable when nothing uses it; the REST API user listing at /wp-json/wp/v2/users revealing usernames; author archives (/?author=1) doing the same.
  • Front-end libraries. Outdated jQuery, sliders and other scripts served to visitors, which plugins rarely report.

An external scanner such as ScanBastion runs these checks together, with passive OWASP ZAP analysis and curated Nuclei templates for exposed files and known-vulnerable components, and produces a report you can send as is.

2. Internal checks: with admin and hosting access

  • Core, plugins and themes up to date, and automatic updates on for minor core releases at least. Note any plugin abandoned by its author (no update in two years) and any premium plugin with an expired licence, which usually means no security updates.
  • Unused plugins and themes deleted, not just deactivated. Deactivated code on disk can still be reachable.
  • Known vulnerabilities in the installed versions, from the security plugin or a vulnerability database.
  • Users. No shared admin accounts; every administrator is a real, current person; former staff and previous agencies removed; two-factor authentication on every admin.
  • File integrity. Core files match the official release; no unexpected PHP in wp-content/uploads.
  • wp-config.php. DISALLOW_FILE_EDIT set to true; WP_DEBUG off in production; unique salts; database user with only the privileges WordPress needs.
  • Hosting. Supported PHP version; SFTP or SSH rather than FTP; file permissions not world-writable.
  • Backups. Automatic, off-site, retained for at least 30 days, and restored successfully at least once. An untested backup is a hope.
  • Security plugin configured: firewall on, login rate limiting, alerts going to an inbox someone reads. See security plugin vs external scanner for what it does and does not cover.

3. Prioritise before you report

A list of thirty findings with equal weight is not useful to a client. Order the work:

  1. Anything that means compromise is likely or under way: known-exploited plugin vulnerabilities, exposed backups or .git, unknown admin users, unexpected PHP in uploads.
  2. Updates and removals: outdated core, plugins and themes; abandoned plugins replaced.
  3. Transport and headers: TLS versions, HSTS, cookies, the safe headers. Mostly configuration; an hour or two.
  4. Hardening: file editing, XML-RPC, user enumeration, version disclosure.
  5. Content-Security-Policy: valuable but needs a report-only period on a WordPress site, because themes and plugins inject inline scripts.

Mark automated findings you have not reproduced as "needs review" rather than presenting them as confirmed. The guide on severity, confidence and verification explains why that matters for credibility.

4. What to deliver to the client

  • A one-page summary in plain language: what was checked, what was found, what to do first, and what the assessment did not cover.
  • Each finding with evidence and a specific fix, so the work can be scheduled or approved.
  • A date for the rescan, and the before-and-after once it is done. This is what turns a one-off audit into a retainer; see how to price monthly security reports.

The sample report and template shows one way to lay this out.