views:

57

answers:

4

Is there any way/reason to keep your js/jQuery ouside public_html? Are there security benefits?

A: 

Unless it's in a writable location (which it shouldn't be), no.

Ignacio Vazquez-Abrams
It's not. Thanks.
foxtrot
+2  A: 

All javascript is readable no matter where you put it on your server. The best you can do is obfuscate it:

http://stackoverflow.com/questions/194397/how-can-i-obfuscate-javascript

Plus, jQuery is open source, so there is no benefit of storing it any place in particular.

Andrew M
I meant my actual development code for jQuery, but you're right in that I wouldn't be linking to the actual jQuery from ouside public_html. It's from the jQuery site. Edit: I forgot to add that I already obfuscate it. Just wondering if there was more security I could use to my advantage. :)
foxtrot
Yeah, if it is your code, it is still readable by anyone using the View Source function of any browser. If you need some protection, obfuscation is really one of the only ways.
Andrew M
Thanks for the help. Much appreciated!
foxtrot
+1  A: 

JavaScript is code that is executed by your visitor's browsers so it must be public. It is good practice to compress your JavaScript code because it will require less bandwidth to transfer and it will make it harder for other to read it (i.e. figure out how to exploit it). Yahoo offers a free JavaScript compressor.

Lawrence Barsanti
It won't take more than 5 minutes to find a common decompresser. There are lots of them.
sanmai
If your code being readable is a *security* risk, you're doing something badly wrong. Security should be handled server-side. Compression has bandwidth benefits if you're a very high-volume site, but can have downsides too; e.g. a programmer who has a problem with your site might provide a useful bug report if he can read the JavaScript, but is unlikely to bother if it's obfuscated.
Porculus
A: 

Is there any reasons to keep your JavaScript outside public_html?

  • It allows for a more optimized server-side and client-side caching of the resources.
  • It allows for a more parallelized download of the resources from the server by the client.
  • It makes it easier for you to separate your UI's presentational layer (your HTML code) from its controls and logic layer (your JavaScript code), which also means:
    • It makes it easier for you to manage.
    • It's easier to share across your team (you won't have designers and developers working on the same pieces of code, and you separate functionalities in smaller resources (even if you compile them together for a production server).
    • As a result of this, the design of your JS code will most probably be more prone to testability.
  • It also allows you to not load some bits and pieces you may not need all the time. It thus also facilitates code reuse for some of these bits when they're needed somewhere else, without having to duplicate them in other huge files of stuff put together.

Is there any ways to keep your JavaScript outside public_html?

Sure. Just put the code in a external JS files and inject them normally using script tags. Or inline them with your build script or template engine. Be sure to decouple your HTML from your JS (no ugly JS injected directly with on<something>=javascript:doThisOrThat() in your tags) and to use more standard and robust methods instead (use a system compliant with the W3C DOM Level 2 Event model. jQuery is very practical for this anyway, as it's designed with progressive enhancement in mind).

Are there security benefits?

Short answer: no. But you have a clear increase in code quality, which would be easily relating to your overall security. But having your JS within the same file is not a security flaw. If what you meant is that you're concerned about your JS code being visible by visitors, as other answers already mentioned: you cannot do anything it about this. You can make it harder and more painful to look at (via obfuscation), but this won't prevent someone who really wants to to dig into your code. My recommendation: don't waste your time and efforts on that.

haylem