Title: TrustSig Security Author: trustsig Published: May 23, 2026 Last modified: July 19, 2026 --- Search plugins ![](https://ps.w.org/trustsig-security/assets/icon-256x256.png?rev=3545156) # TrustSig Security By [trustsig](https://profiles.wordpress.org/robertvahhi/) [Download](https://downloads.wordpress.org/plugin/trustsig-security.1.8.2.zip) * [Details](https://mri.wordpress.org/plugins/trustsig-security/#description) * [Reviews](https://mri.wordpress.org/plugins/trustsig-security/#reviews) * [Installation](https://mri.wordpress.org/plugins/trustsig-security/#installation) * [Development](https://mri.wordpress.org/plugins/trustsig-security/#developers) [Support](https://wordpress.org/support/plugin/trustsig-security/) ## Description 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. #### How it works TrustSig loads a small browser SDK, signs every rendered form with a per-site secret, and checks submissions against the TrustSig Edge service. A real visitor passes the check in about a second without doing anything. A scripted client that never runs JavaScript produces no token and gets stopped. When a request arrives without a valid token, the plugin does not quietly wave it through. Depending on the mode, it either serves a short “please wait” page that re-verifies the browser and then continues the original request, or blocks it. No account and no API keys are needed; the anonymous free tier is the default. Connecting a TrustSig dashboard account is optional and only adds analytics and higher limits. #### Protection modes * 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. #### What it protects Browser forms are covered automatically, no code needed: * 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 (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 * 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 On top of that there is an optional brute-force lockout for repeated failed logins, an opt-in guard for admin-ajax and the REST API, and a verification API for developers. #### For developers * 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”: “…” }. #### Known limitations * 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. ### External services This plugin relies on the TrustSig Edge service to decide whether a request comes from a human or an automated client. That verdict cannot be produced locally, so the service is required for the plugin to do its job. Service provider: TrustSig, https://trustsig.eu Remote script loaded in the browser: https://edge.trustsig.eu/trustsig.js loads on pages that contain a protected form, on the login screen, and on the verification interstitial. It runs the non-interactive browser check and produces a verification token. Data sent from the visitor’s browser or 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 (for example example.com) on the anonymous free tier, or the secret key you entered if you connect a dashboard account; * as with 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) with visitor IP addresses, the action attempted, and the verdict. This log is not sent to TrustSig, and you can clear it at any time under 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 visitors as your local privacy obligations require. * Terms of Service: https://trustsig.eu/terms-of-service/ * Privacy Policy: https://trustsig.eu/privacy ## Screenshots [⌊TrustSig dashboard overview: protection status, recent verifications, and the current mode at a glance.⌉⌊TrustSig dashboard overview: protection status, recent verifications, and the current mode at a glance.⌉[ TrustSig dashboard overview: protection status, recent verifications, and the current mode at a glance. [⌊Protection details: per-form coverage across WordPress core, WooCommerce, BuddyPress, EDD, and Elementor.⌉⌊Protection details: per-form coverage across WordPress core, WooCommerce, BuddyPress, EDD, and Elementor.⌉[ Protection details: per-form coverage across WordPress core, WooCommerce, BuddyPress, EDD, and Elementor. [⌊Settings: switch between Monitor, Challenge, and Enforce, configure brute-force lockout, and link an optional dashboard account.⌉⌊Settings: switch between Monitor, Challenge, and Enforce, configure brute-force lockout, and link an optional dashboard account.⌉[ Settings: switch between Monitor, Challenge, and Enforce, configure brute-force lockout, and link an optional dashboard account. ## Installation 1. Upload the trustsig-security folder to /wp-content/plugins/, or install the plugin from the WordPress Plugins screen. 2. Activate it from the Plugins menu. 3. Open Settings, TrustSig. Protection is already active; there is nothing you have to configure. 4. Optionally, enter your Site Key and Secret Key to link a TrustSig dashboard account for analytics and higher limits. ## FAQ ### 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. ## Reviews ![](https://secure.gravatar.com/avatar/4099501c3d305a6603f5255ebe34cebb48990a96076193df7304b421de0cce5b? s=60&d=retro&r=g) ### 󠀁[Easy setup and spam stopped](https://wordpress.org/support/topic/easy-setup-and-spam-stopped/)󠁿 [veebiekspert](https://profiles.wordpress.org/veebiekspert/) June 4, 2026 Deployment was easy, I am not tech savy but was able to get it running in less than a minute. I always had constant email spam from my site, after installing TrustSig it dropped to zero. 10/10 [ Read all 1 review ](https://wordpress.org/support/plugin/trustsig-security/reviews/) ## Contributors & Developers “TrustSig Security” is open source software. The following people have contributed to this plugin. Contributors * [ trustsig ](https://profiles.wordpress.org/robertvahhi/) [Translate “TrustSig Security” into your language.](https://translate.wordpress.org/projects/wp-plugins/trustsig-security) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/trustsig-security/), check out the [SVN repository](https://plugins.svn.wordpress.org/trustsig-security/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/trustsig-security/) by [RSS](https://plugins.trac.wordpress.org/log/trustsig-security/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 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. #### 1.7.2 * 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. #### 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, 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. #### 1.7.0 * 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. #### 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. 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. #### 1.6.0 * 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. #### 1.5.0 * 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. #### 1.4.2 * 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. #### 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 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. #### 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, 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. #### 1.3.0 * 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. #### 1.2.9 * 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. #### 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 copy, feature bullets, and a three- shot screenshot carousel (dashboard overview, per-form coverage, settings). * Added a 256×256 plugin icon and a 128×128 search-results icon. * No behaviour change. #### 1.2.6 * 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. #### 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 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. #### 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 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. #### 1.0.0 * Initial release. ## Meta * Version **1.8.2** * Last updated **21 hours ago** * Active installations **10+** * WordPress version ** 5.0 or higher ** * Tested up to **6.9.5** * PHP version ** 7.2 or higher ** * Language * [English (US)](https://wordpress.org/plugins/trustsig-security/) * Tags * [bot protection](https://mri.wordpress.org/plugins/tags/bot-protection/)[Brute Force](https://mri.wordpress.org/plugins/tags/brute-force/) [security](https://mri.wordpress.org/plugins/tags/security/)[spam](https://mri.wordpress.org/plugins/tags/spam/) [woocommerce](https://mri.wordpress.org/plugins/tags/woocommerce/) * [Advanced View](https://mri.wordpress.org/plugins/trustsig-security/advanced/) ## Ratings 5 out of 5 stars. * [ 1 5-star review ](https://wordpress.org/support/plugin/trustsig-security/reviews/?filter=5) * [ 0 4-star reviews ](https://wordpress.org/support/plugin/trustsig-security/reviews/?filter=4) * [ 0 3-star reviews ](https://wordpress.org/support/plugin/trustsig-security/reviews/?filter=3) * [ 0 2-star reviews ](https://wordpress.org/support/plugin/trustsig-security/reviews/?filter=2) * [ 0 1-star reviews ](https://wordpress.org/support/plugin/trustsig-security/reviews/?filter=1) [Your review](https://wordpress.org/support/plugin/trustsig-security/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/trustsig-security/reviews/) ## Contributors * [ trustsig ](https://profiles.wordpress.org/robertvahhi/) ## Support Got something to say? Need help? [View support forum](https://wordpress.org/support/plugin/trustsig-security/)