Xerotact SHIELD-X Security

SHIELD-X is a shared-hosting-first WordPress security plugin. It is designed for site owners who need practical local protection without installing server daemons or requiring command-line access.

Current features include:

• Web application firewall rule engine that logs by default and requires explicit opt-in for enforce mode.
• Bundled SHIELD-X WordPress/AppSec WAF rules with local-only rule metadata and no external WAF runtime dependency.
• Manual IP, country, browser, referrer, and temporary blocking controls.
• File, database, and vulnerability scanner sections.
• Core file comparison against official WordPress release archives.
• Safer scanner review, ignore, recheck, quarantine, restore, and database remediation workflows.
• Login security with authenticator 2FA setup and recovery controls.
• Hardening controls for security headers, WordPress signatures, admin gate keyword, SSL, file editor restrictions, and PHP disable_functions guidance.
• Lockdown controls for direct PHP access protection, read-only policy previews, and controlled revert.
• Restore points, database backups before selected remediation actions, and log rotation reports.
• WP-CLI commands for status, scan, WAF, lockdown, log rotation, and database backup.
• Setup Assistant with a baseline completion indicator and remaining setup checklist.

External services

SHIELD-X does not send visitor profiler records, WAF logs, scanner findings, database backups, restore points, or site recovery tokens to SHIELD-X.

Some optional scanner features can contact third-party services selected or triggered by a site administrator:

• WPVulnerability API: The Vulnerability Scanner uses WPVulnerability by default when an administrator runs or schedules a vulnerability scan with feed refresh enabled. Requests are sent to https://www.wpvulnerability.net/core/{version}/, https://www.wpvulnerability.net/plugin/{slug}/, https://www.wpvulnerability.net/theme/{slug}/, and software endpoints such as https://www.wpvulnerability.net/php/{version}/, https://www.wpvulnerability.net/apache/{version}/, or https://www.wpvulnerability.net/mysql/{version}/ when SHIELD-X can detect those local versions. These requests include the installed WordPress version, installed plugin/theme slugs, and detected runtime component versions in the URL path so SHIELD-X can fetch matching advisory records. No visitor logs, WAF events, database backups, restore points, or recovery tokens are sent. Service information: https://www.wpvulnerability.com/. Privacy information: https://www.wpvulnerability.com/privacy/.
• Custom JSON feed: If the administrator enters a custom SHIELD-X advisory feed URL, SHIELD-X downloads JSON from that URL and caches it locally. The site owner is responsible for reviewing the custom feed provider’s terms and privacy policy.
• Xerotact licensing: If an administrator activates, checks, or deactivates a site license, SHIELD-X uses the Xerotact WC Key Manager API at https://xerotact.com. The exact request data is listed in the Privacy section below. Service information: https://wckeymanager.com/docs/licensing-api/. Xerotact terms: https://xerotact.com/terms/. Xerotact privacy policy: https://xerotact.com/privacy/.
• Google Drive backup storage: If an administrator enables Google Drive storage, SHIELD-X uses https://oauth2.googleapis.com/ and https://www.googleapis.com/drive/v3/ with the drive.file scope. The exact request data is listed in the Privacy section below. Each administrator supplies their own Google Cloud OAuth client; SHIELD-X does not bundle shared credentials. Service information: https://developers.google.com/drive/api/guides/about-sdk. Privacy information: https://policies.google.com/privacy.
• Optional reputation feed: If the administrator enables Firewall reputation feeds and enters a public HTTPS JSON feed URL, SHIELD-X downloads cached IP, hostname, and user-agent block entries from that URL. Administrators can keep the feature disabled, refresh it manually, and add local allowlist exceptions to control false positives. The site owner is responsible for reviewing the custom feed provider’s terms and privacy policy.
• Optional human challenge: SHIELD-X uses Cap.js Challenge (Captcha) with a bundled widget and local WordPress verification endpoint by default. Administrators may instead configure their own Cap-compatible endpoint. When enabled for login, password reset, or selected firewall challenge flows, SHIELD-X sends the visitor cap-token to the configured endpoint /siteverify URL with the saved site secret. Challenge features are disabled by default. Cap project information and source: https://github.com/tiagozip/cap.
• WordPress.org APIs and release archives: SHIELD-X uses normal WordPress.org plugin/theme/core update metadata through WordPress APIs during vulnerability inventory checks, and downloads official WordPress release archives and official WordPress.org plugin packages only when an administrator requests a core or plugin hash refresh/comparison. These packages are cached locally to build clean file hashes and reduce scanner false positives. WordPress.org privacy policy: https://wordpress.org/about/privacy/.

The Vulnerability Scanner can be set to Local cache only to avoid live advisory feed requests.

Bundled third-party code

SHIELD-X bundles the Cap.js browser widget for the optional Human Challenge feature so the challenge can run without loading JavaScript or CSS from a CDN. The bundled runtime file is assets/vendor/cap/cap.min.js, based on cap-widget 0.1.56 from https://github.com/tiagozip/cap. Readable upstream cap-widget source is included under assets/vendor/cap/cap-widget-src/ for reviewer verification. The upstream GitHub README says: “This project is licensed under the Apache-2.0 License, please see the LICENSE file for details.” SHIELD-X patches the browser bundle only to remove upstream CDN fallbacks; upstream attribution is preserved in the bundled JavaScript header, assets/vendor/cap/NOTICE.md, assets/vendor/cap/LICENSE-CAP-WIDGET.txt, and assets/vendor/cap/LICENSE-APACHE-2.0.txt.

