=== Xerotact SHIELD-X Security ===
Contributors: xerotact
Tags: security, firewall, malware scanner, login security, hardening
Requires at least: 6.5
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 2.0.180
License: GPLv3
License URI: https://www.gnu.org/licenses/gpl-3.0.html

Shared-hosting security with WAF logging, opt-in enforcement, malware scanning, login protection, hardening, backups, and audit tools.

== Description ==

SHIELD-X gives you a clearer way to protect your WordPress site without turning security into a server-admin job. From one workspace, you can see what is happening, spot what needs attention, and take practical next steps with confidence.

Start with the guided Setup Assistant, then choose the protections that fit your site. SHIELD-X is built for everyday WordPress sites and shared hosting: it works with normal WordPress tools, starts conservatively, and lets you review what it finds before you enable stronger actions.

= What you get with SHIELD-X =

* A guided security baseline that helps you get protected quickly.
* A firewall that watches suspicious traffic in Log only mode first, with temporary and permanent blocking available when you are ready.
* Malware, changed-file, database, and vulnerability scans that help you find issues before they become bigger problems.
* Login protection with rate limits, 2FA, human challenges, and recovery controls.
* Practical hardening for safer file access, security headers, and common WordPress attack surfaces.
* Restore points and database backups before important changes, plus clear activity and security-posture views to help you stay in control.

= Extend SHIELD-X when you need more =

SHIELD-X is useful on its own. Optional SHIELD-X add-ons let you extend it as your site and workflow grow:

* **Notifications** sends important security events to the right people through instant alerts or email digests.
* **Cloudflare** audits and, after an administrator reviews the change set, manages a selected Cloudflare zone's edge-security baseline with encrypted API-token storage and rollback snapshots.
* **Pulse** monitors uptime, speed, content changes, traffic, mail, and WordPress cron health.
* **Recovery** adds an isolated recovery workflow for serious incidents and safer full-site restores.
* **Scheduler** automates recurring SHIELD-X tasks with WordPress cron or system cron.
* **Updates** delivers protected SHIELD-X and add-on updates inside WordPress.

= Your data stays with your site =

SHIELD-X stores its security records locally by default. Optional services and add-ons are clearly disclosed 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/.
* **Cloudflare**: If an administrator connects the optional Cloudflare extension, SHIELD-X sends administrator-selected API requests to `https://api.cloudflare.com/client/v4/` using the administrator's restricted Cloudflare API token. Requests can read the selected zone's security settings and rules, and can write only the individually reviewed changes that the administrator applies. The encrypted token, selected-zone metadata, audit records, and encrypted rollback snapshots stay on the WordPress site. SHIELD-X does not send visitor profiler records, WAF logs, scanner findings, backups, restore points, or recovery tokens to Cloudflare. Service information: https://www.cloudflare.com/. Privacy information: https://www.cloudflare.com/privacypolicy/.
* **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.

== Installation ==

1. Upload the `xerotact-shield-x-security` directory to `/wp-content/plugins/`, or install the ZIP from the WordPress Plugins screen.
2. Activate SHIELD-X from the WordPress Plugins screen.
3. Open **SHIELD-X > Setup** in the WordPress admin menu and follow the Setup Assistant.
4. Review the **System** page for PHP extensions, filesystem writability, human challenge settings, file type policy, and configuration portability.
5. Review **Firewall**, **Malware/Virus**, **Login Security**, **Hardening**, and **Lockdown** before enabling enforcement-style controls.

For shared hosting, start with log-only mode and review events before enabling blocking or lockdown actions.

== 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.

== Frequently Asked Questions ==

= Does SHIELD-X require a cloud account? =

No. Core WAF, scanner, hardening, login security, backups, restore points, and logs are local. Vulnerability advisory feeds are optional and configurable by the site administrator.

= Does the WAF block traffic by default? =

No. SHIELD-X is designed to start conservatively. Use log-only mode first, review hits and false positives, then explicitly choose rule actions or enforce mode when you are ready. Matched scores are diagnostic by default; score-threshold challenge/block behavior is an advanced opt-in setting.

= Does the WAF inspect complete request bodies and long headers? =

