Public threats include token guessing, database disclosure, email scanners, replay, CSRF-like unsolicited submission, input abuse, leakage via tracking/referrers and contradictory decisions. Merchant threats include unauthorized changes/exports, CSRF, stored output injection, SQL injection, unsafe state changes, mail flooding and accidental destructive policies.
Each request uses 32 random bytes as seed and an HMAC-SHA256 bearer derived from WordPress auth/secure-auth secrets, order ID and generation with domain-separated input. A separately keyed digest supports indexed lookup. No plaintext bearer is persisted in the request, event or scheduler tables. Workers reconstruct only when composing an authorized message. Database-only access does not reveal usable links; application/server-secret compromise remains a full compromise. Rotating WordPress secrets invalidates old links and order signatures. Review and deliberately re-enroll through a safe operational process if secrets change; do not patch stored hashes blindly.
GET only validates/renders; customer decisions require POST, the bearer, a domain-separated HMAC form challenge valid for current/previous 30-minute bucket, unexpired authority, matching generation/state, and an unchanged order. Challenge is a form-step safeguard rather than identity proof; the bearer is authority. No logged-out WordPress nonce is used for customer authentication. POST replay cannot reverse a terminal decision. Atomic state claims plus connection-owned named locks serialize contradictory decisions and normal WooCommerce CRUD saves. The order guard checks payment method, paid timestamp, safe expected status, exclusion and keyed content signature.
Tokens and challenges require exactly 64 lowercase hexadecimal characters; input/body lengths are bounded. Fixed-window throttling allows 60 requests per minute per directly connected IP, storing only a keyed digest in a two-minute transient. Shared NATs share this limit. Forwarded-IP headers are not trusted; configure edge limits for deployments behind proxies. This application throttle is not a volumetric DDoS defense.
Customer pages use private no-store headers, noindex/nofollow, no-referrer, nosniff, frame denial and a restrictive CSP. They have no third-party resources, tracking pixels or customer-identifying order details. Tokens necessarily appear in the secure form and outgoing email; mail systems and infrastructure may retain URLs. Configure web-server, reverse-proxy, analytics, monitoring and mail logs to redact the token query value. Use HTTPS for both site and administration URLs.
Admin pages/reports require manage_woocommerce. Order operations additionally require edit_shop_orders; this is the store-wide operational permission, not a hardcoded role. All mutations and CSV exports are POST, with capability checks independent of WordPress nonce verification. Settings use the WordPress Settings API with a manage_woocommerce group capability. Output is escaped in its HTML/attribute/URL/textarea context. SQL values are prepared; table identifiers come only from WordPress's controlled prefix. CSV cells prefix potential formula values. No personal data is needed in CSV. Headers are single-line validated and sender addresses checked. Template bodies are plain text.
Audit context has a fixed allowlist of operational fields; it excludes tokens, message bodies, mail addresses, phone numbers, IPs and arbitrary exception dumps. Errors use safe classifications. Staff reasons are sanitized, bounded, privileged data with retention controls. No telemetry, SaaS calls, frontend third-party scripts or commercial runtime provider is included. Standard WordPress/WooCommerce and the site's chosen mail transport remain runtime trust dependencies.
See testing.md for executed negative/security tests and residual validation limits. Report vulnerabilities privately to the distributor or store maintainer; do not publish live verification links or customer records in issues.