설명
CodeCanvas Guard is a local-first WordPress security suite built around reviewable changes and safe recovery.
Core features include:
- Safe, Balanced, and Strict protection profiles.
- A recovery-first custom login route with browser verification before activation.
- Username-and-IP rate limiting, CIDR allow/block rules, a login honeypot, and generic login errors.
- TOTP two-factor authentication with encrypted secrets and one-use recovery codes.
- Optional role-based 2FA enforcement and optional Cloudflare Turnstile.
- REST user protection, author-enumeration blocking, XML-RPC and pingback controls, security headers, and file-editor protection.
- WordPress core and eligible WordPress.org plugin checksum checks.
- Local suspicious-PHP patterns, executable uploads, unsafe permissions, recent sensitive-file changes, and known-vulnerability matching.
- Critical, High, Medium, Informational, and Unavailable findings with exact reasons and evidence.
- Administrator-reviewed findings, exact-file hash approvals, filters, and protected CSV/JSON exports.
- Scheduled scans and priority-aware file monitoring with explicit coverage reporting.
- Administrator-approved trusted repairs, protected recovery points, quarantine, restore, and rollback.
- Security activity logs, update awareness, session review, and optional email alerts.
Scheduled scans do not modify files. Repair, quarantine, restore, and rollback actions require an authenticated administrator action and nonce. Guard does not send telemetry to CodeCanvas.
Emergency Recovery
The dashboard can create a one-time emergency login link. The link expires after 30 minutes and opens a 15-minute recovery session.
For hosting-level recovery, add the following above the stop-editing comment in wp-config.php:
define( 'CODECANVAS_GUARD_DISABLE', true );
Remove the line after access is restored and the configuration is corrected.
External Services
CodeCanvas Guard uses external services only for the features described below.
WordPress.org services
Integrity scans, native update awareness, and approved trusted repairs use official WordPress.org services. Depending on the action, WordPress sends the installed WordPress version and locale, or plugin/theme identifiers and versions, and receives checksum data, update metadata, or an official package. Guard uses the native WordPress HTTP and updater APIs. These requests occur during manual or scheduled scans, update checks, and an administrator-approved repair.
Service: https://wordpress.org/
Privacy policy: https://wordpress.org/about/privacy/
Terms: https://wordpress.org/about/terms/
Wordfence Intelligence
Known-vulnerability matching is optional. When enabled with an API key, the server sends the API key and normal HTTP request metadata to Wordfence Intelligence and downloads its V3 production vulnerability feed. Guard compares the feed with the installed inventory locally; website files and the installed inventory are not uploaded to Wordfence. The service requires a Wordfence Intelligence API key.
Service and setup: https://www.wordfence.com/help/wordfence-intelligence/v3-accessing-and-consuming-the-vulnerability-data-feed/
Terms and privacy: https://www.wordfence.com/terms-of-use-and-privacy-policy/
Cloudflare Turnstile
Turnstile is optional and disabled by default. When configured, Cloudflare’s challenge script loads on interactive login pages. Cloudflare can process browser and device information under its policy. During login, Guard sends the challenge response, configured secret, and visitor IP address to Cloudflare for verification.
Service: https://www.cloudflare.com/products/turnstile/
Privacy policy: https://www.cloudflare.com/privacypolicy/
Terms: https://www.cloudflare.com/website-terms/
Privacy
Guard can store WordPress user IDs, IP addresses, event times, action summaries, limited technical context, user agents, and hashed device fingerprints for security and accountability. Administrators choose log retention from 7 to 365 days; the default is 30 days.
The plugin also stores security settings, encrypted 2FA and optional service credentials, recovery-code hashes, protected-login state, scan evidence, file hashes, approvals, and repair/quarantine metadata. Repair and quarantine files remain on the same server in a protected local directory.
Guard adds suggested text to Settings > Privacy and integrates with WordPress personal-data export and erasure tools. Erasure anonymizes user-linked audit events and removes device fingerprints and unfinished 2FA setup data. Active 2FA credentials are retained while the WordPress account exists to avoid weakening account security.
Source Code and Licenses
CodeCanvas Guard is licensed GPLv2 or later. The bundled QR generator is MIT licensed. Its human-readable upstream source is available at:
https://github.com/kazuhikoarase/qrcode-generator/tree/js2.0.4/js
See THIRD-PARTY-NOTICES.txt for the complete notice.
설치
- Back up the site and confirm hosting-panel or SSH access.
- Install and activate CodeCanvas Guard.
- Open CodeCanvas Guard and apply the Balanced profile.
- Configure 2FA from Users > Two-Factor Security.
- Generate and save an emergency recovery link before configuring a protected login route.
- Verify and activate the protected route, then test it in a private browser.
- Test checkout, membership, mobile-app, PWA, password-reset, and integration flows before applying Strict mode.
FAQ
-
Does Guard automatically remove malware?
-
No. Scans report evidence. Trusted WordPress sources can be reinstalled and executable uploads can be quarantined only after explicit administrator approval. Custom, premium, database, or ambiguous findings remain manual-review items.
-
Why can some plugins not be repaired automatically?
-
Automatic repair is available only when the exact installed version has a trusted WordPress.org package and checksum set. Premium, custom, or repository-removed plugins require a trusted vendor package or manual restoration.
-
Does repair activate another plugin?
-
No. Guard does not change another plugin’s activation status. If WordPress leaves a repaired plugin inactive, Guard verifies the installed files and asks an administrator to reactivate it manually from the native Plugins screen.
-
Are repairs reversible?
-
Eligible plugin repairs create a protected pre-repair copy. Verification failure triggers file rollback, and successful repairs retain a manual rollback point. Permission repairs retain the previous mode. Quarantined files require a separate restore approval. Keep a current hosting backup.
-
Does fingerprint reduction make WordPress impossible to detect?
-
No. Guard removes common public indicators and simple enumeration paths, but themes, assets, APIs, and behaviour can still reveal WordPress.
-
Does the protected login route work with plain permalinks?
-
The request-path fallback is designed to work when pretty permalinks are unavailable. Hosting rules, caching, and other security plugins can interfere, so verify the route before activation.
-
Will XML-RPC blocking affect integrations?
-
It can. Jetpack, WordPress mobile apps, and other integrations may require XML-RPC. The Balanced profile leaves XML-RPC available.
-
Should I enable HSTS immediately?
-
No. Enable HSTS only after the whole site and every required resource work permanently over HTTPS.
후기
이 플러그인에 대한 평가가 없습니다.
기여자 & 개발자
변경이력
1.3.2
- Replaced standalone browser
<style>output with WordPress-enqueued stylesheet assets. - Moved login honeypot and Turnstile presentation rules into an enqueued login stylesheet.
- Tightened nonce ordering for settings and session actions so request data is inspected only after intent verification.
- Added explicit capability checks to self-service 2FA management actions.
- Rotated protected-login route-test tokens after successful verification so each test URL is single-use.
- Corrected the bundled QR generator source URL and WordPress.org contributor metadata.
- Added narrowly scoped Plugin Check annotations for Cloudflare Turnstile’s required external service endpoints and reduced the session-user query to only rendered fields.
1.3.1
- Replaced repair, quarantine, rollback, permission, and vault mutations with the WordPress Filesystem API.
- Replaced the dynamic audit query with literal prepared queries and short-lived cache invalidation.
- Hardened public route, recovery-cookie, login-challenge, and settings input handling.
- Added narrow reviewer annotations for public authentication tokens, one-time migrations, custom audit tables, and optional Turnstile service loading.
- Scoped uninstall variables, completed new migration-state cleanup, and preserved the legacy audit table until explicit uninstall.
- Removed the export stream close warning and renamed the main runtime class to the unique plugin namespace.
1.3.0
- Replaced the former three-letter namespace with the unique
CCGUARD_andccguard_prefixes. - Added a verified migration for profiles, protected-login state, scan data, encrypted settings, 2FA metadata, transients, scheduled jobs, and audit events.
- Preserved existing emergency and pending route-test links during the namespace upgrade.
- Removed automatic activation of repaired plugins and added an explicit manual-reactivation result.
- Added WordPress privacy-policy text, a personal-data exporter, and an anonymizing eraser.
- Completed uninstall cleanup for new and legacy records, schedules, transients, metadata, tables, and protected vaults.
- Added complete external-service disclosures and human-readable QR source attribution.
- Updated WordPress compatibility metadata and reduced the directory readme below the processing limit.
Older release history is available in changelog.txt.