Being conscious of web security is sometimes a real pain in the you know what. I’m seeing some attempts to directly access some scripts on WordPress sites I maintain that should not be directly accessed. No harm is being done, but there are “500 Internal Server Error” results being generated that should instead be “403 Forbidden” or “404 Not Found”.
I’ve made a few stabs at changing the re-write rules and am now looking the mod_security rules as perhaps a better method to trap the errors. In both cases, there appears to a lack of good tools to use for testing the rules without making them active on a website somewhere. And this is making it more complicated of course to get the rules right!
Stay tuned… I’ve got a few more ideas and if I get this sorted out to my satisfaction, I’ll be posting an update on some good ways to protect areas of WordPress that should not be directly accessed via browser requests. I haven’t found much on this topic in my searches on the web. In fact, many places I find recommend turning off mod_security for WordPress. I had a site hacked once with a SQL Injection attack because I had followed that advice. I’m doing what I can to prevent that in the future!