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

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.