Security & Encryption

Security Overview

SafeGuard is designed with a security-first philosophy. Every feature — from backups to migrations to cloud storage — is built on the principle that your data should be protected at rest, in transit, and at every point in between.

Key security properties across SafeGuard:

Backup Encryption

SafeGuard supports encrypting backup archives before they are stored locally or uploaded to a remote provider.

Enabling Backup Encryption

curl -X POST /wp-json/safeguard/v1/storage/settings \
  -H "X-WP-Nonce: <nonce>" \
  -d '{"encryptBackups": true}'

What Gets Encrypted

When backup encryption is enabled, the entire backup archive is encrypted before it leaves your server. This includes:

• Database exports — all SQL dump files containing your posts, users, options, and custom tables.
• File archives — themes, plugins, uploads, and WordPress core files.
• Incremental diffs — changed files in incremental backups are encrypted identically to full backups.

How It Works

Backup encryption uses AES-256-CBC with a key derived from your WordPress authentication salts via SHA-256. Each backup archive gets a unique random initialization vector (IV), ensuring that identical backups produce different ciphertext.

SafeLink Migration Encryption

SafeLink is SafeGuard's site-to-site migration protocol. It implements a full cryptographic chain inspired by modern secure messaging protocols, ensuring that migration data is protected even if the network is compromised.

Cryptographic Chain Overview

Source Site                                    Destination Site
───────────                                    ────────────────
1. Generate ECDH keypair (prime256v1)
2. Send public key + migration code  ──────►   3. Generate ECDH keypair
                                     ◄──────   4. Return public key + nonce
5. Derive shared secret (ECDH)                 5. Derive shared secret (ECDH)
6. HKDF-SHA256 → auth_key + enc_key           6. HKDF-SHA256 → auth_key + enc_key
7. Encrypt data (ChaCha20-Poly1305)
8. Sign request (HMAC-SHA256)        ──────►   9. Verify HMAC signature
                                               10. Verify sequence number
                                               11. Decrypt data (ChaCha20-Poly1305)

ECDH Key Exchange

Both the source and destination sites generate ephemeral Elliptic Curve Diffie-Hellman (ECDH) keypairs on the prime256v1 (P-256) curve. The public keys are exchanged during the handshake, and each side independently derives the same shared secret — without ever transmitting it over the network.

This means even if an attacker captures the handshake, they cannot reconstruct the shared secret without one of the private keys.

HKDF Key Derivation

The raw ECDH shared secret is never used directly for encryption. Instead, SafeGuard uses HKDF-SHA256 (HMAC-based Key Derivation Function) to derive two separate 32-byte keys:

• Authentication key — used for HMAC-SHA256 request signing (context: safeguard-safelink-auth-v1)
• Encryption key — used for AEAD encryption (context: safeguard-safelink-enc-v1)

A per-session nonce is used as the HKDF salt, ensuring that even if the same two sites migrate multiple times, the derived keys are always different.

AEAD Encryption

All migration data is encrypted with Authenticated Encryption with Associated Data (AEAD):

• Preferred cipher: ChaCha20-Poly1305 — fast on all hardware, including servers without AES-NI acceleration.
• Fallback cipher: AES-256-GCM — universally available across PHP OpenSSL builds.

SafeGuard probes at runtime to confirm the preferred cipher supports AEAD tags correctly, and automatically falls back if needed. The cipher selection is transparent and requires no configuration.

Each encrypted message is packed as a binary blob:

The authentication tag ensures that any tampering with the ciphertext, IV, or cipher ID is detected and rejected before decryption.

Anti-Replay Protection

Each encrypted message includes a monotonically increasing sequence number packed into the first 8 bytes of the IV. The receiver tracks the expected sequence number and rejects any message where the embedded sequence does not match.

This prevents an attacker from capturing and replaying legitimate migration packets to corrupt or duplicate data on the destination site.

HMAC-SHA256 Request Signing

Every migration request is signed with HMAC-SHA256 using the derived authentication key. The receiver verifies the signature using a constant-time comparison (hash_equals) before processing any data.

This provides two guarantees:

1. Authenticity — the request genuinely originated from a site that holds the shared secret.
2. Integrity — the request body has not been modified in transit.

Zero-Knowledge Design

The source and destination negotiate encryption keys directly via ECDH. No intermediate server — including SafeGuard's cloud relay — ever has access to the shared secret or derived keys. Even if the relay infrastructure were fully compromised, an attacker would see only encrypted ciphertext with no way to recover plaintext.

