Title: TrustSig Security
Author: trustsig
Published: <strong>મે 23, 2026</strong>
Last modified: મે 29, 2026

---

પ્લગીન શોધો

![](https://ps.w.org/trustsig-security/assets/icon-256x256.png?rev=3545156)

# TrustSig Security

 [trustsig](https://profiles.wordpress.org/robertvahhi/) દ્વારા

[ડાઉનલોડ](https://downloads.wordpress.org/plugin/trustsig-security.1.6.1.zip)

 * [વિગતો](https://gu.wordpress.org/plugins/trustsig-security/#description)
 * [સમીક્ષાઓ](https://gu.wordpress.org/plugins/trustsig-security/#reviews)
 *  [સ્થાપન](https://gu.wordpress.org/plugins/trustsig-security/#installation)
 * [ડેવલપમેન્ટ](https://gu.wordpress.org/plugins/trustsig-security/#developers)

 [સપોર્ટ](https://wordpress.org/support/plugin/trustsig-security/)

## વર્ણન

**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, 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.

#### How it works

TrustSig injects a lightweight browser SDK, signs every rendered form with a per-
site secret, and verifies submissions against the TrustSig Edge service. Real visitors
pass an invisible check in about a second; scripted clients that never run JavaScript
are stopped.

When a request arrives without a valid token, TrustSig does not silently fail
 open.
Depending on the mode you choose it serves a lightweight “please wait” interstitial
that re-verifies the browser and then transparently continues the original request—
or blocks it.

The plugin works out of the box with **no account and no API keys** (anonymous
 
free tier). Connecting a TrustSig dashboard account is optional and only adds analytics
and higher limits.

#### Protection modes

 * **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.

#### What it protects

Browser forms are protected automatically with no code:

 * 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)
 * Any other form (site-wide “protect all forms” option, the `[trustsig_form]`
    
   shortcode, or a hidden `trustsig-response` input)

It also includes optional brute-force lockout for repeated failed logins, an
 opt-
in admin-ajax / REST API guard, and a developer verification API.

#### For developers

 * PHP: `trustsig_verify( array( 'token' => $t, 'action' => 'my_form' ) )`
    returns`
   pass` | `fail` | `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 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.

### External services

This plugin relies on the **TrustSig Edge** service to decide whether a request

comes from a human or an automated client. This bot-detection verdict cannot be 
produced locally, so the service is required for the plugin’s core functionality.

**Service provider:** TrustSig — https://trustsig.eu

**Remote script loaded in the browser:**
 https://edge.trustsig.eu/trustsig.js is
loaded on pages that contain a protected form, on the login screen, and on the verification
interstitial. The script runs the non-interactive browser check and produces a verification
token.

**Data sent from the visitor’s browser / 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 (e.g. `example.com`) on the anonymous free tier, or, if
   
   you connect a dashboard account, the secret key you entered;
 * as part of 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) that includes visitor IP addresses, the action
attempted, and the verdict. This data is not sent to TrustSig; you can clear it 
at any time from 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
site’s visitors as required by your local privacy obligations.

 * Terms of Service: https://trustsig.eu/terms-of-service/
 * Privacy Policy: https://trustsig.eu/privacy

## સ્ક્રીનશોટ

 * [[
 * 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.
 * [[
 * Settings: switch between Monitor, Challenge, and Enforce, configure brute-force
   lockout, and link an optional dashboard account.

## સ્થાપન

 1. Upload the `trustsig-security` folder to `/wp-content/plugins/`, or install
     the
    plugin through the WordPress Plugins screen.
 2. Activate the plugin through the ‘Plugins’ menu in WordPress.
 3. Navigate to Settings  TrustSig. Protection is active immediately with no
     further
    configuration.
 4. (Optional) 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 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.

## સમીક્ષાઓ

આ પ્લગઇન માટે કોઈ સમીક્ષાઓ નથી.

## ફાળો આપનાર & ડેવલપર્સ

આ ઓપન સોર્સ સોફ્ટવેર છે. નીચેના લોકો એ આ પ્લગિન માટે ફાળો આપ્યો છે.

ફાળો આપનારા

 *   [ trustsig ](https://profiles.wordpress.org/robertvahhi/)

[“TrustSig Security” ને તમારી ભાષામાં અનુવાદ કરો.](https://translate.wordpress.org/projects/wp-plugins/trustsig-security)

### વિકાસમાં રસ ધરાવો છો?

[કોડ બ્રાઉઝ કરો](https://plugins.trac.wordpress.org/browser/trustsig-security/),
જોવો[અસ્વીએન રેપોઝિટરીમાંથી](https://plugins.svn.wordpress.org/trustsig-security/),
અથવા સબ્સ્ક્રાઇબ કરો[ડેવલપમેન્ટ](https://plugins.trac.wordpress.org/log/trustsig-security/)
દ્વારા[આરઅસઅસ](https://plugins.trac.wordpress.org/log/trustsig-security/?limit=100&mode=stop_on_copy&format=rss).

## ચેન્જલૉગ

#### 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.
 * Hardened cookie handling (HMAC-signed, user-agent anomaly downgrade, revocation).
 * Added the developer verify API and opt-in admin-ajax / 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 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.

#### 1.0.0

 * Initial release.

## મેટા

 *  વર્ઝન **1.6.1**
 *  છેલ્લી અપડેટ: **21 કલાક  પહેલા**
 *  સક્રિય સ્થાપનો: **10 કરતા ઓછા**
 *  વર્ડપ્રેસ વર્ઝન ** 5.0 અથવા ઉચ્ચતર **
 *  **6.9.4** સુધી પરીક્ષણ કર્યું
 *  PHP સંસ્કરણ ** 7.2 અથવા ઉચ્ચતર **
 *  ભાષા
 * [English (US)](https://wordpress.org/plugins/trustsig-security/)
 * ટૅગ્સ:
 * [bot protection](https://gu.wordpress.org/plugins/tags/bot-protection/)[Brute Force](https://gu.wordpress.org/plugins/tags/brute-force/)
   [security](https://gu.wordpress.org/plugins/tags/security/)[spam](https://gu.wordpress.org/plugins/tags/spam/)
   [woocommerce](https://gu.wordpress.org/plugins/tags/woocommerce/)
 *  [વિગતવાર દૃશ્ય](https://gu.wordpress.org/plugins/trustsig-security/advanced/)

## પૉઇન્ટ્સ

હજુ સુધી કોઈ સમીક્ષા સબમિટ કરવામાં આવી નથી.

[Your review](https://wordpress.org/support/plugin/trustsig-security/reviews/#new-post)

[બધા  સમીક્ષાઓ જુઓ](https://wordpress.org/support/plugin/trustsig-security/reviews/)

## ફાળો આપનારા

 *   [ trustsig ](https://profiles.wordpress.org/robertvahhi/)

## સપોર્ટ

કંઈક કહેવું છે? મદદ જોઈએ છે?

 [આધાર ફોરમ જુઓ](https://wordpress.org/support/plugin/trustsig-security/)