Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a web-app should one strive to hide as much of the code as possible, for example from view source? In particular I was wondering should JavaScript be hidden, especially ones used for Ajax? I was thinking that if the JavaScript was an external file the file could not be on the web server or restricted using .htaccess

EDIT: I realize I can't completely prevent the user from seeing JavaScript as it's interpreted on their end. However I was wondering is there a point in detering them from viewing such code, for example making it slightly harder than simply type in

share|improve this question
Could JS be hidden in the session layer for PHP? (just vaguely remember hearing something about that) – Travis Thompson Feb 14 '13 at 20:20
@Travis - Can (client-side) JS be hidden by ____? No. For the browser to run the JS, it has to download it. I have no idea what "session layer for PHP" means. TCP/IP doesn't really have an OSI session layer (HTTP would be the application layer being equivalent of layers 5-7), though HTTP typically does (user) sessions via session cookies (unique text strings identifying a user like a guid) in HTTP request headers. I'm not aware of any browser that runs JS delivered via a cookie or HTTP header, and if one did it still wouldn't be "hidden" as it would be easily retrievable. – dr jimbob Feb 14 '13 at 23:03
There's little reason to even attempt to hide the code used for basic web page use. The primary reason people obfuscate code is because they don't want others to be able to copy that code. By obfuscating the code, they make it harder (not impossible, and not very hard) for somebody to copy their code and use it on their own site. It's not a security thing. – Tom Marthenal Feb 17 '13 at 7:03
@TomMarthenal how does obfuscating the code make it harder to copy? What do you mean by "There's little reason to even attempt to hide the code used for basic web page use"? – Celeritas Feb 18 '13 at 0:54
@Celeritas if your company makes a cool web app with lots of clientside JavaScript, they probably want to prevent other companies from making a clone of their web app and stealing their customers. By obfuscating the code, which anybody can see, you make it harder to make a copy of the code, since it's purposefully made difficult to understand by a human. You can still make a copy of the obfuscated code, but normally you will want to modify it (e.g. to work with your server), and that's harder. Obfuscating code has little to do with security and lots to do with protecting property. – Tom Marthenal Feb 18 '13 at 7:43
up vote 36 down vote accepted

Javascript code executes on the client browser, so the client browser sees the code, and every user can obtain it. At best you can obfuscate the code so as to (try to) hide its meaning and behaviour. Obfuscation will not deter motivated attackers (it will just makes them a bit angrier), so it would be quite unwise to use it as foundation for your security model.

If you want to hide code, don't send it to the attacker's machine; keep it on the server side.

share|improve this answer
You could also minify the code to make it even more annoying for an attacker to go through the code. – Joshua Terrill Dec 18 '14 at 21:31

This is not possible because you cannot enforce a client's behavior. Any requests the client makes can be intercepted and manipulated with TamperData or BURP. Any JS that is executing on a client can be debugged using FireBug.

I have seen some developers go the path of (in)security though obscurity, which I consider to be a carefully engineered vulnerability that should be avoided entirely.

share|improve this answer
"Carefully engineered vulnerability". Best Domitian for obscurity. – Ayesh K Dec 19 '14 at 6:25
Heh, and all the time wasted on that Carefully engineered vulnerability while a great karmic ego massage for the one doing it, is time best spent elsewhere developing a security model that actually works. – Fiasco Labs Nov 1 '15 at 20:14

First, any server-side javascript that you may run (e.g., if you webserver is node.js) should be hidden from visitors. Any client-side javascript must be downloaded by users to run on their browsers, and can't be hidden. You can minify/uglify your code and if you want, and you shouldn't feel compelled to also serve the original un-minified version. However, they still have fully functional minified code on their machine; the main difference is that the minified version no longer has convenient descriptive names for humans to parse out. This makes it a little bit more difficult to step through the client-side logic, but its relatively straightforward to do as you have a JS debugger built into most modern browsers.

Bottom line: You cannot assume or rely on your client-side javascript being secret -- its run by the browser.

share|improve this answer


  • Load propitiatory client side JavaScript code after the user has logged in to the web site.
  • If you still don't want authenticated users to see the JS code, then load a JS on the client that calls another JS file that runs on the server or call a service such as a WebAPI. Off course, you want to secure the communication channel, perhaps using HTTPs.
share|improve this answer

Doesn't the yui compressor make it difficult for human readability? In any case, you shouldn't do validation just on the client side. Remember, it's not called client server for nothing, so let the server do most of the work. The thing to remember is the world wide web was never meant to be opaque to the endpoint. That moniker belongs to native applications.

share|improve this answer
difficult for human readability = obfuscation/minification/ulgification which has already been discussed. – Fiasco Labs Nov 1 '15 at 20:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.