What is the standard method for protecting JavaScript, CSS, and other sensitive source files on a web host?

I%26#039;m sure there is a web programming pattern to add this layer of security to my web host, I just can%26#039;t find it. Changing file permissions doesn%26#039;t help because the world needs to be able to read files for the pages to behave correctly. Since they can read the files, they can also just navigate to them and read the source code. Please help!
What is the standard method for protecting JavaScript, CSS, and other sensitive source files on a web host?
is it really worth it?





css has to be read , as css, so it must be css. (you could stop using it,. JavaScript can do much of the same, but sloppier). css can be served from a cgi program , only to the pages on your site, with any extra crazy security you want (but they can be %26#039;view sourced%26#039;)





html has to be read, as html, so it must be html (you could use less html and use more ajax with headers to protect the data from prying eyes)





JavaScript doesn%26#039;t need to be read, it needs to be executed! it need not resemble the original code (look at google%26#039;s scripts!) A simple packer makes JavaScript unreadable to all but the best hackers!


http://dean.edwards.name/packer/ is the easy one time packer, there are other versions for automated packing!





and of course, all server side programs are protected by your server!
What is the standard method for protecting JavaScript, CSS, and other sensitive source files on a web host?
It%26#039;s %26quot;Don%26#039;t put anything sensitive in client side code in the first place%26quot;.





The browser has to be able to parse the code, and if the browser can, then so can users.





http://dorward.me.uk/www/hide/
Reply:Never put anything you don%26#039;t want to be read by visitors into files that will be directly included to a URL response. No %26quot;secrets%26quot; (e.g., account/password combinations) should ever be in such files. You need some sort of controller that has access to your secure layers and mediates the handling of sensitive information without returning any of it in the response. This can be any of the usual types, e.g., servlet, jsp, php, perl, etc.





As for non-secret info that you just prefer not to make publicly available, the best you can hope for is to obfuscate it beyond the means of the lighter-weight programmer types to figure out. You can minify the code, removing all comments and whitespace. You can use non-documentating names for methods and fields. Means you have to manage multiple files that do the same thing, since the obfuscated version is not likely to be very easily directly supportable; then, evolutionary changes have to be made to the regular version, and a new obfuscated version created ...ugh!





Frankly, it ain%26#039;t worth the effort just to hide source code that will be included client-side. Look at the quality of the source code released by Yahoo in their YUI JavaScript libraries. I%26#039;ve done some pretty nifty stuff in JavaScript, but, for everything I%26#039;ve done that would be generally useful, there are alternate implementations as good or better that have been published by one of the Open Source library groups. When I find my code being recycled by others, I%26#039;m flattered. I enjoyed solving the problem - if it saves someone else some effort, cool.





Do you think that your code is worth %26quot;stealing%26quot; in some way that negatively impacts your business? If not, and there are no %26quot;secrets%26quot; in the code, let %26#039;em look and accept the compliment that anyone was interested.
Reply:It%26#039;s not possible to protect any sensetive information that is to be sent to a browser. The only thing you can do is process it server side.