Fixed an availability gap: a TrustSig edge/CDN outage no longer takes your forms down. When the edge is unreachable the verification SDK cannot load, so a real visitor submits with no token — and that path previously always challenged or blocked, ignoring your “Edge unreachable” fallback. It now honours the Edge fallback policy (default: allow / fail-open) whenever the request carries a valid server-signed nonce (proof of a real rendered form) and the edge is confirmed down by a short, cached health probe. A request that is both tokenless and nonceless (a blind bot) still gets no grace. Monitor still never blocks.
Security: the settings Export no longer includes secret material — the site signing secret (which signs page nonces and verified-session cookies), the recovery key, and the dashboard Secret Key are stripped from the downloaded file. Importing settings still works; each site keeps its own secrets.
WooCommerce block-based checkout (the modern default, served over the Store API POST /wc/store/v1/checkout) is now covered by the existing “WooCommerce → Checkout” toggle. Previously only the classic shortcode checkout was protected, and turning on the broad REST guard could block guest block-checkout. The token rides on the checkout request via the SDK’s “Token on XHR/fetch” option (on by default). Only anonymous tokenless submissions are challenged/blocked; logged-in customers and authenticated requests pass straight through.
Brute-force lockout now counts genuine failed logins (wrong username/password from a browser that passed the bot check), not only TrustSig token-blocks — so the lockout actually defends against password guessing and credential stuffing. No double-counting of TrustSig’s own blocks. (Only active when Brute-Force protection is enabled, which is off by default.)
1.7.2
API keys are now behind an explicit “Use a TrustSig.eu project” checkbox, off by default. While it’s off the Site Key and Secret Key inputs are fully disabled — so the browser/password manager can no longer autofill your site login into them (a wrong Site Key was breaking the browser check) — and any stored key is ignored everywhere: the SDK runs on the anonymous free tier and nothing is sent to the verify endpoint. Enable the box only to link a dashboard account.
Verified session is now off by default, so the plugin sets no cookie out of the box. Forms remain fully protected via the per-submission token; turn Verified session on only if you want the cookie-based fast path for AJAX/REST.
1.7.1
Fixed: the allowed-domains list saved empty every time, so domains “disappeared” on save. The domain normaliser used a regex whose delimiter clashed with a character in its own pattern; it errored out and rejected every domain. Domains now save and persist correctly (and scheme/path/port in a pasted URL are stripped as intended).
1.7.0
Added first-class SureForms protection, enabled by default. SureForms submits over the REST route POST /sureforms/v1/submit-form, which previously was only covered if the broad REST guard was switched on. It is now bot-checked on its own toggle, like Contact Form 7 and WPForms. The token rides in the form’s own multipart payload, so no shortcode is needed. Only anonymous tokenless submissions are challenged/blocked; verified browsers and any authenticated request pass straight through.
Hardened the Site Key / Secret Key fields against browser and password-manager autofill. The Secret Key is a masked field, so Chrome could treat it as a login password and silently inject the saved site username/password — a wrong Site Key then broke the verification SDK (“could not verify this browser”). The fields are now held read-only until focused and carry explicit autocomplete / LastPass / 1Password opt-outs. Note: these are API keys for the optional dashboard, never required on the free tier.
Allowed domains now save the instant a domain is added or removed, instead of only on the main Save. The list could previously be lost if you navigated away before saving. (An empty list still means “allow all” — the zero-config default.)
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.
