Notice: This plugin interface and documentation are currently available only in Portuguese. English translation is planned for a future update.
I’ve always liked understanding how a website works behind the scenes, especially when it comes to security. For a long time, whenever I needed to analyze a WordPress site, I did everything manually. I would check if the site was using HTTPS, see if XML-RPC was active, look for outdated plugins, test endpoints directly in the browser, and analyze headers. It was a repetitive but necessary process.
That’s where the idea for this plugin came from. The goal wasn’t to create a complex scanner or a tool that promises to fix everything automatically. It was simpler and more honest: I wanted a technical checklist that would give me a quick overview of a WordPress site’s security health. That is how Nousk WP SafeCheckwas born.
Each check is classified as:
- OK
- Attention
- Risk
- Manual
This allows for a quick grasp of what is fine, what deserves attention, and what requires a more careful analysis. The goal isn’t to declare that a site is “secure”—the goal is to help you see better.
What the plugin checks today
In its current version, the plugin covers several critical areas. It verifies internal WordPress configurations, such as the existence of a user with the “admin” login, file editing via the dashboard, and pending updates for plugins and themes.
It also analyzes public endpoints, such as access to `wp-login.php` and `xmlrpc.php`, and performs real access tests on sensitive files like `wp-config.php`, `.env`, and `.git`. Additionally, it checks for directory exposure, analyzes security headers on the server, and includes a `robots.txt` review as a manual check. All of this is organized within a simple interface directly in the WordPress dashboard.
Why I didn’t want to build a “Full Scanner”
Security isn’t something you can solve with a single button. Many tools promise complete analyses, but in practice, this can lead to:
- False positives
- A false sense of security
- Conclusions taken out of context
I preferred a different path. The plugin doesn’t make decisions for you; it points the way. It shows you what is happening and suggests what can be done, but the final analysis remains the responsibility of the person looking at the data.
What I learned building this plugin
Building this plugin forced me to look at security in a more structured way. Before, I knew how to check things, but I did it in a scattered fashion. Now, I have a workflow. I think in categories, risk types, and how to present information clearly and usefully. Most importantly, I’ve learned to better distinguish what is truly a risk, what is just a point of attention, and what requires manual analysis.
Next Steps
The current version is functional and covers a solid set of checks, but there is plenty of room to grow. For the next version (v1.1), I plan to refine and expand several points:
- Header Validation: Not just checking if security headers exist, but validating their values.
- Debug Mode: Adding a check for active WordPress debugging, which can expose sensitive info in production.
- File Modifications: Verifying settings like `DISALLOW_FILE_MODS`.
- Version Exposure: Checking for WordPress version exposure and improving REST API analysis.
- Heuristics: Improving current check logic to reduce potential false positives.
Conclusion
This plugin was born from a real need. It doesn’t try to be a complete solution, but rather a practical tool to help understand WordPress security better. It doesn’t replace security audits or specialized tools; instead, it functions as a vital first layer of analysis. The plan is to keep evolving, adding new checks, and improving how information is presented.
