Hi @neversaynever504,
If PHP blocking is enabled within the plugin,
it may result in a 403 error and disrupt the website’s functionality.
If the file “plugins/litespeed-cache/guest.vary.php” includes a vulnerability your site could be hacked.
Exclusions can potentially enlarge the attack surface of your site.
+++ To prevent any confusion, I’m not SolidWP +++
I understand your point.
However, not all plugins are built with robust security measures in mind.
Some of them create and alter files within the /plugins/ directory.
Allowing users to exclude certain folders and files gives them the freedom to make informed decisions if they are confident in their expertise.
Hi @neversaynever504
Happy to provide a bit of context for this!
It’s an established best practice in WordPress to discourage direct execution of PHP files. Responsible plugin developers do that within their code, directly. That’s why (if you view the source code of a plugin or a theme) many times you’ll see something like
if ( ! defined( 'ABSPATH' ) ) {
exit; // Exit if accessed directly
}
…which is a function to ensure that the file in question is being executed correctly. A brief translation into English of what that function is telling the machine would be “check to see if ABSPATH has been defined, and if it hasn’t, stop executing this code!”
ABSPATH is a PHP constant defined in WordPress itself, in the wp-config.php file (after a warning to not modify the constant!).
So that responsible little line at the top of a legitimate file essentially ensures that the code is being executed in the correct context.
Solid Security allows you as a user to essentially enforce that developers do that responsible thing. It performs a similar block on directly executing code, whether that line is present at the top of the file or not!
If it’s not being executed in the context of WordPress, you can’t execute anything. Solid Security gives you the ability to granularly block the specific directories where you want to enforce the rules, but beyond that if there were something like a filter to whitelist certain files, it would essentially provide a way for a malicious actor to bypass the functionality altogether.
So when we say “we’re not going to be adding that” it’s not just to make it more difficult: it’s to encourage other plugin developers to stop the bad practice of directly executing PHP in that way, and it’s to prevent putting in a way for bad actors to essentially render that layer of security protection null.
Put slightly more bluntly: This has been a standard practice for years in WordPress, and plugins and other adding code that’s designed to execute outside of WordPress itself should find better places to put that code.
