Security model

Trust boundary

The browser can request and display a TrueSift challenge, but it is not an authority for the protected business action. Only the opaque verificationToken is accepted as client-controlled proof input.

The plugin signs action, path, and origin into a short-lived WordPress context token. PHP validates that signature and sends the resulting server-owned expectations together with the site key, secret key, and verification token to TrueSift's authoritative proof endpoint.

Accepted proof

A normal proof is accepted only when the TrueSift response confirms all of the following:

• allowed is true;
• decision is allow;
• one-time consumption is confirmed by consumed: true or a non-empty consumedAt;
• challenge ID, action, and origin are present;
• returned action, path, and origin match the signed WordPress context.

Invalid, expired, replayed, mismatched, reviewed, and blocked proofs never use fail-open.

Availability policy

Only the saved server-side fail_open setting or the TRUESIFT_FAIL_OPEN constant can permit a protected action when the proof service is temporarily unavailable. A browser field named failOpen is ignored.

The browser submit control still requires an issued verification token. Therefore a browser challenge or verify failure does not unlock the form merely because server-side fail-open is enabled.

Credentials

• The site key and secret key never appear in frontend configuration.
• The secret key is stored encrypted with Sodium secretbox when available.
• OpenSSL AES-256-GCM is used as a fallback.
• wp-config.php constants can be used instead of database storage.
• Logs never include credentials or complete verification tokens.
• HTTP certificate verification is never disabled.

Reporting a vulnerability

Do not publish security issues in a public support topic. Report them through the security contact listed at:

mailto:info@webdigitech.de