SECURITY

Dokan Conditional Category Attributes — Security Architecture & Policies

Version: 2.0.0 (Server) / 2.0.0 (Plugin)
Developer: LogicBlue
Last Updated: June 2026
Classification: Commercial Plugin Security Documentation

1. Security Architecture Overview

Dokan Conditional Category Attributes implements a multi-layered security model that protects licensing integrity, prevents unauthorized access, and ensures data confidentiality across the WordPress-Dokan-WooCommerce stack. The security approach follows the principle of least privilege, defense in depth, and zero-trust communication with the licensing server.

Core Security Layers:

• Authorization Gate — Server-bound license validation with anti-tamper fingerprints

• Input Sanitization — All user inputs sanitized via WordPress APIs before database persistence

• Output Escaping — All rendered data escaped for HTML, JavaScript, and attribute contexts

• API Security — HTTPS-only communication with API secret validation and zero-cache headers

• Integrity Verification — Cryptographic checksums detect local option tampering

• Audit Logging — Server-side action logging for compliance and forensics

2. Authorization & Licensing Security

2.1 License Protection Model

The plugin uses a server-bound authorization system that cannot be bypassed through local manipulation alone. The security model operates on three pillars:

Pillar 1: Server-Authoritative State

• The licensing server maintains the single source of truth for all license states

• Local WordPress options cache the last-known state but are not trusted without server validation

• Every activation, validation, and sync request requires server confirmation

Pillar 2: Anti-Tamper Integrity Checks
The plugin generates a runtime fingerprint from:

If local options are manually edited (e.g., via database access), the fingerprint mismatch triggers a forced server re-sync
If re-sync fails, all feature functions return false and the UI displays the authorization lock
The fingerprint is stored in dokan_conditional_attrs_auth_fingerprint and validated on every dokan_auth_feature_gate() call

Pillar 3: Graceful Degradation

• If the licensing server is unreachable (network outage, DNS failure, SSL error), the plugin continues operating under the last valid state

• No immediate feature lockout occurs — business continuity is preserved during temporary outages

• The background verification runs once per cache cycle (default: 15 seconds for admin, configurable via dokan_auth_cache_duration filter)

2.2 Terminal vs. Non-Terminal States

The system distinguishes between terminal states (irreversible without admin action) and non-terminal states (auto-corrected by sync):

Critical: Only EXPIRED and SUSPENDED are terminal states. INACTIVE simply means “not currently bound to any site” and does not block activation attempts.

2.3 API Secret & Request Authentication

All server requests include a shared api_secret validated server-side:

• Client → Server: api_secret transmitted in JSON POST body

• Server Response: HTTP 401 if secret mismatch

• FastSpring Webhooks: HMAC-SHA256 signature validation using fastSpringWebhookSecret

• FastSpring Remote: Dual authentication (HTTP Basic Auth + MD5 request hash)

Secret Storage:

• Client-side: Defined as LICENSE_API_SECRET constant (not stored in database)

• Server-side: Hardcoded in license (not exposed via API)

Recommendation: Rotate secrets quarterly via plugin update + server config change

3. Data Sanitization & Validation

3.1 Input Sanitization Pipeline

All user-facing inputs pass through WordPress sanitization functions:

3.2 Output Escaping

All rendered data is escaped for its context:

JavaScript Context Safety: The window.X7M configuration object (if used) is encoded via json_encode() with JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT flags to prevent script injection.

4. API Communication Security

4.1 Transport Layer Security (TLS)

All licensing server communication uses HTTPS with certificate validation:

Security Requirements:

• Server must have up-to-date CA certificate bundle for SSL verification

• Outdated CA bundles cause wp_remote_post() to fail with SSL errors

• No HTTP fallback — all endpoints enforce HTTPS

4.2 Zero-Cache Headers (Server-Side)

The licensing server implements aggressive no-cache headers to prevent stale authorization data:

Purpose: Prevents CDN, proxy, and browser caching of license state responses.

4.3 Request Timeout Handling

• Standard requests: 15-second timeout

• Activation requests: 30-second timeout (allows for server-side processing)

• Failure behavior: Returns last known valid state — no feature lockout on timeout

5. Frontend & Script Security

5.1 Minimal Frontend Footprint

The plugin’s frontend attack surface is intentionally minimal:

• No scripts on customer-facing pages — only loads on Dokan vendor dashboard and admin pages

• No cookies set — no session management on the frontend

• No tracking pixels — no analytics or third-party beacons

• No external resource loading — all assets are local (except badge images from dokanconditionalattribute.com)

5.2 Content Security Policy (CSP) Compatibility

The plugin uses inline styles and scripts consistent with WordPress/Dokan patterns:

• Inline styles: Used for admin dashboard UI (compatible with style-src 'unsafe-inline')

• Inline scripts: Used for modal interactions and AJAX handlers (compatible with script-src 'unsafe-inline')

• Event handlers: Uses addEventListener rather than inline onclick where possible

Note: If your site implements a strict CSP (no inline scripts), the WordPress admin and Dokan dashboard themselves will fail. The plugin follows the same patterns as core WordPress.

5.3 XSS Prevention

All user-rendered content is escaped:

• Attribute labels: esc_html()

• License keys: esc_html() + <code> tags

