TrustSig Security

1.8.5

• Fixed Contact Form 7 and WPForms spam getting through unchecked. Both plugins also accept a plain POST of the form to any page URL (CF7 via the _wpcf7 field, WPForms via wpforms[id]) and process it before the page loads. TrustSig only guarded their REST and AJAX endpoints, so bots that replay the rendered HTML form were never checked and never logged. These submissions are now verified on the same Contact Form 7 and WPForms toggles.
• Fixed saving settings from AJAX switching every optional setting on. Adding or removing an allowed domain, dismissing the upgrade notice, regenerating the recovery key or importing a settings file re-ran the settings sanitizer over the stored values, which treated any present flag as enabled, including ones stored as off. That enabled protect all forms, AJAX and REST protection, scan on submit and the verified session, which blocked anonymous AJAX and REST traffic while logged-in users were exempt. Sites that show the full pattern are reset to the defaults once on upgrade, with an admin notice.
• Fixed AJAX form plugins submitting without a token. The bootstrap now holds the submission before Contact Form 7, WPForms or WooCommerce serialize the form, and releases it through the plugin’s own submit handler once the token is in place. Previously the plugin had already sent its request with an empty token, and the bootstrap then fired a second, full-page submission that also dropped the clicked button’s name, which WooCommerce login and registration need.
• A token older than four minutes is now refreshed before submission in the default mode as well, so a visitor who spends a while filling in a form is not rejected for an expired token.
• Each submission now carries its own token. After an AJAX form is sent (for example a Contact Form 7 form that came back with a validation error), the next interaction with the form starts a new scan, so the resubmission does not reuse the spent token.
• Pages served from a full-page cache no longer carry an expired form nonce. The bootstrap requests a fresh one when the cached value is close to expiry.
• Blocked Contact Form 7 submissions now show the form’s own spam message instead of a generic error.
• Search forms and other GET forms no longer get TrustSig fields appended to their URLs.
• An admin notice now warns when the site’s domain is missing from the allowed domains list, which turns protection off.
• The verification log is pruned after 30 days (filter trustsig_log_retention_days). The total count on the dashboard still includes pruned rows.

1.8.4

• Tested against WordPress 7.0.

1.8.3

• Fixed protection silently going dead on sites that combine scripts. WP-Optimize’s minify merges the verification SDK into a local bundle and emits it as a bare tag without the configuration attributes, so the SDK was present but never initialized and every scan hung: real visitors submitted with no token and were sent to the interstitial. The bootstrap now detects that state and re-initializes the SDK in place instead of injecting a second copy, and both TrustSig scripts are excluded from WP-Optimize’s minify.

1.8.1

• “Scan on submit only” now really loads nothing on a page view. It previously skipped the scan but still loaded the verification script, which booted its sandbox, fetched its WASM and ran a key handshake on every page, so the mode saved almost nothing. The script tag is no longer printed at all in this mode: a visitor who never touches a form causes no request to TrustSig, and the preconnect hint is dropped to a DNS hint so no connection is opened either. The bootstrap injects the script at the first form interaction. The trade-off is that the first submission on a page now waits for a cold start, so the window a held submission is given was widened from 8 to 12 seconds.
• Fixed “Scan on submit only” never producing a token. The bootstrap called the verification SDK through the wrong global name, which went unnoticed in the default mode because the SDK scans by itself there. With scan-on-submit on, that call is the only thing that starts a scan, so nothing ever ran: every submission was released without a token and routed to the verification interstitial.
• Fixed the verification interstitial loading the SDK with a stored Site Key even when “Use a TrustSig.eu project” was off. Every other page correctly used the anonymous key, so a leftover or autofilled key only broke the interstitial: the browser check requested a project the edge does not know, no token could be produced, and the visitor was blocked once the challenge retries ran out.
• A degraded scan result is no longer submitted or verified as if it were a token. It cannot be decoded, so verification returned no verdict and the request took the ambiguous path, re-challenging until the visitor was blocked. It is now treated as no token, which is what the nonce-gated fallback (including the edge-unreachable fail-open) is there to handle.
• In scan-on-submit mode a token older than four minutes is now discarded and re-verified when a form is submitted, instead of posting a token the edge would reject as expired.

1.8.0

• New optional scan timing mode, “Scan on submit only” (Advanced, Scan timing; off by default). Normally the SDK verifies the browser once per page load so the token is ready before any submission. With this mode on, the SDK loads with auto-scan disabled and nothing runs for visitors who never touch a form. The check starts at the first interaction inside a form, and a submission that arrives before a token exists is held, verified, then continued automatically. The held submission is re-dispatched through requestSubmit, so form plugins’ own submit handlers (WPForms, Contact Form 7, Elementor) still run and the clicked button’s name and value are preserved. The interaction trigger also covers fetch-driven flows such as the WooCommerce block checkout, which never fire a native submit event. Background verified-session re-scans are skipped in this mode, and the challenge interstitial still verifies immediately. Default behaviour is unchanged.

1.7.3

• Fixed an availability gap: an outage of the TrustSig edge or its CDN no longer takes your forms down with it. When the edge is unreachable the verification SDK cannot load, so a real visitor submits without a token, and that path used to challenge or block regardless of your “Edge unreachable” fallback setting. The fallback (allow by default) is now honoured whenever the request carries a valid server-signed nonce, which proves the form was really rendered, and a short cached health probe confirms the edge is down. A request with neither token nor nonce is a blind bot and still gets no grace. Monitor mode still never blocks.
• Security: the settings export no longer contains 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. Import still works, and each site keeps its own secrets.
• The WooCommerce block checkout (the modern default, submitted over the Store API at POST /wc/store/v1/checkout) is now covered by the existing WooCommerce Checkout toggle. Previously only the classic shortcode checkout was protected, and enabling the broad REST guard could block guest checkout. The token travels with the checkout request through the SDK’s “Token on XHR/fetch” option, which is on by default. Only anonymous submissions without a token are challenged or blocked; logged-in customers and authenticated requests pass straight through.
• Brute-force lockout now counts genuine failed logins (wrong username or password from a browser that passed the bot check) instead of only TrustSig’s own token blocks, so it actually defends against password guessing and credential stuffing. TrustSig blocks are not double-counted. Only active when brute-force protection is enabled, which is off by default.