Security
SECURITY
Dokan Conditional Category Attributes — Security Architecture & Policies
Version: 2.0.0 (Server) / 2.0.0 (Plugin)
Developer: OpequeGlass
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:
plain
- 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
falseand the UI displays the authorization lock - The fingerprint is stored in
dokan_conditional_attrs_auth_fingerprintand validated on everydokan_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_durationfilter)
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):
Table
| State Type | Status | Reversible? | Blocks Features? |
|---|---|---|---|
| Non-Terminal | INACTIVE | Auto-corrected by sync | No — available for activation |
| Non-Terminal | ACTIVE |  Auto-corrected by sync | No — fully operational |
| Terminal | EXPIRED | Requires renewal purchase | Yes — blocks activation & validation |
| Terminal | SUSPENDED |  Requires admin approval | Yes — blocks all API operations |
Critical: OnlyEXPIREDandSUSPENDEDare terminal states.INACTIVEsimply 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_secrettransmitted 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
DOKAN_LICENSE_API_SECRETconstant (not stored in database) - Server-side: Hardcoded in
license.php(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:
Table
| Input Source | Sanitization Function | Purpose |
|---|---|---|
| License key entry | sanitize_text_field() | Strips tags, encodes special chars |
| Category attribute selection | array_map('sanitize_text_field', ...) | Bulk-sanitizes attribute slugs |
| Domain/URL parameters | parse_url() + PHP_URL_HOST | Extracts clean domain |
| AJAX nonces | check_ajax_referer() | CSRF protection |
| Admin form nonces | check_admin_referer() | CSRF protection for POST actions |
3.2 Output Escaping
All rendered data is escaped for its context:
Table
| Context | Function | Usage |
|---|---|---|
| HTML body | esc_html() | License key display, status messages |
| HTML attributes | esc_attr() | Input field values, CSS variables |
| URLs | esc_url() | Site links, image URLs |
| JavaScript | esc_js() | Inline script strings, JSON encoding |
| JSON API | json_encode() | Server responses with JSON headers |
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:
php
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:
php
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 opequeglass.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
addEventListenerrather than inlineonclickwhere 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:
Table
| Field | Purpose |
|---|---|
license_id | Links action to specific license |
action | Event type (activate, deactivate, sync, suspend, etc.) |
site_domain | Affected domain |
ip_address | Client IP for geo/forensics |
user_agent | Client identification |
response | Server response (JSON) |
created_at | Timestamp |
Logged Actions:
activate_success/activate_failed— Activation attemptsfastspring_generate— License key generationwebhook_order_completed— FastSpring order eventswebhook_subscription_charge_extended— Renewal processingadmin_suspend/admin_approve— Administrative actionsadmin_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:php
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:
Table
| Data | Purpose | PII? |
|---|---|---|
License key (DKN-...) | Authorization validation | Â No |
Site domain (example.com) | Domain binding verification | Â No |
| Site URL | Reactivation detection | Â No |
| WordPress version | Compatibility tracking | Â No |
| Plugin version | Update eligibility | Â No |
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 (
opequeglass.com) is separate from payment processing infrastructure
9. Threat Mitigation Matrix
Table
| Threat Vector | Mitigation | Implementation |
|---|---|---|
| License key brute-force | Rate limiting + key format validation | Server-side pattern matching (DKN- prefix) |
| Local option tampering | Integrity fingerprint + server re-sync | md5() checksum with hash_equals() |
| Man-in-the-middle (MITM) | HTTPS + CA validation | wp_remote_post() with SSL verification |
| CSRF attacks | Nonce validation on all state-changing actions | check_ajax_referer() + check_admin_referer() |
| XSS via attribute labels | Output escaping | esc_html() on all rendered labels |
| SQL injection | WordPress API usage only | No custom SQL — all prepared statements |
| Privilege escalation | Capability checks | current_user_can('manage_woocommerce') |
| Nulled plugin backdoors | Official distribution only | Server-signed update packages |
| CDN caching of license state | Zero-cache headers | no-store, no-cache, must-revalidate |
| Admin account compromise | 2FA + strong passwords | Recommend Wordfence/iThemes Security |
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
opequeglass.com(port 443) - File permissions: Set plugin files to
644, directories to755 - Disable directory browsing: Add
Options -Indexesto.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_woocommercecapability 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_suspendaction in audit log (admin-initiated block)- Sudden feature lockout with “Expired” or “Suspended” status
Response steps:
- Check Authorization Manager for current status and active domains
- Review server audit log for unauthorized activations
- If compromise confirmed: Click Deactivate → contact support with token
- Request server-side suspension if unauthorized use persists
11.2 Server Unreachability
Symptoms: “Sync failed”, “Stale” status, activation errors
Troubleshooting:
- Verify outbound HTTPS connectivity:
curl -I https://dokanconditionalattribute.com/license/license.php - Check firewall rules (port 443 outbound)
- Verify CA bundle:
openssl s_client -connect opequeglass.com:443 - Check PHP
allow_url_fopenandopensslextension - Review WordPress debug log for
wp_remote_post()errors
12. Glossary
Table
| Term | Definition |
|---|---|
| API Secret | Shared authentication token between client and licensing server |
| CSRF | Cross-Site Request Forgery — prevented via nonce validation |
| Fingerprint | md5() checksum detecting local option tampering |
| Integrity Check | Server-side validation of license state consistency |
| MITM | Man-in-the-Middle attack — mitigated by HTTPS + CA validation |
| Nonce | Cryptographic one-time token preventing CSRF attacks |
| PII | Personally Identifiable Information — not collected by this plugin |
| Terminal State | expired or suspended — requires manual/admin action to resolve |
| Zero-Cache | Aggressive no-cache headers preventing stale authorization data |
| XSS | Cross-Site Scripting — prevented by output escaping |
These security notes reflect the current implementation as of License Server v3.5.0 and Plugin v3.0.1. For the latest security advisories, subscribe to the OpequeGlass security mailing list or monitor the documentation portal.
