I am testing an application and come across few javascript pages that are publicly accessible. I have earlier also found few websites which allows .js pages public access. So as per me this can be considered as a security issue, since one of the ngapp.js page contains entire logic of the angularjs page. And if wants to secure such pages post authentication, is it possible? Can someone please clarify this?

  • 2
    No as far as it isn't the server side javascript code, which seems very unlikely here. How could you execute js function if the file is private ?
    – Xavier59
    Commented Oct 20, 2016 at 12:16

2 Answers 2


So I'm guessing the drive of your question here isn't whether the JavaScript files are obfuscated or not but rather whether they're accessible pre-authentication?

If that's the case then I'd say it shouldn't be an issue as the JavaScript is sent client-side and therefore no sensitive information should be embedded in it.

With that said, as a hardening measure I generally recommend not providing any information to an attacker that I don't have to , so I would restrict access to post-authentication wherever possible. Things like Angular apps can disclose a lot of information like valid application paths which is kind of useful to attackers in trying to find other issues.

In terms of how to achieve this, I'd suggest that you could separate the templates of the site, such that the main Angular (or similar) app is accessed post-authentication only.

  • Exactly, in case of one of the angularJS application, i can see ngapp.js file where all the variables are defined like x-csrf-token, and complete flow that is application, is accessible without authentication. Similarly node js application also have js file only that is considered as source code of the application. So that should be accessible post-authentication only.
    – PenGeek
    Commented Oct 21, 2016 at 5:36

This is the intended design, and not an issue, except when site authors forget that this is the intended design.

In a web application, Javascript must be readable by the browser, because that is where it is parsed and executed. And anything that's readable by the browser is readable to an attacker. Therefore, the security of the system cannot depend on the secrecy of the Javascript.

You may be thinking, instead, of the rules around CGI scripts. A CGI script is executed on the server, not the client, and therefore does not need to be readable by the client. Furthermore, it isn't unusual for "secret" information (like database connection strings with usernames and passwords) to be embedded in the CGI script, which means that having it be readable to the client is very bad. And because that's a somewhat common web server misconfiguration (to allow CGI script source to be downloaded by the client), there's a security issue there.

Of course, some web authors prefer that their Javascript not be easily readable. This is generally an Intellectual Property concern rather than Security, although Malware authors in particular will use various obfuscation techniques (here's an example) to make it difficult for the attacker to read their code. This is not a true security measure, but it does increase the cost for the reader to determine what the Javascript is doing.

Sometimes authors forget that their Javascript isn't secret. BMC Remedy used to have a "security measure" to protect credentials when the connection was over unencrypted HTTP. Javascript code would "scramble" the user's password before it was submitted over the network from the browser to the server. Unfortunately, the "scrambling" was along the lines of "Replace A with Q, replace B with G, ..." and was easily reversed by any attacker who read the Javascript and captured the unencrypted traffic.

  • Based on the other answers, I assume the question was referring to something more along the lines of a website that doesn't have open sign-up (closed organization?) and the javascript isn't required on the sign-in page. If this were the scenario, then I suppose it would be "safer" to include things in your js that you wouldn't want just anyone to read, but I would still consider that bad practice. Commented Oct 20, 2016 at 21:26
  • To be specific here, take an example of angularJS or NodeJs applications where the source code of the application is built into JS file like ngapp.js or main.js or similar named js file. Should those files containing the complete logic of the application be accessible publicly?
    – PenGeek
    Commented Oct 21, 2016 at 5:41
  • @DPrajapati If making them public harms something, then something's wrong with the application. Consider the case where, as Rory McCune suggests, you block "anonymous" access to the Javascript and require login... do you trust your authorized users with the application logic? Every one of them? Completely? And everyone who might have access to their computers and/or passwords? The bottom line is, Javascript is readable to the browser. Your security model must assume the attacker can read it.
    – gowenfawr
    Commented Oct 21, 2016 at 11:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .