Platform guide
WordPress security and cookie consent scanner
SecurityScan checks a WordPress site from the outside, the way a visitor’s browser sees it. There is nothing to install in wp-admin: enter the domain and get a list of what to fix, with the cookie, header or file behind each finding.
What the scan checks
WordPress exposures
Public user lists in the REST API, enabled XML-RPC, a readable debug.log, wp-config.php backups, a listable uploads folder and an announced version.
Cookies before consent
Tracking cookies set before any consent choice, the consent banner and its reject option, the privacy policy link and consent on forms.
Security headers
HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy.
SSL/TLS certificate
A valid certificate, days until it expires, and whether plain HTTP redirects to HTTPS.
Outdated JavaScript
Library versions the pages load, such as jQuery or Bootstrap, compared with versions that have known CVEs.
Exposed files and server settings
Files like .git or .env reachable from the web, version-revealing headers, risky HTTP methods, open CORS and cookie flags.
Checks that run only on WordPress
When the scan recognises WordPress, from its generator tag or its wp-content and wp-includes paths, it also checks the places where WordPress sites most often leak. It follows a subdirectory install such as /blog/, and it confirms each file by its content, so a site that answers every address with a “not found” page doesn’t produce false alarms.
User accounts listed by the REST API
Whether /wp-json/wp/v2/users shows your user accounts and their login names to anyone. The report gives the number of accounts, never the names.
XML-RPC enabled
Whether xmlrpc.php answers. Unless an app or Jetpack needs it, it mainly gives attackers a way to try many passwords in one request.
A readable debug.log
Whether wp-content/debug.log is public. With WP_DEBUG_LOG switched on, it records PHP errors with server paths and sometimes request data.
Backups of wp-config.php
Whether a copy such as wp-config.php.bak or wp-config.php~ can be downloaded. It holds the database password and secret keys, so the report tells you to change them, not just delete the file.
A listable uploads folder
Whether wp-content/uploads/ shows a directory listing of every file ever uploaded, including ones never linked from the site.
The announced version
Whether the generator tag names the WordPress version. This one is informational and doesn’t lower the score.
Where WordPress problems usually come from
Tracking added outside the consent plugin
Google Analytics, Tag Manager or the Meta Pixel is often added by an analytics or SEO plugin, a theme setting or a snippet in the header. If it doesn’t go through the consent plugin, its cookies load before the visitor chooses. The scan names the tracking cookies it saw before any consent choice, such as _ga or _fbp.
Old JavaScript in themes and plugins
WordPress core updates its own jQuery, but many themes and plugins ship their own older copy of jQuery or another library. The scan reads the versions from script URLs and from the loaded page, and compares them with versions that have known vulnerabilities.
Headers left at hosting defaults
Much WordPress hosting sends no Content-Security-Policy, Strict-Transport-Security or Referrer-Policy. They are set once for the whole site, in .htaccess, the Nginx configuration or a security plugin.
Files left in the web root
Deployments and manual uploads can leave a .git folder, an .env file or an error log reachable from the web. The scan requests a fixed list of such paths and reports the ones that answer.
Fixing findings on WordPress
Every finding comes with a recommendation. On WordPress the fix is usually in one of three places: the consent plugin (make the analytics or pixel plugin wait for consent), the server configuration or a security plugin (headers, blocked paths), or the theme or plugin that bundles an old library (update or replace it).
Plugin and theme updates can bring a fixed problem back. Paid plans re-scan automatically, weekly on Starter and daily on Business and Agency, and email you the report, so a regression doesn’t go unnoticed for months.
Questions
- Do I need to install a WordPress plugin?
- No. The scan runs from outside and needs only the domain. It sees what a visitor’s browser sees, plus the server’s response headers and TLS certificate.
- Does it check my WordPress plugins for vulnerabilities?
- Not by plugin name. It checks the JavaScript libraries your pages load against versions with known CVEs, which catches old copies bundled with themes and plugins, and it checks WordPress itself for the exposures listed above.
- Is it safe to run against a live WordPress site?
- Yes. The WordPress checks are a few ordinary requests for well-known addresses. The scan doesn’t log in, doesn’t try passwords and doesn’t send attack payloads.
- Is this a GDPR audit?
- No. It is a technical check of cookies, the consent banner and security settings. It does not replace legal advice.
Technical checks, not legal advice. SecurityScan does not replace a consultation with a lawyer.