=== InTouch Integrity Guard ===
Contributors: intouchdesigndev, ikaroweb
Tags: security, file integrity, hardening, brute force, vulnerability
Requires at least: 6.2
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 1.0.2
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

A lightweight file integrity checker, hardening toggles and opt-in known-vulnerability alerts — built to never slow your site down.

== Description ==

**InTouch Integrity Guard** is not a malware scanner and does not try to be one. It does a few focused things, all designed to run in the background without adding weight to a single front-end page load:

* **Incremental file integrity checking.** Compares WordPress core, plugin and theme files against known-good checksums from WordPress.org, and tracks your own file hashes locally so unchanged files are never re-hashed. Everything heavy runs in small batches via WP-Cron — never synchronously on a visitor's request.
* **Optional hardening toggles.** Disable XML-RPC, block the file editor, hide the WordPress version, stop user enumeration (both the classic ?author=N probe and the REST API users endpoint), disable directory listing, send basic security response headers, and reduce automated bot noise against the login page — each one an independent, reversible switch, never forced on.
* **Brute-force login protection.** Blocks an IP after repeated failed logins, with configurable thresholds, backoff and a whitelist — checked with a single indexed query, before WordPress even attempts to verify a password.
* **Opt-in known-vulnerability alerts.** Off by default. If you turn it on, a once-a-day check (never on a page load) compares your installed plugins, themes and core version against a public vulnerability database and emails you a digest if something needs attention. This is the plugin's only feature that contacts a third-party service — see *External services* below.

InTouch Integrity Guard deliberately does not include a heuristic malware/YARA scanner, an always-on web application firewall, or automatic malware removal. If you need those, this is not the right tool — InTouch Integrity Guard is the lightweight layer that watches for unauthorized file changes and closes the easy doors, not a full security suite replacement.

### Features:
* Incremental file integrity index (SHA-256, hash/mtime short-circuit so unchanged files are skipped)
* WordPress.org core and plugin checksum comparison, with orphan/unknown-file detection
* Batched, cron-driven scanning — never a blocking scan on page load
* Independent hardening toggles with automatic backup/restore of any file they touch
* Brute-force login protection with IP whitelist and reverse-proxy-aware IP detection
* A hidden honeypot field on the login form, feeding into the same brute-force protection
* Optional custom login URL, to cut down on automated bot traffic against wp-login.php/wp-admin
* REST API user-enumeration blocking, alongside the classic ?author=N block
* Optional security response headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy)
* Opt-in daily known-vulnerability check (off by default) with a single digest email
* Admin dashboard with an aggregate security score, last-scan status, known vulnerabilities and 24-hour brute-force block count — the score and file-integrity counts refresh live while a scan runs, no manual reload needed
* Flagged-files list — every non-`ok` tracked file (modified, missing or unrecognized) with a paginated view, a read-only file content viewer, a direct link to the official plugin/theme/core source for comparison, and a CSV export for checking the list with external tools
* A commercial plugin sharing its free counterpart's WordPress.org slug (a common pattern — e.g. a Pro edition installed under the free plugin's folder name) is flagged as a likely different edition instead of flooding the list with unexplained "unrecognized" files, and doesn't count against the security score
* Blocked IPs list — every IP currently blocked by brute-force protection, with a one-click unblock and a one-click "add to whitelist"

== External services ==

**Always active (core functionality):**

