TrustSig Security
| 开发者 | robertvahhi |
|---|---|
| 更新时间 | 2026年9月23日 07:27 |
| PHP版本: | 7.2 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
TrustSig Security stops scripted bots and brute-force attacks on WordPress forms and API endpoints. There are no puzzles to solve and no "I am not a robot" checkboxes to tick, and you do not have to sign up for anything before it starts working. What exactly gets checked depends on the protection mode you pick, described below.
Why TrustSig
- Covers the forms that matter out of the box: login, registration, comments, password reset, WooCommerce checkout, BuddyPress signup, Easy Digital Downloads, Elementor Pro forms, WPForms (including the Mesmerize and Materialis contact form), Contact Form 7, SureForms, plus any custom form via a shortcode.
- Locks out brute-force login attempts after repeated failures.
- Real visitors never notice it. The browser check runs on its own and finishes in about a second, with no images to click.
- Three protection modes: Monitor logs and never blocks, Challenge (the default) shows a short interstitial and retries, Enforce blocks outright.
- Nothing to configure. Activate the plugin and protection is live. The anonymous free tier needs no account.
- Works with caching plugins, WPML, multisite and most themes, because forms are signed server-side with a per-site secret.
- A developer API: the PHP helper trustsig_verify(), the REST endpoint /wp-json/trustsig/v1/verify, and filters and actions for custom forms.
- An optional guard for admin-ajax and the REST API on sites that need it.
- An optional scan-on-submit mode that runs the browser check only when a visitor actually uses a form, not on every page view.
- GPLv2, fully open source.
- Monitor: verify and log only, never block. Good for a safe rollout. Upgrades also pin existing sites here, so behaviour never changes silently on update.
- Challenge (default for new installs): a missing or invalid token triggers the interstitial, which then continues or blocks.
- Enforce: a missing or invalid token is blocked immediately.
- WordPress core: login, registration, comments, lost and 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, both AJAX and non-AJAX submissions (this also covers the Mesmerize and Materialis contact section)
- Contact Form 7: feedback submissions, on by default, guarded on the REST endpoint CF7 submits to and on plain POSTs of the form to a page URL
- SureForms: form submissions, on by default, guarded on the REST submit-form endpoint
- Anything else via the site-wide "protect all forms" option, the [trustsig_form] shortcode, or a hidden trustsig-response input
- PHP: trustsig_verify( array( 'token' => $t, 'action' => 'my_form' ) ) returns pass, fail or challenge. Filters: trustsig_pre_verify, trustsig_result. Action: trustsig_blocked.
- REST: POST /wp-json/trustsig/v1/verify with { "token": "..." }.
- XML-RPC (xmlrpc.php) is deliberately out of scope and is not verified. If your site does not use XML-RPC, disable it separately.
- admin-ajax and the REST API are only guarded when you enable that in Settings. This is on purpose, so third-party integrations do not break the moment you install the plugin.
- File uploads and AJAX submissions cannot show the interstitial. In Challenge or Enforce mode a missing token on those is blocked. It is never silently allowed.
安装:
- Upload the trustsig-security folder to /wp-content/plugins/, or install the plugin from the WordPress Plugins screen.
- Activate it from the Plugins menu.
- Open Settings, TrustSig. Protection is already active; there is nothing you have to configure.
- Optionally, enter your Site Key and Secret Key to link a TrustSig dashboard account for analytics and higher limits.
屏幕截图:
常见问题:
Do I need an account or API keys?
No. The plugin protects your forms the moment you activate it, on the anonymous free tier. An account only adds 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 go to the TrustSig Edge service. The "External services" section above has 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 on its own. Monitor mode never blocks. Enforce mode is the strictest and can block visitors who have JavaScript disabled.
Does it work with caching plugins?
Yes. Forms are signed with a server-issued nonce and the SDK fills in the token client-side, so cached pages stay protected.
Does the check run on every page view?
By default, yes: the check runs once when a protected page loads, so the token is ready before any submission. If you would rather not verify visitors who never touch a form, turn on "Scan on submit only" under Advanced, Scan timing. The check then runs at the first interaction with a form, or at submission, in which case the submission is held for about a second, verified, and continued automatically. Protection is the same either way.
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, GPLv2 or later.
更新日志:
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
_wpcf7field, WPForms viawpforms[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.
- Tested against WordPress 7.0.
- 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.
- "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.
- 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.
- 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.
- API keys now sit behind an explicit "Use a TrustSig.eu project" checkbox, off by default. While it is off the Site Key and Secret Key inputs are fully disabled, so the browser or a 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. Tick 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 stay fully protected through the per-submission token. Turn verified session on only if you want the cookie-based fast path for AJAX and REST.
- 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, so it errored out and rejected every domain. Domains now save and persist correctly, and scheme, path and port in a pasted URL are stripped as intended.
- Added first-class SureForms protection, on by default. SureForms submits over the REST route POST /sureforms/v1/submit-form, which used to be covered only if the broad REST guard was switched on. It now gets 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 submissions without a token are challenged or blocked; verified browsers and authenticated requests pass straight through.
- Hardened the Site Key and 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 and password, and 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 and 1Password opt-outs. These are API keys for the optional dashboard and are 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 by navigating away before saving. An empty list still means "allow all", the zero-config default.
- 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. Elementor submits over admin-ajax, so the hook never ran on a real submission, and 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.
- Added first-class Contact Form 7 protection, on by default. CF7 submits over the REST route POST /contact-form-7/v1/contact-forms//feedback, which used to be covered only if the broad REST guard was switched on. It now gets bot-checked on its own toggle, like WPForms. Only anonymous submissions without a token are challenged or blocked; verified browsers and authenticated requests pass straight through. The match is narrow, on the submission route only, 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.
- Added first-class WPForms protection, on by default: the contact-form submission (the wpforms_submit action used by the Mesmerize and Materialis contact section and any [wpforms] embed) now gets 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 plus nonce, Application Passwords, WooCommerce REST API keys, OAuth) defer to WordPress's own authorization. This fixes legitimate API traffic such as WooCommerce REST, headless front-ends and server-to-server integrations being blocked for carrying no browser token, which could cascade into side effects like order emails not being sent.
- REST verification now runs at dispatch time (rest_pre_dispatch), where authentication has been 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.
- Fixed a false-positive 403 on early theme and 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. The exemption is strictly scoped: only a POST body containing exactly that one field set to "1" and nothing else qualifies; any additional field falls through to the normal guard.
- Performance: the SDK and bootstrap now load with the native defer attribute, so they no longer block first paint, plus a preconnect and dns-prefetch hint to the edge so the connection is warmed while the page is still parsing. Removes the render-blocking penalty without weakening protection; pending submissions still wait for the verifier.
- 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, for example because 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 (for example to an intentional proxy) without forking the plugin.
- New "Discover & bulk-add" picker for the allowed-domains list. Operators with many country or alias domains can pull candidates from WordPress Multisite, WPML and Polylang, or paste a freeform list separated by newlines, commas, spaces or semicolons.
- 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 and 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.
- Listing copy: removed emoji bullets and tightened the tagline to reflect actual scope (forms plus the opt-in admin-ajax and REST API guard). No behaviour change.
- Listing rewrite republished: screenshots now show at the top of the description, feature bullets prominent. No behaviour change.
- Rewrote the wordpress.org listing: tighter copy, feature bullets, and a three-shot screenshot carousel (dashboard overview, per-form coverage, settings).
- Added a 256x256 plugin icon and a 128x128 search-results icon.
- No behaviour change.
- All front-end and admin scripts and styles are now registered and enqueued via wp_enqueue_script and wp_enqueue_style, with configuration passed through wp_localize_script. No inline script or style is printed in the normal page pipeline.
- Fixed the Terms of Service link in the readme.
- Added the verified-session layer: after a passing scan the browser is trusted via a signed cookie with no further edge calls, protecting AJAX and REST globally.
- Added a rate-limited grace window for non-auth APIs during SDK bootstrap.
- Hardened cookie handling: HMAC-signed, downgraded on user-agent anomalies, revocable.
- Added the developer verify API and opt-in admin-ajax and REST protection.
- 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 the Monitor, Challenge and 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.
- Initial release.