When a WordPress user sync system transmits a customer record from one domain to another, it is moving personally identifiable information — names, email addresses, billing details, password hashes — across a network boundary. That transmission happens hundreds or thousands of times per day on an active multi-site network, and every single one of those transmissions is a potential attack surface. A user sync implementation that is not properly secured is not just an engineering oversight — it is an exposure of customer data that GDPR, CCPA, and a growing number of data protection regulations require you to prevent.
Most documentation on WordPress cross-domain user sync treats security as a checkbox: “use HTTPS and it is secure.” This is incomplete in ways that matter. TLS transport encryption prevents passive eavesdropping but does not prevent request forgery. API key authentication prevents unauthorized callers but does not protect against a valid key being replayed with modified payloads. Payload signing using HMAC prevents payload tampering but requires careful key management to remain effective over time. Each security layer addresses a different threat, and a complete implementation requires all of them working correctly together.
This guide provides a systematic treatment of the encryption and authentication layers in cross-domain WordPress user synchronization. It covers what each layer protects against, how it is implemented technically, and how to verify that each layer is functioning correctly in your specific deployment. We cover this in the context of how secure WordPress cross-domain user synchronization with encrypted data transfer implements these protections, with the technical detail that security professionals and senior developers need to evaluate the implementation confidently.
This guide assumes comfort with HTTP request concepts, basic cryptographic terminology, and WordPress REST API fundamentals. It is written for developers and security professionals who need to understand and verify the security properties of their cross-domain sync implementation, not just configure it.
The threat model: what you are actually protecting against
Security design requires a clear threat model — a specification of what attacks you are protecting against and which are outside your scope. Without a threat model, security measures are added based on intuition rather than analysis, and the result is a system that is either under-secured against real threats or over-engineered against implausible ones. For cross-domain WordPress user synchronization, the relevant threat model consists of five distinct attack categories.
A network observer positioned between the master and sub-site (a compromised router, a malicious CDN node, a network monitoring tool) reads the sync request payload and extracts customer data — email addresses, password hashes, billing information. Mitigated by: TLS transport encryption (Layer 1).
An attacker crafts a sync request to a sub-site’s REST API endpoint, creating or modifying user records without authorization — for example, creating an administrator account, elevating a regular user to admin, or corrupting user data. Mitigated by: API key authentication (Layer 2).
An attacker intercepts a valid sync request from the master site, modifies the payload (changing a user’s role, email, or other data), and forwards the modified request to the sub-site. The sub-site sees a valid API key and processes the tampered data. Mitigated by: HMAC payload signing (Layer 3). Note: TLS prevents this in most scenarios, but signing provides defense-in-depth against TLS compromise.
An attacker captures a valid, properly signed sync request and replays it later — either to re-process a stale record (rolling back a user’s role change), to trigger duplicate operations, or to probe the endpoint’s behavior. Mitigated by: Nonce and timestamp validation (Layer 4).
The API key or HMAC shared secret is exposed through a database breach, an inadvertent log entry, an improperly secured configuration file, or an insider threat. With the key, an attacker can generate valid requests indefinitely. Mitigated by: Key rotation procedures, secure key storage, and key scope limitation (covered in the key management section).
Layer 1: TLS transport encryption — the baseline that everything else depends on
TLS (Transport Layer Security) is the protocol that encrypts HTTP communications — when a URL begins with https://, TLS is active. For cross-domain WordPress sync, TLS is not optional — it is the foundation that makes every other security layer meaningful. Without TLS, API keys, HMAC signatures, and nonces are all transmitted in plain text and can be captured by any network observer, completely defeating the security they are meant to provide.
# Check TLS grade for both sites using SSL Labs API curl "https://api.ssllabs.com/api/v3/analyze?host=yoursubsite.com&publish=off" | python3 -m json.tool | grep -E '"grade"|"hasWarnings"' # Verify minimum TLS version (TLS 1.2 minimum; TLS 1.3 preferred) openssl s_client -connect yoursubsite.com:443 -tls1_1 2>&1 | grep "Cipher" # A failed connection to TLS 1.1 is the correct/desired result # Confirm certificate validity and expiry openssl s_client -connect yoursubsite.com:443 2>/dev/null | openssl x509 -noout -dates
TLS protects the sync request while it is in transit across the network. What it does not protect against is an attacker who has access to one of the communicating servers — TLS terminates at the server, and a compromised server sees plaintext. TLS also does not validate that the payload has not been modified by the receiving server or by a TLS-terminating proxy that rewrote the payload before re-encrypting it. This is why payload signing (Layer 3) is a necessary complement to transport encryption rather than a redundant addition.
The sync system must validate the sub-site’s SSL certificate when making API calls — it must not accept invalid, expired, or self-signed certificates with the PHP
CURLOPT_SSL_VERIFYPEER option disabled. A common development convenience — disabling SSL verification to test with local certificates — must never reach production. A sync system that accepts invalid certificates provides no protection against DNS hijacking attacks where a malicious server presents a self-signed certificate for the sub-site’s domain.Layer 2: API key authentication — how shared secrets authenticate the caller
API key authentication answers the question: is this request coming from a party that has been authorized to sync data to this site? The API key is a shared secret — a long, random string known only to the master site and the specific sub-site it was generated for. The master site includes the key in each sync request (typically in a custom HTTP header like X-Sync-Key or as a parameter in a signed payload). The sub-site validates the key before processing any data.
- Caller identity verification — only holders of the correct key can initiate sync operations
- Simple, stateless authentication with no session management overhead
- Per-connection isolation — each connection has its own unique key, limiting blast radius if one key is compromised
- Easy revocation — a compromised key can be invalidated without affecting other connections
- Payload integrity — a valid key does not prove the payload has not been tampered with
- Replay prevention — a captured request with a valid key can be replayed later
- Protection against a compromised key — once stolen, it grants full access until rotated
- Payload confidentiality beyond TLS — if TLS fails, the key and payload are exposed together
A well-implemented API key for cross-domain WordPress sync should have specific properties that maximize its security: it should be generated using a cryptographically secure random number generator (not rand() or mt_rand()), it should be at least 256 bits (32 bytes) of entropy, it should be scoped to a specific connection pair rather than being a single site-wide key, and it should be stored in the WordPress database using wp_hash() rather than as plain text where possible.
// Generate a cryptographically secure 32-byte (256-bit) API key $api_key = bin2hex( random_bytes( 32 ) ); // Produces a 64-character hex string — safe for URL and header transmission // NEVER use these weaker alternatives: // $key = rand() — not cryptographically secure // $key = md5(time()) — predictable and reversible // $key = wp_generate_password(32) — acceptable but random_bytes() is preferred // Validate an incoming key using hash_equals() to prevent timing attacks if ( ! hash_equals( $stored_key, $incoming_key ) ) { wp_send_json_error( 'Invalid API key', 401 ); exit; }
The use of hash_equals() rather than the === operator for key comparison is critical. Standard string comparison in PHP exits as soon as it finds a difference, producing a response time that varies based on how many characters match. An attacker who can measure response times can use this timing difference to guess the key one character at a time — a timing attack. hash_equals() always compares the full string regardless of where the first difference occurs, eliminating the timing channel.
Layer 3: HMAC payload signing — verifying integrity beyond the transport layer
HMAC (Hash-based Message Authentication Code) provides payload integrity verification. While TLS prevents a third party from reading or modifying the payload in transit, HMAC provides proof that the payload was generated by the holder of the shared secret and has not been modified since signing. This is defense-in-depth: even if TLS is somehow compromised or bypassed, a tampered payload will fail HMAC verification and be rejected.
The HMAC signing process is mathematically straightforward: the sender computes HMAC-SHA256(payload, shared_secret) and includes the resulting signature in the request header. The receiver independently computes the same HMAC using their copy of the shared secret and compares it to the signature in the request. If they match, the payload was generated by someone who holds the shared secret and has not been modified since signing. If they do not match, the request is rejected.
// === MASTER SITE: Sign the payload before sending === $payload = json_encode( $user_data ); $timestamp = time(); $nonce = bin2hex( random_bytes( 16 ) ); // Include timestamp and nonce in the signed string to prevent replay $signed_string = $timestamp . '.' . $nonce . '.' . $payload; $signature = hash_hmac( 'sha256', $signed_string, $shared_secret ); // Send in request headers $headers = [ 'X-Sync-Timestamp' => $timestamp, 'X-Sync-Nonce' => $nonce, 'X-Sync-Signature' => $signature, 'Content-Type' => 'application/json', ]; // === SUB-SITE: Verify the signature on receipt === $received_timestamp = $_SERVER['HTTP_X_SYNC_TIMESTAMP']; $received_nonce = $_SERVER['HTTP_X_SYNC_NONCE']; $received_signature = $_SERVER['HTTP_X_SYNC_SIGNATURE']; $received_payload = file_get_contents( 'php://input' ); $expected_signed = $received_timestamp . '.' . $received_nonce . '.' . $received_payload; $expected_signature = hash_hmac( 'sha256', $expected_signed, $shared_secret ); if ( ! hash_equals( $expected_signature, $received_signature ) ) { wp_send_json_error( 'Signature verification failed', 403 ); exit; }
Notice that the timestamp and nonce are included in the signed string, not just the payload. This is essential — if only the payload were signed, a valid signature for one request could be combined with a different timestamp to create a replay attack window. Including the timestamp and nonce in the signed string means that altering either the payload, the timestamp, or the nonce invalidates the signature, and the nonce-based replay protection (Layer 4) is bound to the same signature that protects payload integrity.
Layer 4: Nonce and timestamp validation — preventing replay attacks
A nonce (number used once) is a random value that is included in each request and must not be reused. Combined with a timestamp that specifies when the request was generated, nonce-based replay protection ensures that a captured valid request cannot be replayed successfully — either because the timestamp has expired or because the nonce has already been recorded as consumed.
The sub-site checks that the request timestamp is within an acceptable window of the current server time — typically ±5 minutes, which is 300 seconds. Requests older than 5 minutes are rejected as potentially stale or replayed. This requires the server clocks to be synchronized (NTP) — the same clock skew problem that affects SSO tokens affects nonce-based replay protection.
The sub-site stores each received nonce in a WordPress transient for the duration of the timestamp validity window. When a request arrives, the sub-site checks whether the nonce has been seen before. If it has, the request is rejected as a replay. After the timestamp window expires, the stored nonce can be purged — any replay attempt with that nonce would fail the timestamp check regardless.
$allowed_skew = 300; // 5 minutes in seconds $current_time = time(); // Step 1: Reject requests outside the allowed time window if ( abs( $current_time - $received_timestamp ) > $allowed_skew ) { wp_send_json_error( 'Request timestamp outside acceptable window', 400 ); exit; } // Step 2: Reject if this nonce has been seen before $nonce_key = 'sync_nonce_' . $received_nonce; if ( get_transient( $nonce_key ) !== false ) { wp_send_json_error( 'Nonce already used — possible replay attack', 400 ); exit; } // Step 3: Record the nonce as used for the validity window duration set_transient( $nonce_key, 1, $allowed_skew * 2 ); // Store for 2x the window to ensure expiry overlap coverage
Key management and rotation: maintaining security posture over time
The encryption and signing layers described above are only as strong as the keys that power them. A mathematically perfect HMAC implementation is worthless if the shared secret has been compromised or has not been rotated in three years. Key management is the operational discipline that maintains the security properties of the cryptographic implementation over time.
API keys and HMAC shared secrets should be rotated on a scheduled basis — quarterly is a reasonable default for most deployments, monthly for higher-security contexts. Rotation limits the window of exposure if a key is silently compromised: an attacker who obtained the key three months ago loses their access at the next rotation. Implement rotation as a documented procedure that updates the key on both the master and sub-site simultaneously, not as an ad-hoc activity when a problem is suspected.
When a key compromise is suspected or confirmed — due to a server breach, an accidental log exposure, an employee departure, or any other event that may have exposed the key — emergency revocation must happen immediately, not at the next scheduled rotation. Revoke the key on the sub-site first (making the compromised key immediately invalid), then generate a new key pair through the plugin’s connection management interface, and update the master site’s configuration. Log the revocation event and the reason in your security incident records.
API keys and shared secrets must never appear in application logs, error messages, or debug output. They must never be committed to version control. They should not be stored in wp-config.php in plain text if that file is accessible to version control systems. Best practice is storage in the WordPress database (where they are protected by the database access controls) with the display in admin interfaces limited to a one-time reveal at generation time — the same UX pattern used by GitHub for personal access tokens and AWS for access keys.
Each API key should authorize only the specific operations needed for that connection — user data sync — and nothing else. A key that also authorizes content management operations, settings changes, or administrative actions creates a much larger attack surface than one scoped exclusively to user sync. Implement key scope at the REST API authorization level: the key is valid only for the sync endpoint namespace, not for the full WordPress REST API.
Security verification checklist: confirming each layer is working
Configuring a security layer and verifying it is functioning correctly are different activities. The following checklist provides concrete tests for each security layer. Each test should be run after initial setup and after any significant configuration change.
Security is not a configuration state — it is a continuous practice. The verification tests in this checklist should be run at setup, after any significant plugin update that touches the sync or authentication code, and on a quarterly basis as part of a routine security review. A system that passed all tests six months ago and has not been reviewed since may have developed vulnerabilities through dependency updates, configuration drift, or environmental changes on the hosting platform.
Nexu User Sync’s encrypted WordPress cross-domain user data transfer with HMAC signing and replay protection implements all four security layers described in this guide: TLS enforcement, per-connection API key authentication, HMAC-SHA256 payload signing, and nonce-based replay protection. The verification tests above can be run against any WordPress sync implementation — including this one — to confirm that the security properties are functioning as specified.
User data in transit. Encrypted at every layer. Verifiable at every step.
Nexu User Sync implements TLS transport enforcement, HMAC-SHA256 payload signing, nonce-based replay protection, and per-connection API key isolation — the complete security stack for cross-domain WordPress user synchronization.
Hey, great breakdown on replay attack risks. Just wish the SSL bypass warning stood out more
This plugin finally gave me peace of mind when syncing client data between our main site and subdomains. The API key validation is solid no more stressing over random scripts trying to push fake user data into our system. The only reason I'm not giving it five stars is that key rotation could be a little more automated for the less tech savvy folks on my team. but honestly, security probably shouldn't be too easy, right? Still a really helpful for us
The nonce protection is solid and actually stops replay attacks, which is a big plus for security.