Xerotact SHIELD-X Security

SHIELD-X helps you protect and maintain a WordPress site from one clear workspace. It brings firewall monitoring, security scans, login protection, hardening, backups, and activity review together so you can see what needs attention and act with confidence.

Start with the guided Setup Assistant, then enable the protections that suit your site. SHIELD-X is designed for shared hosting and everyday site owners, so it works with normal WordPress tools and does not require a server daemon or command-line access.

Protect your site

• Watch suspicious traffic with a firewall that starts in Log only mode, then choose temporary or permanent blocking when you are ready.
• Find malware, changed files, database issues, and known software vulnerabilities.
• Strengthen logins with rate limiting, 2FA, human challenges, and recovery controls.
• Apply practical WordPress hardening, including security headers, safer file access, and common attack-surface protections.
• Create restore points and database backups before important changes, then review and restore them from SHIELD-X.
• Review security events, scan results, and security posture from the dashboard.

Your data stays with your site

SHIELD-X stores its security records locally by default. Optional services are clearly disclosed below and are used only when an administrator enables or uses the matching feature.

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.

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.