=== TrustSig Security ===
Contributors: robertvahhi
Tags: security, bot protection, brute force, woocommerce, spam
Requires at least: 5.0
Tested up to: 6.9
Requires PHP: 7.2
Stable tag: 1.6.1
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Stop bots, spam and brute-force attacks on every WordPress form. No CAPTCHA. No account. No keys. Installs and protects in one click.

== Description ==

**TrustSig Security protects WordPress forms and API endpoints from scripted bots and brute-force attacks.** No puzzles. No "I am not a robot" checkboxes. No third-party signup required to start. Coverage depends on the protection mode you choose — see "Protection modes" below.

[![Dashboard overview](https://ps.w.org/trustsig-security/assets/screenshot-1.png)](https://ps.w.org/trustsig-security/assets/screenshot-1.png)
[![Per-form protection coverage](https://ps.w.org/trustsig-security/assets/screenshot-2.png)](https://ps.w.org/trustsig-security/assets/screenshot-2.png)
[![Settings: protection modes and brute-force lockout](https://ps.w.org/trustsig-security/assets/screenshot-3.png)](https://ps.w.org/trustsig-security/assets/screenshot-3.png)

= Why TrustSig =

* **Protects every important form out of the box** — login, registration, comments, password reset, WooCommerce checkout, BuddyPress signup, Easy Digital Downloads, Elementor Pro forms, WPForms (including the Mesmerize / Materialis contact form), Contact Form 7, and any custom form via shortcode.
* **Stops brute-force login attempts** with built-in lockout after repeated failures.
* **Invisible to humans** — real visitors are verified in under a second by a non-interactive browser check. No CAPTCHA, no images to click.
* **Three protection modes** — Monitor (log only), Challenge (default, soft block with auto-retry), Enforce (hard block).
* **Zero configuration** — activate the plugin and protection is live immediately. Anonymous free tier needs no account.
* **Works with caching plugins, WPML, multisite and most themes** — forms are signed server-side with a per-site secret.
* **Developer-friendly** — PHP helper `trustsig_verify()`, REST endpoint `/wp-json/trustsig/v1/verify`, filters and actions for custom forms.
* **Optional admin-ajax and REST API guard** for advanced sites.
* **GPLv2** — fully open source.

= How it works =

TrustSig injects a lightweight browser SDK, signs every rendered form with a per-site secret, and verifies submissions against the TrustSig Edge service. Real visitors pass an invisible check in about a second; scripted clients that never run JavaScript are stopped.

When a request arrives without a valid token, TrustSig does not silently fail
open. Depending on the mode you choose it serves a lightweight "please wait"
interstitial that re-verifies the browser and then transparently continues the
original request — or blocks it.

The plugin works out of the box with **no account and no API keys** (anonymous
free tier). Connecting a TrustSig dashboard account is optional and only adds
analytics and higher limits.

= Protection modes =

* **Monitor** — verify and log only, never block. Used for safe rollout; the
  upgrade path also pins existing sites here so behaviour never changes
  silently on update.
* **Challenge** (default for new installs) — a missing or invalid token shows
  the interstitial, then continues or blocks.
* **Enforce** — a missing or invalid token is blocked immediately.

= What it protects =

Browser forms are protected automatically with no code:

* WordPress core — login, registration, comments, lost/reset password
* WooCommerce — login, registration, checkout, pay order, lost password
* BuddyPress — registration
* Easy Digital Downloads — login, registration
* Elementor Pro forms
* WPForms — contact and other forms, on by default (covers the Mesmerize / Materialis contact section)
* Contact Form 7 — feedback submissions, on by default (guarded on the REST endpoint CF7 submits to)
* Any other form (site-wide "protect all forms" option, the `[trustsig_form]`
  shortcode, or a hidden `trustsig-response` input)

It also includes optional brute-force lockout for repeated failed logins, an
opt-in admin-ajax / REST API guard, and a developer verification API.

= For developers =

* PHP: `trustsig_verify( array( 'token' => $t, 'action' => 'my_form' ) )`
  returns `pass` | `fail` | `challenge`. Filters: `trustsig_pre_verify`,
  `trustsig_result`. Action: `trustsig_blocked`.
* REST: `POST /wp-json/trustsig/v1/verify` with `{ "token": "..." }`.

= Known limitations =

* XML-RPC (`xmlrpc.php`) is intentionally out of scope and is not verified.
  Disable XML-RPC separately if it is unused on your site.
* admin-ajax and the REST API are only protected when explicitly enabled in
  Settings, to avoid breaking third-party integrations.
* File-upload and AJAX submissions cannot show the interstitial; under
  Challenge or Enforce mode a missing token on those is blocked, never
  silently allowed.

== External services ==

This plugin relies on the **TrustSig Edge** service to decide whether a request
comes from a human or an automated client. This bot-detection verdict cannot be
produced locally, so the service is required for the plugin's core
functionality.

**Service provider:** TrustSig — https://trustsig.eu

**Remote script loaded in the browser:**
`https://edge.trustsig.eu/trustsig.js` is loaded on pages that contain a
protected form, on the login screen, and on the verification interstitial. The
script runs the non-interactive browser check and produces a verification
token.

**Data sent from the visitor's browser / your server to
`https://edge.trustsig.eu/verify`:**

* the TrustSig verification token generated by the SDK in the visitor's browser;
* your site's host name (e.g. `example.com`) on the anonymous free tier, or, if
  you connect a dashboard account, the secret key you entered;
* as part of any HTTPS request, the visitor's IP address and standard request
  metadata (such as the user-agent) are visible to the service.

**When data is sent:** when the SDK loads on a protected page, when a protected
form is submitted, and once per browser when the optional verified-session
cookie is bootstrapped.

**Data stored locally on your site:** TrustSig writes a verification log to
your own WordPress database (custom tables) that includes visitor IP addresses,
the action attempted, and the verdict. This data is not sent to TrustSig; you
can clear it at any time from Settings → TrustSig → Tools.

By installing and activating this plugin you (the site administrator) consent to
this data being sent to TrustSig so that requests can be verified. Inform your
own site's visitors as required by your local privacy obligations.

* Terms of Service: https://trustsig.eu/terms-of-service/
* Privacy Policy: https://trustsig.eu/privacy

== Installation ==

1. Upload the `trustsig-security` folder to `/wp-content/plugins/`, or install
   the plugin through the WordPress Plugins screen.
2. Activate the plugin through the 'Plugins' menu in WordPress.
3. Navigate to Settings → TrustSig. Protection is active immediately with no
   further configuration.
4. (Optional) Enter your Site Key and Secret Key to link a TrustSig dashboard
   account for analytics and higher limits.

== Frequently Asked Questions ==

= Do I need an account or API keys? =

No. The plugin protects your forms immediately on activation using the
anonymous free tier. An account is only needed for analytics and higher limits.

= What data leaves my site? =

A browser verification token, your site host name (or your secret key if you
connect an account), and standard HTTPS request metadata are sent to the
TrustSig Edge service. See the "External services" section above for the full
disclosure, including links to the Terms of Service and Privacy Policy.

= Will this block real visitors? =

In Challenge mode (the default) a visitor whose token is missing sees a brief
"please wait" page that re-verifies the browser and then continues the original
request automatically. Monitor mode never blocks. Enforce mode is the strictest
and can block visitors with JavaScript disabled.

= Does it work with caching plugins? =

Yes. Forms are signed with a server-issued nonce and the SDK fills the token
client-side, so cached pages are still protected.

= How do I temporarily bypass protection if I lock myself out? =

Settings → TrustSig → Tools shows a private recovery URL that bypasses all
checks once. You can also add your IP to the whitelist.

= Is the plugin GPL? =

Yes, it is licensed GPLv2 or later.

== Screenshots ==

1. TrustSig dashboard overview: protection status, recent verifications, and the current mode at a glance.
2. Protection details: per-form coverage across WordPress core, WooCommerce, BuddyPress, EDD, and Elementor.
3. Settings: switch between Monitor, Challenge, and Enforce, configure brute-force lockout, and link an optional dashboard account.

== Changelog ==

= 1.6.1 =
* Security fix: Elementor Pro form protection now actually fires. The guard was registered on the `elementor_pro/forms/validation` hook inside the protection-hooks loader, which is skipped on admin-ajax requests — and Elementor submits over admin-ajax, so the hook never ran on a real submission. An anonymous tokenless POST to the Elementor form action was not bot-checked unless the broad admin-ajax guard was enabled. Elementor forms are now guarded directly in the request interceptor on their own default-on toggle, mirroring WPForms. Verified browsers pass through; tokenless submissions are blocked.

= 1.6.0 =
* Added first-class Contact Form 7 protection, enabled by default. CF7 submits over the REST route `POST /contact-form-7/v1/contact-forms/<id>/feedback`, which previously was only covered if the broad REST guard was switched on. It is now bot-checked on its own toggle, like WPForms. Only anonymous tokenless submissions are challenged/blocked; verified browsers and any authenticated request pass straight through. Matched narrowly to the submission route, so CF7's other endpoints and unrelated REST traffic are never touched.
* Added a `trustsig_rest_form_guards` filter so integrators can register additional form-plugin REST submission endpoints for default-on protection without enabling the broad REST guard.

= 1.5.0 =
* Added first-class WPForms protection, enabled by default: the contact-form submission (the `wpforms_submit` action used by the Mesmerize / Materialis contact section and any `[wpforms]` embed) is now bot-checked on its own toggle, without having to enable the broad admin-ajax guard. Anonymous tokenless submissions are blocked; a verified browser passes straight through.
* REST API and admin-ajax protection are now scoped to anonymous traffic only. Authenticated requests — logged-in cookie + nonce, Application Passwords, WooCommerce REST API keys and OAuth — defer to WordPress's own authorization. This fixes legitimate API traffic (WooCommerce REST, headless front-ends, server-to-server integrations) being blocked for carrying no browser token, which could cascade into side effects such as order emails not being sent.
* REST verification now runs at dispatch time (`rest_pre_dispatch`), where authentication is resolved, instead of too early on `init`. Only anonymous writes (POST/PUT/PATCH/DELETE) are verified; reads pass through.
* Added route and action allowlists (Advanced → API surface, plus the `trustsig_rest_allowlist` and `trustsig_ajax_allowlist` filters) for unauthenticated-but-legitimate callbacks such as signature-verified payment webhooks.

= 1.4.2 =
* Fixed a false-positive 403 on early theme/app bootstrap requests under API protection: a frontend `lei_ajax_settings=1` settings ping fired before the SDK has loaded (so it can carry no token) is now allowed through. Strictly scoped — only a POST body containing exactly that one field set to "1" and nothing else is exempt; any additional field falls through to the normal guard.

= 1.4.1 =
* Performance: the SDK and bootstrap now load with the native `defer` attribute so they no longer block first paint, plus a preconnect/dns-prefetch hint to the edge so the connection is warmed in parallel with page parsing. Removes the render-blocking penalty without weakening protection — pending submissions still wait for the verifier.

= 1.4.0 =
* Compatibility hardening for caching and performance-optimization stacks. The verification SDK now always loads live from the edge, even when a host aggressively optimizes assets.
* The SDK and bootstrap script tags carry opt-out markers (data-cfasync, data-no-optimize, data-no-minify, data-no-defer, data-no-lazy) so Cloudflare Rocket Loader, WP Rocket, Autoptimize, LiteSpeed, WP Fastest Cache, Perfmatters and SiteGround Optimizer leave them alone instead of minifying, combining, deferring or self-hosting them.
* Added server-side exclusion filters for WP Rocket, SiteGround Optimizer, Perfmatters, Autoptimize and FlyingPress (each a no-op when its plugin is absent).
* Added a client-side self-heal: if the SDK never initialises — e.g. LiteSpeed "Localize Resources", a CDN rewrite, an over-eager optimizer or an ad blocker rehosted or stripped it — the canonical edge source is re-injected automatically. It fires only when nothing loaded, so a working copy is never duplicated.
* Added a trustsig_sdk_url filter so operators can repoint the SDK source (e.g. an intentional proxy) without forking the plugin.

= 1.3.0 =
* New "Discover & bulk-add" picker for the Allowed Domains list — operators with many country / alias domains can pull candidates from WordPress Multisite, WPML and Polylang, or paste a freeform list (newline / comma / space / semicolon separated).
* Allowed-domain entries are normalised on save: scheme, userinfo, port, path and trailing dots are stripped, IDN labels are converted to punycode when the intl extension is available, and IPs / wildcards / single-label hosts are rejected.
* Fresh installs still auto-allow only the main site domain — the picker is opt-in, so the zero-config experience is unchanged.

= 1.2.9 =
* Listing copy: removed emoji bullets and tightened the tagline to reflect actual scope (forms plus opt-in admin-ajax / REST API guard). No behaviour change.

= 1.2.8 =
* Listing rewrite republished: screenshots now show at the top of the description, feature bullets prominent. No behaviour change.

= 1.2.7 =
* Rewrote the wordpress.org listing: tighter marketing copy, feature bullets, and a 3-shot screenshot carousel (dashboard overview, per-form coverage, settings).
* Added a 256×256 plugin icon and 128×128 search-results icon.
* No behaviour change.


= 1.2.6 =
* All front-end and admin scripts/styles are now registered and enqueued via
  wp_enqueue_script/wp_enqueue_style with configuration passed through
  wp_localize_script; no inline script/style is printed in the normal page
  pipeline.
* Fixed the Terms of Service link in the readme.

= 1.2.5 =
* Added the verified-session layer: after a passing scan the browser is trusted
  via a signed cookie with no further edge calls, protecting AJAX/REST globally.
* Added a rate-limited grace window for non-auth APIs during SDK bootstrap.
* Hardened cookie handling (HMAC-signed, user-agent anomaly downgrade, revocation).
* Added the developer verify API and opt-in admin-ajax / REST protection.

= 1.2.0 =
* Enforcement overhaul. Removed the universal fail-open on a missing token.
* Added an HMAC-signed per-site form nonce (auto-generated, works on the free tier).
* Added the interstitial challenge: re-verify and transparently resubmit, or block.
* Added Monitor / Challenge / Enforce policy and configurable edge-down behaviour.
* Decoupled brute-force counting from the token path.
* Safe migration: existing installs upgrade into Monitor with an admin notice.

= 1.0.0 =
* Initial release.

== Upgrade Notice ==

= 1.6.1 =
Security fix: Elementor Pro forms are now actually bot-protected by default. The previous guard never fired on real (admin-ajax) submissions. Update recommended for any site using Elementor Pro forms.

= 1.6.0 =
Adds Contact Form 7 protection, on by default. CF7 submissions (sent over its REST feedback endpoint) are now bot-checked on their own toggle without enabling the broad REST guard. Anonymous spam is blocked; verified browsers and authenticated API calls are unaffected.

= 1.5.0 =
Adds WPForms protection (on by default; covers the Mesmerize / Materialis contact form) and scopes REST / admin-ajax protection to anonymous traffic, so authenticated API calls (WooCommerce REST, Application Passwords, OAuth) are no longer blocked. It is now safe to enable REST / admin-ajax protection alongside API integrations.

= 1.4.2 =
Fixes a false-positive 403 on early `lei_ajax_settings=1` bootstrap requests under API protection. Tightly scoped allowlist — not a general bypass.

= 1.4.1 =
Performance: the SDK and bootstrap now load deferred (non-render-blocking) with a preconnect hint to the edge, removing the render-blocking penalty. No behaviour or configuration change.

= 1.4.0 =
Compatibility hardening for caching / optimization stacks (WP Rocket, LiteSpeed, SiteGround, Perfmatters, Autoptimize, FlyingPress, Cloudflare). The verification SDK now resists being self-hosted, rewritten or stripped and self-heals if it never loads. No configuration change needed.

= 1.3.0 =
Adds a bulk-add picker for the Allowed Domains list (Multisite, WPML, Polylang, or paste). No behaviour change for existing installs — fresh sites still auto-allow only the main domain.

= 1.2.9 =
Listing copy refresh only — no behaviour change.

= 1.2.6 =
Compliance update: scripts and styles are now enqueued the WordPress way. No
behaviour change.

= 1.2.5 =
Adds the verified-session layer and global AJAX/REST coverage. Existing sites
stay in Monitor mode until you opt into enforcement.

= 1.2.0 =
Major enforcement overhaul: missing tokens are no longer silently allowed.
Existing installs upgrade safely into Monitor (logging only) mode.