No. For shared-hosting safety, SHIELD-X inspects a bounded body surface, currently 32 KB by default and configurable up to 128 KB. Login, comment, admin-post/admin-ajax, WooCommerce, and contact form bodies are inspected as redacted key/value text so passwords, nonces, tokens, payment fields, and session fields are not stored. Multipart uploads are inspected through form fields, filenames, MIME types, sizes, and part headers, not binary file contents. Country blocking uses country headers supplied by a trusted proxy or CDN, such as Cloudflare, and does not bundle a GeoIP database.

= Does the WAF run before WordPress loads? =

No. The WordPress.org package is a pure WordPress plugin, so request inspection runs after WordPress begins loading.

= What does SHIELD-X not replace? =

SHIELD-X does not replace host-level malware cleanup, a server firewall, CDN edge protection, off-site backups, or emergency hosting support. It adds WordPress-level monitoring, hardening, recovery, and investigation tools that work inside the permissions available to a WordPress plugin.

= Does SHIELD-X scan vendored libraries inside other plugins? =

No. By default, SHIELD-X skips `wp-content/cache/`, `wp-content/upgrade/`, `wp-content/plugins/xerotact-shield-x-security/`, `node_modules/`, `vendor/` inside plugins and themes, and SHIELD-X private storage under `.shield-x/`.

Vendored libraries should be reviewed by their authors. If you want to inspect a specific vendored path, copy it outside `vendor/` first and run a targeted recheck from the SHIELD-X Scan page.

= Which database content does the scanner inspect? =

The database scanner inspects bounded batches from `wp_options`, recent post/page content, post metadata, comments, administrator accounts, administrator capability metadata, widgets, redirects, and WP-Cron payloads. It is a local security review tool, not a full database export scanner.

= Which files can the scanner skip by design? =

For performance and safe shared-hosting behavior, SHIELD-X skips vendor dependency folders, package caches, generated build folders, upgrade/temp folders, private backup storage, and oversized or unchanged files where metadata proves they did not change since the trusted baseline. This keeps routine scans responsive while focusing deeper checks on new or modified files.

= Does the User Profiler track visitors automatically? =

No. The User Profiler is opt-in. When enabled, it uses a first-party cookie and stores recent request metadata locally for security investigation.

= Can I move SHIELD-X settings to another site? =

No. Settings exports are signed with this site's WordPress auth salts, so they can only be restored on the same WordPress site that created them.

= Can I compare modified WordPress core files with clean copies? =

Yes. The scanner can download the matching official WordPress release archive from WordPress.org for core files and official WordPress.org plugin packages for installed plugins. SHIELD-X uses those hashes to avoid flagging unmodified official files as suspicious.

= Can I use SHIELD-X on shared hosting? =

Yes. SHIELD-X is designed for PHP-only shared hosting. Optional features such as filesystem lockdown depend on host permissions and PHP configuration.

= Can WP-CLI change hardening files? =

Only with explicit confirmation. SHIELD-X hardening writes from WP-CLI require an administrator-gated command and `SHIELDX_CLI_CONFIRM=yes`, so direct `wp eval` calls cannot silently modify `wp-config.php` or `.htaccess`.

= What happens on uninstall? =

SHIELD-X treats plugin delete/reinstall as a maintenance path by default. When WordPress runs the plugin uninstaller, SHIELD-X removes scheduled events and reverts active Lockdown state. It keeps SHIELD-X settings, database findings, audit/activity data, backups, restore points, local logs, and private storage so a plugin upload, replacement, or reinstall does not erase customer data. To remove all SHIELD-X data on plugin deletion, enable **Delete all SHIELD-X data when WordPress deletes the plugin** on **SHIELD-X > Cleanup** before using WordPress' Delete action. The `SHIELDX_PURGE_ON_UNINSTALL` constant remains available for managed deployments.

== 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.

== Screenshots ==

1. Overview dashboard with security posture, security metrics, and attention items.
2. Setup Assistant with completion status and Normal, Extreme, and Panic profile reviews.
3. Hardening controls with stealth protections and the security-measure checklist.
4. Backup workspace with restore points, database backups, and file shadow copies.
5. Pulse monitoring for website, traffic, mail, and WordPress cron health.
6. Scheduler controlling recurring SHIELD-X security and maintenance tasks.

