Зависит от содержания комментария. Поскольку без вмешательства человека невозможно проверить содержание комментариев, чтобы определить, являются ли они рискованными, наиболее эффективный способ проверки заключается в том, чтобы объявить все комментарии в исходном коде, обращенном к клиенту, рискованными.
Ниже приведены примеры потенциально рискованных комментариев.
// doesn't really authenticate, placeholder for when we implement it.
myServer.authenticate(user,pass);
или
// don't forget to include the length,
//the server complains if it gets NaN or undefined.
function send_stuff(stuff, length) {
...
}
или
function doSomething() {
querystring = ""
//querystring = "?TRACING_MODE=true&"
...
//print_server_trace();
}
Другим примером может быть, если вы включите заголовок истории исходного кода, кто-то может найти слабые места в безопасности, изучив виды исправленных ошибок. По крайней мере, взломщик мог бы лучше нацеливать свои атаки, если он знает, какие векторы атаки уже закрыты.
Теперь, все эти примеры в любом случае являются плохой практикой (и комментарии, и код), и лучший способ предотвратить это - обзоры кода и хорошие программисты. Первый пример особенно плох, но невинные предупреждения для ваших товарищей по команде, как во втором примере, или закомментированный код отладки, как и в третьем, являются разновидностями дыр в безопасности, которые могут проскользнуть через сеть.