TrustSig Security
| 开发者 | robertvahhi |
|---|---|
| 更新时间 | 2026年6月2日 08:23 |
| PHP版本: | 7.2 及以上 |
| WordPress版本: | 6.9 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
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.
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, SureForms, 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.
- 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.
- 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)
- SureForms — form submissions, on by default (guarded on the REST submit-form endpoint)
- Any other form (site-wide "protect all forms" option, the
[trustsig_form]shortcode, or a hiddentrustsig-responseinput)
- PHP:
trustsig_verify( array( 'token' => $t, 'action' => 'my_form' ) )returnspass|fail|challenge. Filters:trustsig_pre_verify,trustsig_result. Action:trustsig_blocked. - REST:
POST /wp-json/trustsig/v1/verifywith{ "token": "..." }.
- 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.
安装:
- Upload the
trustsig-securityfolder to/wp-content/plugins/, or install the plugin through the WordPress Plugins screen. - Activate the plugin through the 'Plugins' menu in WordPress.
- Navigate to Settings → TrustSig. Protection is active immediately with no further configuration.
- (Optional) 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 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.
更新日志:
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.
- 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).
- 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.)
- Security fix: Elementor Pro form protection now actually fires. The guard was registered on the
elementor_pro/forms/validationhook 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.
- 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_guardsfilter 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, enabled by default: the contact-form submission (the
wpforms_submitaction 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 oninit. Only anonymous writes (POST/PUT/PATCH/DELETE) are verified; reads pass through. - Added route and action allowlists (Advanced → API surface, plus the
trustsig_rest_allowlistandtrustsig_ajax_allowlistfilters) for unauthenticated-but-legitimate callbacks such as signature-verified payment webhooks.
- Fixed a false-positive 403 on early theme/app bootstrap requests under API protection: a frontend
lei_ajax_settings=1settings 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.
- Performance: the SDK and bootstrap now load with the native
deferattribute 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.
- 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.
- 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.
- 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.
- Listing rewrite republished: screenshots now show at the top of the description, feature bullets prominent. No behaviour change.
- 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.
- 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.
- 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.
- 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.
- Initial release.