What you are doing is adding an apache rule.
So effectively what you have done is blocked anything going through apache, which accepts request over port 80, to that specific file only. Or if you are using different web server software, whatever it’s called.
This won’t prevent anything which accesses the filesystem through any one of the other countless files as a part of the wordpress distribution, or 3rd party vendors from causing issues. So, any malware attempting to access your site through any other file, once they gain access to filesystem, they will have effectively circumvented your apache rule.
The only time you would want to block access to a file over port 80 (which is the port which webservers such as apache use), is if the file accepts $_POST, $_GET or other variables from the web, making it a SQL/Shell/whatever attack vector, or in the case it handles $_FILE variables, a file system attack vector. The script itself would have to be not coded well, either not sanitizing the variables, or it otherwise would have to be a script which is resource intensive and when it is run, bogs down the server, which would mean it’s a possible denial of service attack vector.
Did this help at all?
With wordpress specifically, if you are under attack repetitively, it might be a wise move to block access to the entire administration section, and allow only specific people in, until the rest of the security can be figured out.
On poorly configured shared servers, the larger issue might be with file permissions as alluded to in above posts. Should anyone breach any of your neighbors, if your files grant permissions for other groups on the server to access and write to your files, then that would be another way someone could circumvent the apache rule. Typically this should not really be a possibility, but people will share space in any number of strange ways. At the very least, if you are on a shared server, and are not confident that the host it set up right, make sure your file permissions do not allow anyone to write to the file except for the owner, which should be you.
Granting other groups the ability to read your files, is okay. Granting other groups the ability to write to your files, that’s an issue. Your FTP program should allow you to set Read, Write, permissions.
What has prompted you to block access to that file? Is it a file which is being tampered with or written to without your permissions?
Q1: Will using the .htaccess command above stop my script from accessing the wp-config during activation?
Q2: Is there a better way to get the script to use wp-config info?
If you trust the files inside your wordpress distribution, then they absolutely by design must be able to read the files which are also a part of the same distribution.
You might be interested in loading the WP-Config into global variable space using an Include_once command, as opposed to perhaps a file_get_contents command.
In any event, there should be no real need to constantly generate code from “static” variables, which if I am correct, that’s what the wp-config file should be. “Static”, or non-changing variables, or hardcoded ones.