Cloud Relay Security

When the destination site cannot accept direct connections (firewall, NAT, Cloudflare, shared hosting), SafeGuard routes migration data through its cloud relay at safeguard.verdelic.com. The relay is designed as a dumb pipe:

• No decryption — the relay forwards raw encrypted bytes. It does not hold encryption keys and cannot decrypt any payload.
• License-gated access — only active SafeGuard licenses can establish relay sessions, preventing unauthorized use.
• SSRF protection — the relay validates destination URLs to prevent internal network scanning.
• Auto-expiring sessions — relay sessions expire after 1 hour. No migration data is persisted on the relay.

Storage Security

OAuth Token Encryption

When you connect a cloud storage provider (Google Drive, Dropbox, OneDrive), SafeGuard stores your OAuth tokens encrypted in the WordPress database:

• Algorithm: AES-256-CBC with a random 16-byte IV per token.
• Key derivation: The encryption key is derived via SHA-256 from your WordPress auth salt combined with a SafeGuard-specific context string (safeguard_oauth_token_v1).
• Storage location: Encrypted tokens are stored in WordPress user meta, scoped to the user who authorized the connection.
• Automatic cleanup: Expired tokens are automatically purged.

Provider-Specific Security

All provider credentials are encrypted at rest using AES-256. Plain-text credentials are never stored in the database.

Access Control

WordPress Capabilities

All SafeGuard REST API endpoints require the manage_options capability, which is restricted to WordPress Administrators by default. Non-admin users cannot access any SafeGuard functionality, including viewing backups, running restores, or modifying settings.

License Enforcement

Write operations — creating backups, running restores, creating schedules, initiating migrations, and managing staging sites — additionally require an active SafeGuard license. This is enforced via a shared License_Check trait used across all REST API controllers:

• Read operations (listing backups, viewing settings) require manage_options only.
• Write operations require manage_options and an active license.

If your license expires or is deactivated, existing backups remain accessible but no new operations can be performed until the license is reactivated.

Staging Site Access Control

Staging site operations (create, delete, push to live) require both manage_options and an active license. This prevents unauthorized users from deploying staging changes to your production site.

File Quarantine

When SafeGuard restores a backup, it does not blindly overwrite your existing files. Instead, the Pruning Service identifies files that exist on your server but are not present in the backup being restored.

Rather than deleting these files immediately, SafeGuard moves them to a quarantine directory:

wp-content/safeguard-quarantine/20260328-143022/

Each restore operation creates a timestamped quarantine folder. This provides a safety net: if the restore removes files your site depends on, you can recover them from quarantine.

Managing Quarantined Files

# List quarantined files
wp safeguard quarantine list

# Restore a quarantined file
wp safeguard quarantine restore <file>

# Delete all quarantined files
wp safeguard quarantine clean

Rate Limiting

Migration handshake endpoints are protected by IP-based rate limiting to prevent brute-force attempts against migration codes:

• Limit: 3 handshake attempts per IP address per hour.
• Storage: Rate limit counters are stored in WordPress transients with automatic expiration.
• Response: Requests exceeding the limit receive a 429 Too Many Requests response.

This prevents an attacker from rapidly guessing migration codes, even if they know a migration session is active.

Privacy & Data Handling

SafeGuard respects your privacy and your users' privacy:

Telemetry

• Opt-in only — SafeGuard displays a consent notice on first use. Telemetry is never sent unless you explicitly opt in.
• Anonymous — if you opt in, SafeGuard sends only anonymous, aggregated usage statistics (PHP version, WordPress version, backup counts, enabled features). No personal data, site content, or backup contents are ever transmitted.
• Revocable — you can disable telemetry at any time from SafeGuard → Settings.

What SafeGuard Does NOT Collect

• Site content, posts, pages, or user data.
• Backup file contents.
• Database contents.
• OAuth tokens or storage provider credentials.
• Personally identifiable information.

Third-Party Data Sharing

SafeGuard does not share any data with third parties. The only external communication is:

• License validation — your license key and domain are verified against api.safeguard.verdelic.com.
• Cloud relay — encrypted migration data may route through safeguard.verdelic.com when direct connections fail (the relay cannot decrypt this data).
• Telemetry (opt-in only) — anonymous usage statistics sent to api.safeguard.verdelic.com.

Best Practices