{'fraction_non_alphanumeric': 0.019595448798988623, 'fraction_numerical': 0.0037926675094816687, 'mean_word_length': 5.8826086956521735, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Battles with False Positives in Static Analysis of JavaScript Web Applications in the Wild

Now that HTML5 technologies are everywhere from web services to various platforms, assuring quality of web applications becomes very important.While web application developers use syntactic checkers and type-related bug detectors, extremely dynamic features and diverse execution environments of web applications make it particularly difficult to statically analyze them leading to too many false positives.Recently, researchers have developed static analyzers for JavaScript web applications addressing quirky JavaScript language semantics and browser environments, but they lack empirical studies on the practicality of such analyzers.In this paper, we collect 30 JavaScript web applications in the wild, analyze them using SAFE, the state-of-the-art JavaScript static analyzer with bug detection, and investigate false positives in the analysis results.After manually inspecting them, we classify 7 reasons that cause the false positives: W3C APIs, browser-specific APIs, JavaScript library APIs, dynamic file loading, dynamic code generation, asynchronous calls, and others.Among them, we identify 4 cases which are the sources of false positives that we can practically reduce.Rather than striving for sound analysis with unrealistic assumptions, we choose to be intentionally unsound to analyze web applications in the real world with less false positives.Our evaluation shows that the approach effectively reduces false positives in statically analyzing web applications in the wild.