== Changelog ==

= 2.0.180 =

* Reduced private add-on bootstrap file I/O by caching request-local module metadata and avoiding duplicate header reads without bypassing package signature verification.
* Repaired local canonical-domain WP-Cron loopbacks so scheduled security maintenance and threat-intelligence jobs run inside Docker.
* Coalesced database-table cache invalidation writes and replaced repeated admin asset content hashing with lightweight versioned file timestamps.

= 2.0.179 =

* Hardened add-on loading with signed per-file verification before PHP execution.
* Improved WAF engine-error handling, reverse-proxy secure cookies, and context-bound secret encryption with backward-compatible migration.
* Updated security tooling dependencies and strengthened isolated test discovery.

= 2.0.178 =

* Accelerated full backup and isolated restore with adaptive file batches up to 1,000 items, bounded by a 10-second work target, memory headroom, and a 128 MB I/O ceiling.

= 2.0.177 =

* Accelerated full backup and isolated restore with adaptive file batches up to 1,000 items, bounded by a 10-second work target, memory headroom, and a 128 MB I/O ceiling.

= 2.0.176 =

* Accelerated full backup and isolated restore with adaptive file batches up to 1,000 items, bounded by a 10-second work target, memory headroom, and a 128 MB I/O ceiling.

= 2.0.175 =

* Security Trends now moves into its full-width top dashboard position before lazy asset loading begins, so a refresh no longer requires scrolling to make the widget appear.

= 2.0.174 =

* Security Trends now self-heals stale WordPress Dashboard placement data that could leave the widget checked in Screen Options but missing from every dashboard column.

= 2.0.173 =

* Security Trends now render with the WordPress Dashboard instead of waiting for a second admin request, while the initial render stays bounded to indexed daily counters.

= 2.0.172 =

* Accelerated full backup and isolated restore with adaptive file batches up to 1,000 items, bounded by a 10-second work target, memory headroom, and a 128 MB I/O ceiling.
* License checks now allow 20 seconds to connect and retry timeout, DNS, and connection failures through WordPress's alternate Fsockopen transport while preserving TLS verification.

= 2.0.171 =

* Static assets with safe version cache-busters no longer consume the WAF inspection budget; other query strings remain inspected.
* Deferred admin pages now allow slower valid responses to finish before showing a retry option.
* Manual license status checks now contact the license server when a stored key is invalid or expired instead of reporting that the check was skipped.

= 2.0.170 =

* WAF engine budget exhaustion now records an operational warning without blocking visitors; genuine attack-rule matches continue to enforce normally.
* WAF diagnostics now distinguish time-limit exhaustion from pattern-limit exhaustion.

= 2.0.169 =

* Virtual Patch administrative status messages now require a verified redirect.
* Kept the public release history within the WordPress.org parser limit.

= 2.0.168 =

* WAF enforcement now blocks requests when its inspection budget is exhausted, while monitor mode continues to log without blocking.
* Sensitive login, XML-RPC, and user-enumeration rate limits now block when all limiter storage is unavailable.
* Requests to static assets with query strings are inspected before they can bypass the WAF.

= 2.0.167 =

* Accelerated full backup and isolated restore with adaptive file batches up to 1,000 items, bounded by a 10-second work target, memory headroom, and a 128 MB I/O ceiling.

For earlier release history, see the project release history.

== Upgrade Notice ==

= 2.0.175 =

Makes Security Trends appear in its top dashboard position immediately after refresh without requiring a scroll.

= 2.0.174 =

Keeps Security Trends visible when an older or invalid saved dashboard layout places it outside WordPress's supported dashboard columns.

= 2.0.173 =

Loads the Security Trends widget with the Dashboard so administrators no longer wait for a second WordPress request before seeing it.

= 2.0.172 =

Improves backup and restore throughput and lets license checks recover from common cURL connection failures through WordPress's alternate HTTP transport.

= 0.1.0 =

Initial public release. Review settings carefully before enabling blocking or lockdown features.