SHIELD-X is licensed GPLv3-only because the bundled Apache-2.0 Cap.js component is GPLv3-compatible. The complete GNU GPL version 3 text is included in LICENSE.

Third-party notices for the bundled Cap.js and Iconoir material are included in THIRD_PARTY.txt; component-specific Cap.js notices remain under assets/vendor/cap/.

Privacy

SHIELD-X stores security data locally in your WordPress database and private SHIELD-X storage. It prefers a SHIELDX_STORAGE_DIR path or an outside-webroot shield-x-storage directory and falls back to wp-content/uploads/.shield-x/ only when outside-webroot storage is unavailable.

By default, the optional User Profiler is disabled. If a site administrator enables it, SHIELD-X sets a first-party shieldx_visitor cookie and stores recent request metadata locally for security review. Stored metadata can include visitor identifier, IP address, country header when provided by a proxy or CDN, browser label, user agent, URL path, redacted query string, referrer, admin-surface flag, logged-in user ID, and visit time. The profiler retention period is 30 days. Anonymous public GET requests are sampled so busy front-end traffic does not write a row for every visit.

SHIELD-X registers with the WordPress personal-data export and erasure tools. Exports can include authenticated User Profiler activity, threat-resolution actions attributed to the user, and non-secret SHIELD-X user settings. Two-factor secrets and recovery-code hashes are never exported.

Erasure anonymizes User Profiler rows linked to the user, removes user attribution from resolved threat records, and deletes SHIELD-X user metadata including two-factor secrets and recovery-code hashes. Security audit logs are not changed by the eraser and remain subject to the site’s configured log-retention policy. WordPress reports that retained-data status during erasure.

External-service data

SHIELD-X contacts the following services only when an administrator uses or enables the corresponding optional feature:

• xerotact.com license API: activation, validation, and deactivation requests send the license action, activation code, this site’s instance URL, and a SHIELD-X/{version} user-agent. When an activation code is stored, SHIELD-X automatically re-checks its status at most once per day and once per admin session on SHIELD-X pages; these checks send the same data as a manual license check. It does not send visitor profiler records, WAF events, scanner findings, backup or restore-point contents, recovery tokens, or WordPress user data.
• oauth2.googleapis.com: Google Drive device authorization sends the administrator-configured OAuth client ID and requested drive.file scope. Completing device authorization sends the client ID, client secret, device code, and grant type; later token refreshes send the client ID, client secret, refresh token, and grant type.
• www.googleapis.com Google Drive API: SHIELD-X sends an OAuth access token plus the folder/file metadata needed to manage its own backup folder, including names, parent or file IDs, MIME type, and size. When an administrator enables remote backup or restore, it uploads or downloads the selected database-backup or restore-point archive contents. It does not send visitor profiler records, WAF events, scanner findings, license keys, recovery tokens, or unrelated WordPress user data.

No executable code is loaded from vulnerability feeds. Feed data is parsed as JSON advisory metadata.

Runtime requirements

SHIELD-X requires PHP 7.4 or newer and WordPress 6.5 or newer. For full optional feature coverage, enable the PHP extensions normally present on supported WordPress hosts:

• OpenSSL for encrypted 2FA secrets, signed recovery flows, and secure local tokens.
• PCRE for the regular-expression WAF and malware signature engine.
• JSON for settings import/export, scanner metadata, and local logs.
• ZipArchive for official WordPress core and plugin package comparison.

When an optional extension is missing, SHIELD-X shows the affected extension on the System page before enabling related features.

Testing

Automated coverage lives under tests/. Unit tests are in tests/unit/, integration checks are in tests/integration/, Playwright browser smoke checks are in tests/e2e/, and shared fixtures are in tests/fixtures/.

Before creating an SVN trunk, run docker compose run --rm composer test, docker compose run --rm composer phpcompat, docker compose run --rm composer phpstan, wp plugin-check xerotact-shield-x-security --slug=xerotact-shield-x-security --mode=new, and scripts/test-playwright.ps1 locally, then resolve every reported error and warning. The full release gate is scripts/submission-check.ps1, which runs PHPUnit, PHPCompatibilityWP, PHPStan WordPress, Plugin Check, Playwright admin smoke checks, package validation, and uninstall smoke checks.

What SHIELD-X does NOT do

• It is not a server-level WAF. SHIELD-X inspects requests inside PHP after WordPress begins loading. For true network-edge filtering, use a host-provided or reverse-proxy WAF alongside SHIELD-X.
• It does not bundle a GeoIP database. Country blocking relies on proxy-supplied headers from trusted services such as Cloudflare or Sucuri and falls back to allowing traffic when no trusted header is present.
• It does not include a daemon or long-running background process. Scheduled scans, backups, restore points, and reputation feed refreshes use WordPress cron or the opt-in external runner endpoint.
• It does not apply Apache .htaccess rules on hosts that do not support Apache directives. On Nginx or IIS, SHIELD-X can still run PHP-level protections, but server-level rules must be configured at the server or proxy layer.
• It does not scan vendored libraries such as vendor/ or node_modules/ by default.