CodeCanvas Guard
| 开发者 | codecanvasinc |
|---|---|
| 更新时间 | 2026年8月29日 02:23 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
- 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.
安装:
- 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.
常见问题:
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.
更新日志:
- 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.
- 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.
- 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.
changelog.txt.