When a WordPress user sync plugin transmits a user record from your master site to a connected sub-site, that transmission travels across a network. Depending on your hosting configuration, it may cross the public internet. It contains personal data — email addresses, names, billing information, password hashes. The security of that transmission depends on the cryptographic layer protecting it: the TLS configuration of the HTTPS connection, the authentication mechanism that validates the receiving site’s identity, the payload signing that prevents tampering in transit, and the key management practices that ensure those cryptographic controls remain effective over time.
Most WordPress administrators configure user sync, confirm that it works, and assume the security is handled. This assumption is often correct in broad terms — modern sync plugins use HTTPS and API key authentication by default. But “broadly correct” is not the same as “auditably secure.” The difference matters when you are asked to demonstrate your data protection posture to a compliance auditor, when you are assessing a security incident to determine whether user data was exposed in transit, or when you are reviewing a hosting configuration change and need to know whether it has affected your sync security properties.
This guide covers the cryptographic layer of WordPress user sync in the depth that security-conscious administrators need. It examines how OpenSSL and TLS protect sync traffic in WordPress environments, what HMAC-based payload signing adds above TLS, how to audit your current sync security configuration, and what a security-strong implementation looks like. We cover this in the context of how WordPress user sync with encrypted cross-site data transfer and OpenSSL-secured connections implements these protections.
This guide assumes comfort with command-line tools and security concepts at the level of a systems administrator or senior WordPress developer. It does not require cryptography expertise — we explain the relevant concepts as they arise — but it is not a beginner’s guide to website security.
The encryption stack for WordPress user sync: what protects your data in transit
WordPress user sync between connected sites typically uses the WordPress REST API as its transport mechanism. An HTTP POST request carrying the user record payload travels from the master site to the sub-site’s REST endpoint. The security of this transmission depends on three distinct layers, each addressing a different threat. Understanding what each layer protects against — and crucially, what it does not protect against — is the foundation of an accurate security assessment.
A sync implementation that has all three layers correctly configured is well-protected against the realistic threat model for cross-site WordPress data transmission. Each layer addresses a different attack vector. Weaknesses in any individual layer reduce the overall protection even when the other layers are strong. The security audit process described later in this guide verifies each layer independently.
OpenSSL and TLS in WordPress REST API calls: the technical reality
When WordPress makes an outbound HTTPS request — as the sync plugin does when pushing user data to a sub-site — it uses the WP_HTTP class, which calls either cURL or the PHP stream context depending on which is available. Both use OpenSSL for TLS negotiation. The security properties of this TLS connection depend on the OpenSSL version installed on the server, the TLS version and cipher suites that OpenSSL is configured to use, and whether the receiving server’s SSL certificate is properly validated.
This last point — certificate validation — is where many WordPress implementations have a significant security gap. By default, WordPress’s wp_remote_post() function validates SSL certificates using the certificate bundle that ships with WordPress. But several common configurations disable this validation entirely: some sync plugins include a 'sslverify' => false option for debugging purposes and leave it in production, some hosting environments set CURLOPT_SSL_VERIFYPEER to false globally, and some administrators disable SSL verification to resolve connection errors without understanding the security consequence.
// This is the CORRECT configuration — SSL verification enabled $response = wp_remote_post( $sub_site_url, [ 'body' => json_encode( $user_payload ), 'headers' => [ 'Content-Type' => 'application/json' ], 'sslverify' => true, // Must be true in production 'timeout' => 15, ] ); // This is INSECURE — never use in production $response = wp_remote_post( $sub_site_url, [ 'body' => json_encode( $user_payload ), 'sslverify' => false, // Disables certificate validation — MitM attacks possible ] );
With
sslverify set to false, WordPress will accept any SSL certificate presented by the sub-site — including a fraudulent certificate issued by an attacker who has positioned themselves between the master and sub-site (a man-in-the-middle attack). The TLS encryption is still in place, but it encrypts traffic to the attacker rather than to the legitimate sub-site. Personal data, including user records containing names, emails, and password hashes, is delivered to the attacker’s endpoint in plaintext from their perspective.HMAC signing: why TLS alone is not enough and how to verify it is implemented
TLS encrypts the connection. It does not guarantee that the payload received at the sub-site is identical to the payload sent by the master site. In a correctly functioning TLS connection, modification in transit is prevented by the TLS record layer’s MAC (Message Authentication Code). But TLS operates at the transport layer — it protects the transmission, not the application-layer request itself.
HMAC signing at the application layer provides an additional guarantee: the sub-site can verify that the specific request payload was produced by a party holding the shared secret, not merely that it arrived via a TLS-protected connection. This distinction matters in scenarios where the sub-site’s endpoint is called directly by an attacker who has somehow obtained the API key — a compromised credential does not allow them to craft valid HMAC signatures if the signing algorithm is implemented correctly, because the HMAC includes a timestamp component that prevents replay of captured requests.
// On the master site — generate signature before sending function nus_sign_payload( string $payload, string $secret ): string { $timestamp = time(); $nonce = bin2hex( random_bytes( 16 ) ); $message = $timestamp . '.' . $nonce . '.' . $payload; $signature = hash_hmac( 'sha256', $message, $secret ); return 'v1:' . $timestamp . ':' . $nonce . ':' . $signature; } // On the sub-site — verify signature before processing function nus_verify_signature( string $payload, string $signature_header, string $secret ): bool { [ $version, $timestamp, $nonce, $sig ] = explode( ':', $signature_header, 4 ); // Reject requests older than 5 minutes — prevents replay attacks if ( abs( time() - (int) $timestamp ) > 300 ) { return false; } $message = $timestamp . '.' . $nonce . '.' . $payload; $expected = hash_hmac( 'sha256', $message, $secret ); // Timing-safe comparison — prevents timing oracle attacks return hash_equals( $expected, $sig ); }
Two implementation details in this example deserve specific attention. First, the use of hash_equals() rather than the === operator for the comparison. String comparison with === short-circuits on the first non-matching character, which creates a timing side-channel that an attacker can use to gradually discover the expected HMAC value. hash_equals() takes constant time regardless of where the strings diverge. Second, the five-minute timestamp window prevents an attacker who captures a valid signed request from replaying it after the window expires.
The six-point security audit for your WordPress sync implementation
The following audit process verifies the security posture of a WordPress user sync implementation systematically. Each audit point addresses a specific failure mode. Run this audit on every sync connection in your network, and repeat it after any hosting configuration change, SSL certificate renewal, or sync plugin update.
API key lifecycle management: rotation, revocation, and storage
The cryptographic controls described above are only as strong as the key material they depend on. An HMAC signature is only secure if the shared secret cannot be compromised. API key lifecycle management — generating strong keys, storing them securely, rotating them regularly, and revoking them promptly when necessary — is the operational layer that maintains the security properties of the cryptographic implementation over time.
Always generate API keys using random_bytes() in PHP or an equivalent CSPRNG. The wp_generate_password() function uses a fixed character set that reduces entropy relative to raw random bytes — it is acceptable for user-facing passwords but not ideal for API keys that should have maximum entropy. A 32-byte random value encoded as 64 hexadecimal characters provides 256 bits of security, which is well beyond any currently practical attack.
API keys should be stored in the WordPress database via wp_options, not in wp-config.php. While wp-config.php storage is common for credentials, it has the disadvantage of appearing in file backups, version control history, and deployment pipelines. Database storage with autoload set to false limits exposure. In high-security environments, the WordPress database itself should be encrypted at rest, and database access should be restricted to the web server process only.
Rotate API keys on a scheduled basis (annually as a minimum, quarterly for high-sensitivity deployments) and immediately following any security incident that may have exposed the key material — a server compromise, a codebase leak, a database breach, or any situation where someone with inappropriate access may have seen the key value. The rotation process must be atomic: the new key must be configured on both sites before the old key is invalidated, to prevent a sync interruption window during rotation.
When a sub-site leaves the network — a site is decommissioned, a client relationship ends, or a security incident requires immediate disconnection — the connection key must be revoked on the master site immediately. A revoked key should produce a 401 response from any remaining requests using it. Document key revocation in your security incident log with the timestamp and reason.
Producing a security audit report for compliance reviewers
Running the audit checks is the technical work. Documenting the results in a format that satisfies compliance reviewers — auditors assessing GDPR compliance, security reviewers for enterprise client contracts, or internal security teams doing periodic reviews — is a separate task that requires translating technical findings into a structured report.
The cryptographic layer protecting WordPress user sync is not a feature you enable once and forget. It is a configuration that must be verified against the current state of your infrastructure, tested against the specific attack vectors it is meant to protect against, and maintained through disciplined key lifecycle management. The audit process described in this guide gives you the methodology to do that systematically rather than relying on assumptions about what a plugin does by default.
Nexu User Sync’s OpenSSL-backed WordPress cross-domain user data encryption and HMAC-signed payload transmission implements all three layers of the security model described in this guide — TLS with certificate validation enforced, HMAC-SHA256 payload signing with replay protection, and cryptographically strong key generation — giving your sync implementation the auditable security foundation that compliance reviews and enterprise security requirements demand.
Three-layer cryptographic protection for every user record in transit. Audit-ready by design.
Nexu User Sync implements TLS with enforced certificate validation, HMAC-SHA256 payload signing with timestamp-bound replay protection, and cryptographically strong key generation — producing a sync security posture you can verify, audit, and document for compliance.
Okay, so I've been using this for a few weeks now, and the way it handles HMAC signing before sending user data is actually pretty solid. My main site computes the HMAC of the payload first, so even if someone somehow sniffs the traffic (which is already unlikely with TLS), they can't just inject fake data or mess with records mid sync. That's a big deal when you're moving sensitive stuff like emails or billing info between sites
Finally a guide that doesn't gloss over the
Hey everyone, just wanted to say this guide saved me a ton of stress. I was syncing user data between a main site and a few subsites for a client's membership portal, and I'd just assumed HTTPS meant everything was secure. This explained exactly how OpenSSL handles the TLS handshake during those transfers turns out my host's default cert setup was outdated, and I had no idea that could cause issues. followed the audit steps here and fixed it in 10 minutes. huge relief knowing password hashes aren't at risk anymore
Got this for my farm's membership site after a buddy warned me about sync plugins leaking data. The encryption part actually works checked with Wireshark myself, and all I saw was gibberish in transit. no plaintext emails or names floating around, which is a relief when you're dealing with customer billing info. That said, the setup isn't plug and play