JavaScript obfuscation refers to taking normal, human-readable JavaScript code into a form that is intentionally difficult to read and understand. Obfuscation is generally used to conceal the intended meaning of the code - and as a result, makes it extremely difficult to follow or reverse-engineer the functions of the code. Unlike encryption of code, obfuscating code doesn’t require an algorithm or private key to run. The logic and functionality of the code remain the exact same, but the code is full of vague and opaque function names, strange programmatic structures and encoded strings.
Developers can sometimes use tools like JavaScript obfuscators to protect their code and intellectual property to prevent it from being stolen. But from a security perspective, especially in the context of third-party scripts, obfuscated code is a massive red flag. Attackers often use this obfuscation to hide their malicious code, which could be anything from malware, data-stealing logic or exploit code, inside what looks like a random jumble of text. This alone can often bypass simple security scanners and make manual analysis of scripts much more difficult.
Why is Deobfuscating JavaScript Important for Security?
When it comes to web security, payload visibility - or the ability to see and inspect the code running on your site - is absolutely critical. Deobfuscating JavaScript (reversing or decoding the code) provides a security analyst a clear understanding of the script and what it’s running under the hood. If you can’t see through this obfuscation, you’re effectively blind to what that code could be doing.
Relying on surface-level security measures alone is not enough to protect your site. For example, Constant Security Policy headers can restrict where scripts are allowed to load from, but provide no visibility into the payload of the scripts themselves. If a third-party host is compromised and starts serving obfuscated malware, like we reported on in 2024 with the Polyfill attack, a CSP won’t tell you that the script’s content is malicious. Because it’s coming from an approved source, it will trust it and not flag on the potentially malicious content being served.
Another reason payload visibility is critical is due to the dynamic nature of most client-side attacks. As covered in our Q2 client side attack report, cside has begun to see more and more attacks that inject obfuscated code into sites that often beacons back to a command-and-control server for further instructions. This can open a site up to threats such as malicious advertising and redirects, cryptojacking scripts and browser exploit kits, all controlled dynamically by a third party.
What are Common JavaScript Red Flags to Watch For?
Unreadable or Garbled Code
One of the biggest red flags to look out for is if a script’s code is a nonsensical tangle of characters, long numeric arrays and weird functions that don’t resemble any human-readable code.. Attackers will often hide strings by encoding them using hexadecimal, Base64 and Unicode escapes, splitting them into unreadable pieces. Such variables will look like `_0x5e` or `aa1122bbcc` and will rarely have any meaningful identifiers. Legitimate libraries may minify code that resembles this, but they typically won’t be deeply obfuscated with junk data.
Encoded/Junk Data in Strings
Malicious scripts will often hide critical strings (like URLs, keywords, JavaScript payloads) by encoding and inserting junk data into them. For example, they might have a URL obfuscated via hexadecimal encoding and sprinkle multiple constant junk substrings throughout it to thwart decoding. Functions like `atob()`, `unescape()` and custom routines that transform strings are often clear indicators of the script trying to conceal something. In the past, attackers have been known to insert random text or use multiple layers of encoding to hide variables like `eval` and `document.cookie`.
Dynamic Function Generation (eval and friends)
Another red flag in a script is the use of functions like `eval()`, the `Function()` constructor or `setTimeout()` and `setInterval()`. This often means that the script is constructing code at runtime, which can be a favored technique of malware to unpack the real payload. Modern, legitimate scripts rarely use `eval()` due to the security and performance implications, so its presence in a third-party script should raise an eyebrow. Similarly, creating DOM script elements dynamically using `document.createElement(‘script’)` is another way to inject malicious code. If you spot code that builds a `<script>` tag with a suspicious external URL, that’s a major warning sign that your site may be compromised.
Suspicious External Connections
Any third-party script that references external domains or IPs that aren’t related to the site’s function is a telltale sign of malicious behavior. For example, if an obfuscated script suddenly makes a `fetch()` or XHR request to a domain that’s unrelated to the site, this is often an indicator of malicious behavior. Attackers will often use their own servers for exfiltration or control endpoints and any appearance of these domains in third-party code is a red flag.
HTML & DOM Manipulation Tricks
Obfuscated malicious JavaScript will often manipulate the page in stealthy ways. This is often seen by creating invisible or overlay elements, setting extremely high `z-index` values (to cover the page with a fraudulent input or prompt) and injecting forms and event listeners. cside recently reported on an attack that took place on CoinMarketCap that used a malicious pop-up with a high `z-index` value to trick users into connecting their wallets to a malicious third-party, draining their wallets of any cryptocurrency inside.
Polymorphic Obfuscation in JavaScript Attacks
One of the more advanced & evasive techniques that attackers can use to hide their script’s true intent is polymorphic obfuscation. Polymorphic obfuscation is code that changes its structure each time the payload is delivered, even though the underlying behavior remains the same. This technique is borrowed from traditional malware development, where polymorphic binaries mutate their appearance to evade antivirus detection. In the browser-based JavaScript ecosystem, attackers achieve this similar evasion by rotating variable names, restructuring functions, altering the control flow, and layering randomized junk code throughout the script.
This means that two payloads with the same intention, like skimming a checkout form on a website, may look entirely different on the code level. This makes detection methods like hash-based signatures and static IOC-based filters fall short, and overall incredibly difficult to protect against. Because the code is dynamic and changing, perimeter defenses like Content Security Policy (CSP) and Subresource Integrity (SRI) can’t provide enough protection for your site against polymorphic attacks. These protections are able to validate where the script comes from, and if it’s been changed, but offer no insight into what the script actually does at runtime.
What Tools and Technologies Debofuscate JavaScript?
Deobfuscation is essentially a reverse-engineering exercise to transform the encoded strings and functions into something human readable. It often takes a combination of these techniques below to fully deobfuscate a script:
- Code Beautifiers or Formatters: Tools like JSBeautify, deobfuscate.io, JSnice and de4js can take a packed or minified script and re-indent the code to add line breaks, turning it into a properly structured piece of code. This doesn’t often remove the obfuscation, but makes the layout of the code more legible.
- String Decooding Utilities: With obfuscated code frequently encoding data using hex, Base64, etc., using simple decoding tools can recover the initial strings. Many security analysts use Python scripts or sites like Dencode.com to decode common formats.
- Manual Refactoring and Replacement: Sometimes, the easiest way is the most manual way - after using a code beautifier, reading through the code, and statically replacing obfuscated variable names or functions with their real meaning can help understand the intent behind some functions.
- AST Analysis: For very complex scripts, security researchers often turn to using custom-developed scripts to parse and transform the code. Using a JavaScript parser to get the Abstract Syntax Tree (AST) of a script allows a researcher to programmatically navigate the structure and remove layers of obfuscation. This approach can help automatically simplify things like control-flow flattening or elaborate encoding of functions, though it does require strong programming skills.
Can Obfuscated JavaScript Be Analyzed Automatically?
Automatic analysis and sandboxing are indispensable for handling large volumes of obfuscated JavaScript and catching threats in real time. Manually analyzing every script is often impractical, so organizations can employ a combination of dynamic sandboxing, static code analysis and threat intelligence to tackle understanding the JavaScript at scale.
- Dynamic Analysis using Sandboxing: One approach to determine what suspected code does is to run it in a controlled environment (using a browser that steps through the code, for example) and observe what it does. When an obfuscated script is executed there, the sandbox can often record behaviors that seem malicious. Does the script try to modify the checkout form? Does it make an AJAX call to a suspicious or known-malicious domain? Does it spawn hidden iframes or use a significant amount of CPU? Because the sandbox sees the script’s actions, it can flag patterns even if the code was obfuscated. Some sandboxes might even hook into the JavaScript engine to dump the deobfuscated code once the script has unpacked itself in memory. The dynamic approach is great because it doesn’t require an understanding of the code and instead directly observes the malicious outcomes, but it can be detected by advanced malware and modify its behavior if so.
- Static Analysis with Artificial Intelligence and Large-Language Models: On the static side of analysis, security tools often use pattern matching and artificial intelligence to examine the test and behavior of scripts to decide if they’re malicious, even if obfuscated. Using large-language models to often gain a baseline of activity from the script has become increasingly popular, as it allows a security analyst to quickly distinguish what could be a minified script and a malicious one.
At cside, our automatic analysis pipeline evaluates both obfuscated and deobfuscated JavaScript by running detection rules before and after normalization of the code to something readable. This dual-layer approach helps us catch evasive threats that might only appear once the code is unpacked. Unlike many traditional scanners, cside uses attribute-based detection models to see how a script interacts with the DOM API and what elements it may create, modify and attach to. These behavioural attributes allow us to see suspicious changes even if the script is heavily obfuscated or generated at runtime.
What are some real-world examples of Malicious Obfuscated JavaScript Attacks?
Obfuscated JavaScript has been at the heart of many real-world attacks that cside has reported on, from high-profile breaches to everyday malware campaigns.
- Magecart Credit Card Skimmers: Magecart is an umbrella term for groups that have historically injected malicious JavaScript into e-commerce sites to steal payment card details. In the British Airways attack in 2018, attackers compromised third-party scripts and inserted obfuscated skimmer code. This code was designed to steal credit card information on checkout pages and send it to attacker-controlled servers, all while blending in with legitimate scripts. Magecart attackers commonly use script obfuscation to encode functions and hide the true intent of the code’s logic. For more information on the British Airways attack, cside published a special report about the attack and (how we ended up with the domain used in the attack!)
- Cryptojacking Scripts: The rise of in-browser cryptocurrency miners also saw obfuscated code being used to implement their attacks. In a cryptojacking attack, an attacker injects a script that silently uses a visitor’s CPU to mine cryptocurrency. To avoid easy detection (outside of a user’s CPU usage spiking), the code was often obfuscated or served from a compromised content CDN. cside recently published how cryptojacking attacks have become more prominent in the last year and have changed heavily in the way they are executed.
- Progressive Web App Injection and Redirects: In 2025, cside reported on an attack that used a Progressive Web App to redirect mobile users to a Chinese-adult content scam. The payload of this attack had been seen before, but the delivery through a Progressive Web App was an incredibly unique attack vector. While PWAs are often ignored in the client-side security space, they too are susceptible to the browser-side attacks cside often sees.
What are The Best Practices for Ongoing JavaScript Security Monitoring and Defense?
Keeping your web application safe from malicious third-party code isn’t a one-time effort, but instead requires ongoing monitoring and good practices to minimize risk.
- cside’s proxy: The cside proxy acts as an intermediary between your site and external, third-party scripts, allowing us to intercept, analyze and stop JavaScript attacks before they execute in the user’s browser. Our proxy enables real-time monitoring of script behavior across every page load, without modifying the application’s codebase or adjusting Content Security Policy requirements. By inspecting scripts in both their obfuscated and normalized forms, the proxy can enforce rules and flag anomalies - even when attackers rotate obfuscation layers or inject dynamic payloads.
- Restrict and Validate Script Sources: Using Content Security Policy (CSP) headers to tightly control where scripts can be loaded from is another fantastic way to protect your site against unwanted attacks. Using a CSP rule to whitelist only your domains and known CDNs and blocking everything else is a great first step to secure JavaScript that runs on your site. Combining CSP with subresource integrity (SRI) checks, which can detect if a file is altered and prevent it from executing, can ensure you’re loading only what you intend to load.
- Stay Informed and Train Your Team: The threat landscape evolves incredibly quickly, and new obfuscation tricks and attack techniques emerge all the time. Invest in training your security teams, along with your development teams, about these trends and best practices to protect against them. Follow threat intelligence reports and update your own detection patterns accordingly. Ensure you have an incident response plan specifically for client-side incidents - for example, if you suddenly detect an obfuscated skimmer on your site, who do you alert? Preparing for these scenarios ensures a response that can minimize damage if handled properly.
Final Thoughts
In today’s browser ecosystem, third-party JavaScript is both a necessity and a risk for websites. Obfuscation techniques can serve legitimate code, but they’re also often used by attackers to hide harmful payloads - making it harder than ever to detect, analyze and respond to potential threats. Having the ability to deobfuscate JavaScript and monitor its behavior is no longer optional. It’s absolutely critical.
At cside, we’ve built our technology to give teams visibility into what’s really happening inside of third-party scripts. As client-side attacks continue to evolve, investing in payload visibility and real-time monitoring is the best defense you can deploy today. If you’re ready to take control of your third-party JavaScript risk, get in contact with us and explore more of our threat intelligence blog to stay updated on attack patterns.