views:

109

answers:

3

Where is the most secure place to store sensitive code on a server (ex, authorization php, contact scripts, sensitive or protected javascript)?

You guys/girls got any tips or tricks on how to protect that kind of stuff?

+4  A: 

Some observations

The problem you have is that in order to use any of this code, it needs to be readable by whatever process is using it (typically the webserver). That fact alone really makes it impractical to get extra security, unless you can resort some type of queued offline processing.

Rule #1 - keep it out of the DocumentRoot (unless it should be there)

Rule #2 - run your own server (or VPS), and keep other people off of it

Rule #3 - lock the box down tight - port 22 (from specific IPs) and 80/443 from global

PS. JavaScript is executed in the web browser - there is not much you can do to secure it (other than obscure it), nor should you have to (eg. NOT trusting external data is rule #0).

gahooa
Thank you, great info :D
justin
+6  A: 

You can use .htaccess to cut off remote access to PHP scripts (of course, you'll still be able to access them locally with server-side include). I presume your contact scripts are also PHP scripts. They can be handled this way too. Either way, if PHP works on your server, even if a user knew the location of a PHP file, they wouldn't be able to see the source code anyway. This only prevents certain unauthorized execution.

Regarding sensitive or protected Javascript, you can use a JS compressor like this to obfuscate the code, but since JS is executed client-side, the user will be able to see whatever source code you give him.

Steven Xu
Good idea with the .htaccess, I'll mess around with that idea. Thank you!
justin
Obfuscation is definetely the only way to protect your js.
Jonno_FTW
+2  A: 

Another tactic is to store such PHP scripts above the public web folder. Your scripts can still access them. I often use this for data that I want to make available to logged in users for download. I have to make a script specifically to retrieve and send them the data, when it's needed, but nobody can access that data unless they are logged in and the script sends it to them.

With your scripts, it's even simpler - you don't make a means to access them. Your own scripts can include them, of course, and using .htaccess to control access is another worthwhile step.

Frank DeRosa