• Domain URLs: esc_url()

• Status messages: esc_html()

• JavaScript strings: esc_js()

No user-generated content is rendered without escaping.

6. File System & Code Integrity

6.1 File Permissions

Recommended permissions:

• Plugin files: 644 (readable by all, writable by owner)

• Plugin directories: 755 (executable for directory traversal)

• Never allow web server write access to plugin files (prevents RCE via file upload vulnerabilities)

6.2 Integrity Verification

While the plugin does not include automatic file checksum verification, you can manually verify integrity:

• Download the official distribution from https://dokanconditionalattribute.com

• Compare file hashes (MD5/SHA-256) against the published manifest

• Monitor for unauthorized modifications using a security plugin (Wordfence, Sucuri, iThemes Security)

6.3 Update Security

• Official channel only: Updates are delivered via the WordPress update system with server validation

• Update requirements: Active license + domain validation + version check

• Nulled plugin warning: Unauthorized distributions may contain backdoors, malware, or broken license checks. Never install nulled plugins.

7. Audit Logging & Monitoring

7.1 Server-Side Audit Log

The licensing server maintains a comprehensive activity log:

Logged Actions:

• activate_success / activate_failed — Activation attempts

• fastspring_generate — License key generation

• webhook_order_completed — FastSpring order events

• webhook_subscription_charge_extended — Renewal processing

• admin_suspend / admin_approve — Administrative actions

• admin_deactivate_site — Per-site deactivation

7.2 Client-Side Monitoring

WordPress Debug Log: When WP_DEBUG_LOG is enabled, API errors and activation failures are logged to wp-content/debug.log:

Monitor for:

• Repeated activation failures (brute-force attempts)

• Unexpected domain changes (license sharing)

• SSL errors (CA bundle issues)

8. Compliance & Data Protection

8.1 GDPR Compliance

The plugin is GDPR-compliant by design:

• No personal data collection: The licensing server only receives domain name and license key — no customer, vendor, or visitor data

• No cookies: No tracking or session cookies set by the plugin

• No analytics: No usage tracking, heatmaps, or telemetry

• Data processor status: Not required — no personal data processing occurs

Data transmitted to licensing server:

8.2 CCPA Compliance

• No data sale: No personal information is sold or shared

• No advertising integrations: No ad networks, retargeting, or data brokers

• No analytics beacons: No third-party tracking scripts

8.3 PCI-DSS Considerations

While the plugin does not handle payment data directly:

• SSL required: All licensing communication uses HTTPS

• No card data transmission: License validation does not involve payment information

• Server isolation: Licensing server (dokanconditionalattribute.com) is separate from payment processing infrastructure

9. Threat Mitigation Matrix

10. Security Recommendations for Site Administrators

10.1 Hosting Environment

• Keep PHP updated: Use PHP 7.4+ (plugin minimum) — preferably PHP 8.1+ for security patches

• Update CA bundle: Ensure server’s CA certificates are current for HTTPS validation

• Firewall rules: Allow outbound HTTPS to dokanconditionalattribute.com (port 443)

• File permissions: Set plugin files to 644, directories to 755

• Disable directory browsing: Add Options -Indexes to .htaccess

10.2 WordPress Hardening

• Use strong admin passwords: Minimum 12 characters, mixed case, numbers, symbols

• Enable 2FA: Use Wordfence, iThemes Security, or similar for admin 2FA

• Limit login attempts: Prevent brute-force against /wp-login.php

• Change table prefix: Avoid default wp_ prefix

• Disable XML-RPC: If not needed, block xmlrpc.php

• Security plugin: Install Wordfence or Sucuri for file integrity monitoring

10.3 WooCommerce-Specific

• SSL certificate: Required for checkout — also ensures license validation works

• Secure checkout: Disable guest checkout + add CAPTCHA to prevent card testing

• Regular backups: Daily backups with off-site storage (S3, Google Drive)

• Staging environment: Test plugin updates before production deployment

10.4 Plugin-Specific

• Monitor sync status: If “Stale” badge appears, check server connectivity

• Verify license after migration: Always deactivate old domain before activating new

• Keep plugin updated: Active license required for update access — renew before expiry

• Audit admin access: Only manage_woocommerce capability holders can access Authorization Manager

• Review logs regularly: Check server audit log for suspicious activation patterns

11. Incident Response

11.1 License Compromise Detection

Indicators of compromise:

• License active on unexpected domain

• Multiple rapid activation/deactivation cycles

• admin_suspend action in audit log (admin-initiated block)

• Sudden feature lockout with “Expired” or “Suspended” status

Response steps:

1. Check Authorization Manager for current status and active domains

2. Review server audit log for unauthorized activations

3. If compromise confirmed: Click Deactivate → contact support with token

4. Request server-side suspension if unauthorized use persists

11.2 Server Unreachability

Symptoms: “Sync failed”, “Stale” status, activation errors

Troubleshooting:

1. Verify outbound HTTPS connectivity: curl -I https://dokanconditionalattribute.com/license/license.php

2. Check firewall rules (port 443 outbound)

3. Verify CA bundle: openssl s_client -connect dokanconditionalattribute.com:443

4. Check PHP allow_url_fopen and openssl extension

5. Review WordPress debug log for wp_remote_post() errors

12. Glossary