Phishing is no longer restrained to spammy text messages or fake emails from your CEO asking for help. Attackers are injecting small snippets of code onto websites that trick users into visiting a phishing site that seems identical to a legitimate site. The entry point for those attacks: chatbots, third party website scripts, analytics tools, and plugins that are hijacked by attackers. Because they know your security tools are not watching them.
This blog will cover some examples of these phishing attacks and dive into how they work. For a broader understanding of client-side attacks by a security engineer, you can read our article What is Client-side Security.
How to prevent these attacks:
- Monitor JavaScript behavior at runtime (what actually loads when a user visits your site)
- Reduce trust in third-party code and enforce change awareness (implement mechanisms to restrict third party scripts and understand code changes)
- Use a client-side protection tool like cside
Understanding phishing through the browser
Email phishing is like forging a fake letter. Client-side phishing is like an attacker creating a sign that gives customers instructions on where to go and what to do. If an attacker places that sign inside a legitimate location that customers have grown to trust, such as a store that they have visited multiple times before, they can trick unassuming customers into doing almost anything. That sign might ask them to scan a QR code and enroll in a new loyalty rewards program which captures personal information like their home address and possibly even their credit card details. The innocent customer, believing they are in a protected environment (such as inside a storefront or on your official website) won’t second guess the information requested.
Now, in the physical world an employee will quickly question why such a sign is in place. If the sign is in plain sight it won’t take long for someone to ask why it’s there. But on your website, only a small handful of team members look behind the scenes of website code. And very few of those team members (if any at all) are reviewing that code with a security perspective in mind. There are dozens of “third party” scripts on your website that no one is truly watching. Not because there isn’t a risk, but because it’s virtually impossible to monitor all those third party scripts in depth.
How Client-side Phishing Works
98.9% of websites use JavaScript for website functionality. A similar majority (93.8%) of websites use CSS for website styling. In layman’s terms: HTML = website page content (words, images), CSS = website styling (colors, fonts, placement), JavaScript = dynamic website functionality (forms, responsive features, marketing tools).
CSS and JavaScript control what a user sees on the page. JavaScript frequently pulls in code from third-party sources that are not written by your own team. This is by design, as otherwise you would have to reinvent the wheel and create every responsive feature on your website (not feasible). JavaScript on your website is like a supply chain that pulls in code that your team writes and from vendor tools that you have purchased (or are using for free).
But this creates an attack entry point.
Analytics, ads, chat widgets, A/B testing tools, consent managers, personalization engines all introduce code to your website. That can observe, modify, or replace what the user sees on the page.
Users visiting your website, believing they are in a protected environment, will follow instructions they are given even when they are unknowingly malicious.
Examples of phishing through the browser (JavaScript)
Form Interception Without Page Changes
One of the most common techniques is form interception. Instead of replacing a login page, malicious JavaScript simply hooks into existing forms:
- Overriding onsubmit handlers
- Listening for input events on username and password fields
- Copying form data before it’s sent to the legitimate server
From the user’s perspective, nothing looks wrong. The form is submitted normally. The page behaves as expected. But credentials have already been copied elsewhere.
Fake UI Inside Real Pages
JavaScript or CSS can also inject entirely new interface elements:
- “Session expired” login modals
- Security verification prompts
Because these elements are injected directly into the “DOM”, they inherit the site’s styles, fonts, and layout. They don’t feel fake because technically, they aren’t.
The URL is still your official, HTTPS secured company domain.
Examples of phishing through the browser (CSS)
Visual Deception Through Overlays
With nothing more than position, opacity, and z-index, CSS can:
- Place invisible input fields over real ones
- Overlay fake buttons on top of legitimate actions
- Capture clicks without users realizing it
The underlying form may still exist but the user is actually interacting with the malicious form laid over top of it.
Hiding Warnings and Security Signals
CSS can also suppress or obscure UI elements that would otherwise raise suspicion:
- Hiding consent banners or disclosures
- Obscuring security warnings
- Moving legal or privacy text off-screen
Why Traditional Security Tools Miss This
Current web security tooling was not designed to look at the client-side. And unfortunately, they are rarely designed to truly protect users.
Static analysis tools inspect source code before deployment. They don’t see runtime mutations. Server-side logs capture backend requests, not client-side behavior. Even Content Security Policies are often loosened for business needs, allowing broad script execution from trusted vendors.
Why Don’t Security Teams Spot Malicious Javascript?
These attacks don’t slip by security teams due to negligence or lack of competence. They slip by because they are designed to be invisible.
Security teams are focused on protecting servers, APIs, and infrastructure but the browser runtime is a soft spot.
And JavaScript obfuscation makes detection even harder:
- JavaScript obfuscation: 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. Even experienced engineers can struggle to determine what an obfuscated script is doing, let alone why. Malicious code survives through reviews while remaining fully functional in the browser.
There are plenty of mechanisms and vendor tools to de-obfuscate JavaScript code but this still requires a manual review of each case. cside security engineers wrote a guide on how to deobfuscate JavaScript code although it is strongly recommended to use an automated monitoring tool like cside’s client-side security platform.
