QA Audit — pybar.121group.dev (PYBAR staging)

• Evidence:
• /wp-content/plugins/astra-addon/readme.txt → HTTP 200 (Stable tag: 4.13.1)
• /wp-content/plugins/ewww-image-optimizer/readme.txt → 200 (v8.5.0)
• /wp-content/plugins/mailchimp-for-wp/readme.txt → 200 (v4.12.2)
• /wp-content/plugins/spectra-pro/readme.txt → 200 (v1.2.10)
• /wp-content/plugins/ultimate-addons-for-gutenberg/readme.txt → 200 (v2.19.25)

Why it matters: Attackers use automated scanners to match plugin versions against the CVE database. Exposing exact versions is the #1 enabler of "targeted vulnerability scans."

Fix: Add to .htaccess (or LiteSpeed config): ``apache <FilesMatch "^(readme|license|changelog|CHANGELOG)\.(txt|html|md)$"> Require all denied </FilesMatch> ``

Or simpler — a WP security plugin (Wordfence / SolidWP) can handle this automatically.

---

Evidence: Returns "Already Installed" page, but the endpoint itself should not be reachable.

Why it matters: Low-risk in isolation (site is installed), but install.php becomes dangerous if the DB ever gets corrupted or dropped — an attacker who hits the page at that moment can take over the installation. Best practice is to block it outright.

Fix: Block via .htaccess: ``apache <Files install.php> Require all denied </Files> ``

---

Evidence: GET /?author=1 → 301 redirects to /author/121-josh/

So the first user (likely an Administrator) has the slug 121-josh — meaning "Josh" is an admin, and the username is exposed. Combined with wp-login.php being publicly accessible, this gives attackers half the credentials needed for a brute-force attack.

1. Fix (pick at least one):
2. Force author slugs to differ from login — change the "Nicename" field in wp_users via phpMyAdmin to something neutral (e.g. pybar-editor)
3. Block ?author=N enumeration — add to functions.php or security plugin: ``php add_action( 'template_redirect', function () { if ( isset( $_GET['author'] ) ) { wp_safe_redirect( home_url(), 301 ); exit; } }); ``
4. Rename the admin login slug via "WPS Hide Login" or similar plugin (mitigates brute-force)

---

Evidence: None of Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, Referrer-Policy, or Permissions-Policy are set.

Fix: Add to .htaccess: ``apache <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS Header always set X-Content-Type-Options "nosniff" Header always set X-Frame-Options "SAMEORIGIN" Header always set Referrer-Policy "strict-origin-when-cross-origin" Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()" </IfModule> ``

Defer CSP until live site is profiled (it breaks things if mis-configured).

---

Fix: Add to .htaccess / LiteSpeed config / php.ini: `` Header unset X-Powered-By ``

or in php.ini: expose_php = Off

---

Fix: Same FilesMatch rule as B1 also catches this. Or just delete the file — WP core updates will recreate it but you can re-delete as part of your post-deploy checklist.

---

Evidence: time_starttransfer=1.108s, total page 1.71s, HTML size 336 KB.

Why it matters: Google considers >0.8s TTFB a problem for Core Web Vitals. 336 KB of HTML on the homepage is also heavy (likely a lot of inline CSS/JS from Spectra & Astra).

• Likely causes (need wp-admin to confirm):
• No page cache (LiteSpeed Cache not installed / not configured)
• Spectra + Astra Pro + UAG + RankMath running heavy backend for every page
• No object cache (Redis/Memcached)

1. Fix:
2. Install LiteSpeed Cache plugin (free, works beautifully on Synergy's LiteSpeed servers)
3. Enable object caching if Synergy offers Redis
4. Audit for unused plugin features (Spectra Pro + UAG duplicate a lot of functionality — consider removing one)

---

Why: Inline JS/CSS can't be cached across page loads and bloats HTML. Most of these are likely from Spectra / UAG / Astra Pro pushing per-block critical CSS.

• Fix (after plugin audit):
• Review Astra Pro / Spectra "performance" settings — both have "combine CSS/JS" toggles
• In LiteSpeed Cache: enable CSS/JS combine + minify
• Consider disabling "Spectra Block Editor" blocks you're not using (each loads its own CSS)

---

Astra 4.13.1 is current as of early 2026, but Astra Pro paid add-on typically lags 1–2 weeks behind. Worth verifying in wp-admin → Updates that nothing's pending. Also confirm you have a valid Astra Pro license for the client (staging licenses don't always carry over to production).

---

Fix: WordPress has native lazy-loading since 5.5, but if a theme bypasses wp_get_attachment_image() it won't apply. Add to child theme: ``php add_filter( 'wp_lazy_loading_enabled', '__return_true' ); ``

Or ensure all images go through the_post_thumbnail() / wp_get_attachment_image().

---

Responds to HEAD with 405. Best practice on sites not using Jetpack / Gutenberg mobile apps / XML-RPC-based integrations is to fully disable: ``php add_filter( 'xmlrpc_enabled', '__return_false' ); ``

Or block via .htaccess.

Good — unauthenticated user enumeration via REST is blocked. But note: ?author=N still works (see B3). Close the full set by blocking REST users to non-admin too.

Solid core (Wordfence / SolidWP / All In One WP Security) would automate B1, B2, B3, I1, I2, R1 in one install.

This is OK for staging (saves complication) but confirm production DNS plan uses Cloudflare or Synergy's free LiteSpeed QUIC.cloud CDN for edge caching. The live pybar.com.au IS on Synergy with no CDN currently.

Homepage references https://secure.gravatar.com — typical WP comments feature. If the final site doesn't use WP comments, disable globally: ``php add_filter( 'get_avatar_url', '__return_empty_string' ); ``

fonts.googleapis.com / fonts.gstatic.com references present. GDPR-sensitive (German courts have ruled this is a privacy violation). Consider self-hosting fonts via OMGF plugin or Spectra's built-in local fonts option.

---