What We Check

Passive CMS checks built for professional owner reports

Audit My CMS uses public, ownership-verified signals. It does not exploit vulnerabilities, authenticate, brute-force names or scan ports.

CMS and component inventory

Detects WordPress, Drupal, Joomla, OpenCart, PrestaShop, or TYPO3 signals, public component, extension, module, plugin, and theme references, version evidence quality, authentication surface indicators, and records that still need owner verification.

Vulnerability applicability

Matches detected CMS core and component versions against curated records, checks observed versions against affected and patched ranges, and separates version-matched findings from ruled-out historical records and manual-review items.

Public exposure checks

Reviews publicly reachable files, installation remnants, backup artifacts, debug output, development metadata, exposed admin or upload tooling, API surfaces, directory indexes, robots.txt, sitemap signals, and hidden injected-content indicators.

Infrastructure and headers

Reviews CSP, HSTS, X-Content-Type-Options, Permissions-Policy, HTTP versus HTTPS behavior, risky HTTP method signals, server and powered-by headers, certificate health, deprecated TLS, weak cipher signals, IP address, network ownership, CDN/cache signals, and homepage response behavior visible to public visitors.

SEO, privacy, and reputation

Reviews titles, meta descriptions, canonical tags, robots and sitemap signals, Open Graph, structured data, privacy and terms links, cookie notices, tracking or marketing signals, public contact data, and Safe Browsing matches when configured.

Quality, accessibility, and third parties

Runs conservative homepage accessibility checks powered by Axe, reviews selected navigation pages for broken internal links, checks external JavaScript assets for SRI coverage where applicable, records performance signals, and inventories known and unknown third-party scripts, embeds, and services.

Detailed coverage

Coverage adapts to the CMS, public signals, and website configuration found during each scan. The report separates findings, positive checks, ruled-out vulnerability records, limitations, and scanner execution completeness so owners can see both what was observed and what could not be confirmed passively.

  • CMS detection and supported CMS confirmation
  • CMS core, extension, module, plugin, and theme inventory
  • Version evidence quality and latest-version context where public vendor data is available
  • Version-matched CVE records, manual-review records, and ruled-out historical records
  • CMS-specific public exposure review for supported platforms
  • Authentication, administration, upload, API, and content editing surface indicators
  • Version disclosure and manual review signals
  • Public extension and theme evidence where available
  • Passive navigation discovery and selected reviewed pages
  • Public backup, configuration, database, environment, and log file indicators
  • Development repository and build artifact exposure signals
  • Default installation, documentation, or maintenance artifact indicators
  • Public API documentation and admin tooling exposure signals
  • Directory listing exposure
  • Hidden external links or iframes that may indicate injected content
  • Passive parent-domain subdomain discovery and related public asset review
  • Admin, staging, test, legacy, mirror, default-page, TLS, and dangling-CNAME attack surface indicators
  • Suspicious JavaScript review only when stronger behavioral indicators are present
  • Debug logging findings only when sensitive content appears to be logged
  • Missing or weak CSP, HSTS, X-Content-Type-Options, and Permissions-Policy headers
  • Server banner disclosure, CORS wildcard with credentials, and advertised risky HTTP methods
  • Certificate validity, deprecated TLS versions, and weak TLS cipher support
  • SPF, DKIM selector presence, DMARC, MX, MTA-STS, TLS-RPT, CAA, DNSSEC, and dangling CNAME checks
  • SEO metadata, canonical, Open Graph, structured data, robots, and sitemap signals
  • Privacy policy, terms links, cookie notices, analytics, pixels, and public emails or forms
  • Third-party script domains, CDNs, embeds, known services, unknown script domains, and JavaScript libraries
  • Subresource Integrity checks for static external JavaScript candidates
  • Broken internal links, homepage response status, redirect behavior, mobile viewport, and page sampling limits
  • Homepage accessibility checks powered by Axe
  • Scanner execution completeness and coverage-limiting warnings

How findings are classified

  • Known third-party services stay visible for inventory and privacy review, but are not reported as unknown third-party domain findings.
  • Shared cache, public API, privacy-link, debug-log, and suspicious-JavaScript signals are kept low or informational unless stronger evidence supports escalation.
  • Public sensitive files are escalated based on file type and content evidence, not just a generic HTTP 200 response.
  • External attack surface findings include the affected host, review signal, and DNS/HTTP/TLS context where available.
  • Broken-link checks ignore Cloudflare email-protection URLs and similar non-navigation placeholders.
  • Version findings are triage evidence. Owners should confirm installed versions inside the CMS before major remediation or risk acceptance.
  • Scanner execution completeness means modules produced expected output; it does not mean every page, route, component, or internet-facing service was assessed.
  • WAF, bot protection, rate limits, blocked HTML, or low page sampling reduce confidence and are shown as limitations.
  • Reports include remediation guidance and implementation examples where a passive finding can be fixed with common configuration patterns.