A cache diagnostic plugin has to earn trust before it can be useful. WPColt Cache Inspector is being designed around a read-only first release: inspect signals, explain evidence, and avoid changing production configuration automatically.
Security principles
- Read-only first. The first version should not edit cache plugin settings, write server config, purge CDN rules, or modify site content.
- Public-page testing only by default. The core scan uses the homepage and one published post as a logged-out visitor.
- Private pages stay private. Cart, checkout, account, login, admin, preview, and personalized paths should be treated as bypass candidates.
- Evidence over secrets. Reports should rely on plugin presence, WordPress signals, and HTTP headers rather than collecting credentials or private customer data.
What the plugin may inspect
| Signal | Purpose | Risk control |
|---|---|---|
| Active plugins | Detect page-cache, optimization, ecommerce, security, and object-cache tools. | Names and statuses are enough; settings exports are not needed for a first report. |
| Public HTTP headers | Verify cache behavior through Age, X-Cache, CF-Cache-Status, Cache-Control, Set-Cookie, and related headers. | Only public URLs selected for testing are requested. |
| Object-cache clues | Detect Redis/Memcached drop-in and likely connection state. | No database dump or sensitive key storage required. |
| WooCommerce URL patterns | Warn about public cache risk on cart, checkout, and account flows. | The first release should avoid crawling private sessions. |
What should not leave the site
The intended free version is local-first. If a future Pro feature adds hosted monitoring, scheduled reports, account dashboards, or email alerts, the product should clearly disclose what is transmitted, how long it is stored, and how to delete it.
Does WPColt need WordPress admin credentials?
No diagnostic plugin should need you to paste hosting passwords or CDN API keys into a report just to understand public cache behavior. Future integrations, if any, should be optional and documented.
Can a HIT be unsafe?
Yes. A HIT is good for public posts and pages. It is dangerous on personalized pages such as cart, account, checkout, user dashboards, and private content.
Responsible reporting
Report security issues through the Contact page. Include reproduction steps and affected version details when available. Do not send passwords, API keys, private customer data, or unnecessary server secrets.