* **api.wordpress.org** — used to retrieve the official checksum list for the installed WordPress core version, so the integrity scanner can tell an unmodified file from a genuinely changed one. The WordPress version and locale are sent when the checksum list is fetched (then cached locally for 24 hours). No personal or site-identifying data is sent. This host is operated by the WordPress project: [terms / privacy](https://wordpress.org/about/privacy/).
* **downloads.wordpress.org** — used the same way, to retrieve checksums for installed plugins hosted on the WordPress.org Plugin Directory. Only the plugin slug and installed version are sent, and only for plugins that WordPress's own update-check data already lists as wp.org-hosted; premium/custom plugins are never queried. This host is operated by the WordPress project: [terms / privacy](https://wordpress.org/about/privacy/).

**Opt-in, disabled by default:**

* **WPVulnerability API** — used only to check your installed core, active plugins and active theme against a database of known vulnerabilities, and to email the site admin if a match is found.
  * **Endpoint contacted:** `https://www.wpvulnerability.net/` — the public, key-less REST API. The service (API and policies alike) is operated by ROBOTSTXT (Barcelona, Spain); its policy pages are published on the company site `wpvulnerability.com` / `robotstxt.es` and cover this same API.
  * **This is off by default.** No request is made and nothing is scheduled until you explicitly enable it under *InTouch Integrity Guard → Settings → Known-vulnerability check*. You can disable it again at any time, which also clears any stored results.
  * **What is sent, and when:** once every 24 hours, via WP-Cron (never on a front-end page load), the plugin sends the component type (`core`, `plugin` or `theme`), the slug and the installed version number of each active component. No site URL, domain, IP address, admin email or other identifying data is sent, and no account or API key is required. Responses are cached locally for 12 hours.
  * Provider: ROBOTSTXT — [privacy policy](https://www.wpvulnerability.com/privacy/), [terms / legal](https://www.robotstxt.es/legal/), [FAQ](https://www.wpvulnerability.com/faq/).

== Installation ==

1. Upload the plugin files to `/wp-content/plugins/intouch-integrity-guard`, or install directly through the WordPress plugins screen.
2. Activate the plugin through the "Plugins" screen in WordPress.
3. Go to *InTouch Integrity Guard → Settings* to enable the hardening toggles and configure brute-force thresholds; nothing beyond the local integrity scan runs until you turn it on. The known-vulnerability check (the only feature that contacts a third-party service) is off until you opt in on that same screen.

== Frequently Asked Questions ==

= Does InTouch Integrity Guard remove malware? =

No. It tells you which files changed or don't match the official WordPress.org checksums, and lets you decide what to do next. It does not scan file contents for malicious patterns and does not remove anything automatically.

= Does the plugin send my site's data anywhere? =

By default it only contacts api.wordpress.org / downloads.wordpress.org to fetch official checksums (WordPress version and locale, plus wp.org-hosted plugin slugs/versions — no identifying data). The known-vulnerability check that contacts wpvulnerability.net is **off by default** and only runs if you enable it in Settings; see *External services* above for exactly what it sends.

= Will this slow down my site? =

The integrity scan and the optional vulnerability check both run exclusively via WP-Cron, in small batches, and never on a normal front-end page load. Hardening toggles and brute-force checks are lightweight, indexed operations.

= Does this work on WordPress Multisite? =

Multisite is not supported in this version. The plugin will not fatal if activated network-wide, but its functionality is not adapted for a multisite context yet.

= Does changing the login URL actually make my site more secure? =

Be honest with yourself about what this does: it reduces automated bot noise against the standard wp-login.php/wp-admin paths — nothing more. It is **not** a real security boundary. Anyone who wants to find your actual login URL can, by other means, and this does not replace (and is not a substitute for) the brute-force protection above, which is what actually stops credential-guessing attacks. Think of it as cutting down on log noise and drive-by bot traffic, not as locking a door.

This feature is implemented purely as PHP code that runs while the plugin is active — it never writes a rewrite rule or any other change to `.htaccess` or your server configuration. That means deactivating the plugin, or even just removing its files directly (FTP, your host's file manager, without going through the WordPress admin at all), immediately restores the standard wp-login.php/wp-admin URLs on the very next request. There is no separate cleanup step, and no scenario where this feature can lock you out of your own site once the plugin itself is gone.

= My site gets very little traffic — will scans actually run? =

WordPress's built-in "WP-Cron" only fires when someone visits the site, so a low-traffic site can see scans lag behind schedule. The scan cycle is a self-resuming chain — a missed tick just means the next visit (or the next real cron trigger) picks up exactly where it left off, nothing is lost or duplicated — but if you want scans to run on a predictable schedule regardless of traffic, disable WordPress's page-load-triggered cron and drive it with a real system cron job instead:

1. Add `define( 'DISABLE_WP_CRON', true );` to `wp-config.php`.
2. Add a system cron job (via your host's control panel, or crontab) that requests `wp-cron.php` on a schedule, e.g. every 5 minutes:
   `*/5 * * * * curl -s https://yoursite.example/wp-cron.php >/dev/null 2>&1`
   or, if WP-CLI is available on your server:
   `*/5 * * * * cd /path/to/wordpress && wp cron event run --due-now >/dev/null 2>&1`

This is standard WordPress practice, not something specific to this plugin — any WP-Cron-dependent plugin benefits from it on a low-traffic site.

== Screenshots ==

1. Dashboard — aggregate score, last scan status, known vulnerabilities, 24-hour brute-force block count.
2. Settings — hardening toggles, the login honeypot and the optional custom login URL.
3. Settings — brute-force thresholds and IP whitelist, opt-in known-vulnerability check, email digest and scan frequency.
4. Flagged files — the individual modified, missing and unrecognized files behind the dashboard's counts, with a read-only file viewer.
5. Blocked IPs — every IP currently blocked by brute-force protection, with one-click unblock and whitelist actions.

== Changelog ==

= 1.0.2 =
* The known-vulnerability check (WPVulnerability API / wpvulnerability.net) is now strictly opt-in and disabled by default: no request is made and nothing is scheduled until it is enabled in Settings, and disabling it clears any stored results.
* Documented the WPVulnerability API as an external service, including exactly what is sent and links to its privacy policy and terms.
* Removed the redundant load_plugin_textdomain() call (WordPress loads translations for directory-hosted plugins automatically).

= 1.0.1 =
* Initial release: incremental file integrity checking, WordPress.org checksum comparison, hardening toggles (including security headers and REST/author-enumeration blocking), brute-force protection with login honeypot, optional custom login URL, known-vulnerability alerts, a flagged-files list with a read-only file viewer and CSV export, a blocked-IPs list with unblock/whitelist actions, live-updating dashboard stats during a scan, and a "different edition" heuristic so a commercial plugin sharing its free counterpart's slug doesn't flood the flagged-files list or lower the security score.
* Summary email: the periodic digest is an HTML report (with a plain-text alternative part for older clients) — a stat row for the file/vulnerability/brute-force counts, then the individual flagged files grouped by status and tagged with the WordPress core / plugin / theme they belong to (capped per status, with an "…and N more" line), each vulnerable component spelled out with its known-vulnerability titles and reference links, and a footer with a direct link to the dashboard.

== Upgrade Notice ==

= 1.0.2 =
The known-vulnerability check is now opt-in and off by default. If you relied on it, re-enable it under InTouch Integrity Guard → Settings.

= 1.0.1 =
Initial release.
