Javascript Comments are security risk?

Question

During a recient PCI audit the auditor said that we had major security risks because

1. It was possible to download static resources from our website such as images css and javascript without prior authentication.
2. Our javascript had comments in it.

Personally I think that this is not a security risk at all. The images css and javascript where not dynamically created and they contained no data on our backend, our customer details and on mechanisms.

The comments within the javascript were just simply explaining what the methods in the javascript file did. Which anyone who reads JS could have found out anyway.

How does that show "information leakage"?

Are comments within javascript really a security risk?

Answer 1

Depending on how strict the audit, downloading images etc without authentication COULD be seen as a security risk (think diagrams, charts, graphs...).

Removing comments in the javascript is like obfuscating the code: it makes it a bit harder, but still not impossible to understand what's going on. JavaScript should be seen as enhancing-only anyway, all your security should be (duplicated) at server-side. Having anyone understand what the JS does should not be considered a risk.

Answer 2

Without getting into if they are a security risk or not, minify your JS on production environment, this will prevent the "information leakage" and help (in some way at least) to secure the information of your website.

regarding the security risk, I don't think JS comments are a risk at all, every website content (static) can be downloaded without authentication. (unless defined otherwise)

Answer 3

Not if they only reveal how the code works. Any sufficiently determined person could find that out anyway.

That said, it is probably a good idea to minify the JavaScript; not because of security, but because it will reduce download times and therefore make your site a bit more responsive.

Answer 4

JavaScript comments can be. depends on your logic, but certainly as it is publically available, you are giving more visibility to the workings of your code.

There are other reasons for removing this as as well, such as file size, and as a result download size.

Tools such asd JSMin can help you remove the comments and perfrom a crude obfuscation of the code.

Answer 5

It depends on the content of the commentary. Because there is no way, without human intervention, to examine the content of comments to determine whether they are risky, the most efficient way to audit this is to declare all comments in client-facing source code to be risky.

The following are examples of potentially risky comments.

// doesn't really authenticate, placeholder for when we implement it.
myServer.authenticate(user,pass);

or

// don't forget to include the length, 
//the server complains if it gets NaN or undefined.
function send_stuff(stuff, length) {
...
}

or

function doSomething() {
    querystring = ""
    //querystring = "?TRACING_MODE=true&"
    ...
    //print_server_trace();
}

Another example might be if you include a source code history header, someone might be able to find some security weakness by examining the kinds of bugs that have been fixed. At least, a cracker might be able to better target his attacks, if he knows which attack vectors have already been closed.

Now, all of these examples are bad practices anyway (both the comments and the code), and the best way to prevent it is by having code reviews and good programmers. The first example is particularly bad, but innocent warnings to your team mates, like the second example, or commented-out debugging code, like the third, are the kinds of security holes that could slip through the net.