9

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 www.mywebsite.com/how_login_is_done.js

Improve this question
5
  • 1
    Could JS be hidden in the session layer for PHP? (just vaguely remember hearing something about that)
    – Travis Thompson
    CommentedFeb 14, 2013 at 20:20
  • 11
    @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
    CommentedFeb 14, 2013 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
    CommentedFeb 17, 2013 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
    CommentedFeb 18, 2013 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
    CommentedFeb 18, 2013 at 7:43

5 Answers 5

Reset to default
39

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.

Improve this answer
1
  • You could also minify the code to make it even more annoying for an attacker to go through the code.
    – Joshua Terrill
    CommentedDec 18, 2014 at 21:31
14

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.

Improve this answer
2
  • 1
    "Carefully engineered vulnerability". Best Domitian for obscurity.
    – AKS
    CommentedDec 19, 2014 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
    CommentedNov 1, 2015 at 20:14
9

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.

Improve this answer
    0

    Options:

    • 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.
    Improve this answer
      0

      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.

      Improve this answer
      1
      • difficult for human readability = obfuscation/minification/ulgification which has already been discussed.
        – Fiasco Labs
        CommentedNov 1, 2015 at 20:16

      You must log in to answer this question.

      Start asking to get answers

      Find the answer to your question by asking.

      Ask question

      Explore related questions

      See similar questions with these tags.