Category: Client-Side Security

Healthcare organizations routinely handle extremely sensitive personal data – including patient records, diagnostic histories, financial details, and personal identifiers. This has made the sector an attractive target for cybercriminals – and the consequences of a breach are severe.

According to IBM’s 2025 Cost of a Data Breach Report, healthcare data breaches have been the most expensive of all businesses for the past 14 years. The sector topped IBM’s league table for breach costs in 2025, with an average of $7.42 million per incident in the US. 

A perfect storm of technical vulnerabilities and financial gain entices cybercriminals: rigid legacy systems, an increasingly digitized and distributed IT infrastructure, and the high value of patient data on the dark web. Compromised medical data commands high prices because, unlike financial credentials, patients cannot change their diagnoses, dates of birth, or insurance histories. 

Healthcare organizations have invested in perimeter, server-side, and ransomware defenses – but the client-side attack surface remains exposed. In the absence of robust controls, the browser – where patients interact with portals, submit forms, and enter PHI – is a major vulnerability.  

Top Risks Facing Healthcare

Before addressing the client-side gap, healthcare organizations must understand the sector’s broader threat landscape.

1. Phishing

Phishing, in which attackers use deceptive emails to harvest credentials or deploy malware, remains one of the most common attack vectors across all sectors – and healthcare is a prime target. Successful phishing campaigns are typically used to harvest PHI or deploy malware as an initial step toward compromising this sensitive data at scale. 

In May 2026. Microsoft warned of a large-scale phishing campaign that disproportionately targeted the healthcare sector, using credential theft and token compromise to bypass multifactor authentication. 

Conventional defenses, such as email filtering and security awareness training, mitigate exposure but can’t eliminate it. Aware of this, cybercriminals deploy phishing techniques to target healthcare because of its large, distributed workforce. Often, a single compromised credential is all an attacker needs to compromise PHI. That makes limiting what can be accessed and exfiltrated through the browser a critical second line of defense.

2. Ransomware

Ransomware attacks – malware that automatically encrypts or steals an organization’s systems and demands payment for their release – against critical sectors surged 34% year-on-year in 2025, with healthcare among the most frequently targeted. This threat is pervasive because operational downtime directly endangers patient safety, increasing pressure to pay. 

Recent examples include the June 2024 Synnovis ransomware attack, which disrupted pathology services used by NHS organizations in England and delayed over 11,000 appointments. Another example is the February 2024 Change Healthcare ransomware attack in the US, which compromised the personal and healthcare data of approximately 190 million individuals.

3. SQL injection and XSS

SQL injection and cross-site scripting (XSS) remain significant threats to healthcare web applications.

• SQL injection: attackers insert malicious code into database queries to extract or manipulate data.
• Cross-site scripting (XSS): malicious scripts are injected into web pages and executed in users’ browsers.

For example, in 2026, OpenEMR – a medical practice management software – disclosed an SQL injection flaw in its Patient REST API that could expose PHI and credentials. This occurred alongside multiple stored XSS vulnerabilities in patient-portal and staff-facing workflows that allowed malicious JavaScript to execute in clinicians’ browsers.

4. Third-party vendor risk

Third-party risk – where attackers exploit weaknesses in external suppliers, partners, or tools that have access to an organization’s systems or data – is a perennial focus for healthcare security teams. 

The scale of this threat is underscored by an eye-watering stat: in 2025, over 80% of PHI stolen in the US was taken from third-party vendors and business associates, not from hospitals themselves. The Synnovis and Change Healthcare ransomware attacks are cautionary tales of how third-party risk can be exploited when sufficient security measures are not in place. 

The Client-Side Gap

What’s less well documented – and where healthcare organizations remain worryingly exposed – is the substantial risk posed client-side: the scripts, pixels, and third-party code running directly in the patient’s browser.

Third-party tracking pixels and PHI leakage

Third-party tracking pixels are small pieces of JavaScript code embedded in web pages that collect and transmit data about user behavior to external platforms. In healthcare, their proliferation has created a significant attack surface. Almost all hospitals (98.6%) use at least one tracking code that transfers data to third parties. Around a third (33%) of healthcare websites still carry Meta pixel tracking code. 

Third-party analytics pixels, advertising tags, and session recording tools execute in the browser with direct access to the pages patients interact with – including form fields containing PHI. Healthcare organizations must have real-time visibility and control over these scripts. Without this, they have no reliable way of knowing what data is being collected, where it’s being sent, or whether it’s compliant.

Since hospitals embedded Meta’s third-party trackers on public websites and patient portals, which inadvertently sent sensitive health data to the tech giant without patient consent, settlements have exceeded $10 million.

To gain control of this threat, healthcare organizations must maintain a continuously updated inventory of every third-party script running on patient-facing pages. This provides the oversight needed to enforce least-privilege data access rules that restrict what each script can read, and block unauthorized outbound data transmissions before PHI leaves the browser.

Digital skimming and formjacking

Organizations are increasingly targeted by digital skimming attacks, in which malicious code is injected into patient forms, appointment-booking pages, and payment fields on healthcare portals. Skimming exploits trust in third-party scripts to compromise data as it’s entered, before it’s submitted. 

Cybercriminals commonly target valuable form data on healthcare portals by silently modifying legitimate analytics or chat widgets to exfiltrate everything from patient records to financial details.

A Content Security Policy (CSP) can restrict which scripts load, but it can’t monitor or control what authorized scripts do in the browser once they’re running. To protect patient-facing forms, healthcare organizations must augment CSPs with script-level controls. This comprehensive approach restricts which scripts can read patient-entered data and blocks outbound transmission to unauthorized domains.

Code reverse engineering and tampering

Proprietary clinical logic – diagnostic algorithms, patient risk scoring, treatment decision support – is an essential element of healthcare apps. Increasingly, this intellectual property is being embedded directly in client-side JavaScript – an inherently exposed script. This means anyone loading the app in a browser can view and analyze it. AI is making it even easier for threat actors to counter obfuscation and reverse-engineer applications, and as AI dev pipelines increase, more vulnerable code is being shipped. 

To protect both patient data and the intellectual property on which the platform is built, organizations must ensure code integrity by implementing LLM-resilient obfuscation and tamper detection – or face the consequences. Without these defenses, cybercriminals can reverse-engineer or modify proprietary algorithms, or use them to map exploitable vulnerabilities in the app.

Regulatory compliance

Regulatory pressure is intensifying on the client side, reflecting its importance from a security perspective. This is playing out across three key pieces of legislation:

• PCI DSS: Since March 2025, PCI DSS v4.0’s client-side security requirements have made it mandatory to implement documented controls for all scripts that execute in the payment page environment. 
• HIPAA: In the US, the enforcement of HIPAA rules around how healthcare entities and their business associates protect PHI in physical and digital environments remains vigorous. 
• GDPR: In Europe, GDPR continues to impose strict consent and data minimization obligations that third-party pixels routinely violate in healthcare contexts.

Client-side protection – enforcing script-level data access controls, maintaining detailed audit trails of third-party behavior, and blocking unauthorized data collection in real time – enables healthcare organizations to achieve ongoing compliance with these frameworks, without adding significant operational burden.

Closing the Gap

Client-side protection must not be an afterthought for healthcare organizations. Unmonitored third-party pixels, sophisticated skimming techniques, vulnerable application code, and the value of PHI combine to make the browser one of the sector’s most exposed attack surfaces.

Jscrambler’s unified client-side security platform gives healthcare security teams real-time visibility and control over every script running in the browser. This clarity prevents unauthorized data collection and PHI exposure before it happens – from blocking rogue third-party pixels to protecting proprietary application code against reverse engineering.

Ask a room full of CISOs where their architectural edge begins, and you’ll likely get a dozen different answers. Some will point to the network boundary. Others will say identity has become the new perimeter. Cloud security teams may argue it’s the workload. Mobile teams will point to the endpoint. One of them is wrong.

The problem is that defining the edge has become far more complicated than it was a decade ago. As applications, users, data, and infrastructure have become increasingly distributed, the traditional perimeter has dissolved into multiple control points. But there’s another shift that’s receiving far less attention: the place where customers interact with applications, sensitive data is created, and third-party code executes has moved somewhere else entirely.

The browser has quietly become one of the most important architectural edges in the enterprise, and for many organizations, it’s also one of the least controlled.

Server-side security remains essential. Organizations have invested heavily in hardening infrastructure, securing cloud environments, protecting APIs, and enforcing identity controls. Those investments matter. But they largely stop at the point where the application reaches the browser. Beyond that boundary, organizations often have privileged access to data, code, and transactions but very little control over what actually happens. 

The Browser Is No Longer a Static Delivery Channel

It’s worth being precise about what “the browser” means, because it’s easy to file it under “client-side stuff” and move on. It isn’t a UI layer. Modern digital experiences are composed in real time, from first-party code, third-party services, payment platforms, identity systems, and AI-powered agents. All of it is assembled in the browser during live customer interactions.

Consider what a single page load actually involves. The average web page integrates dozens of external services: advertising tags, payment processors, shipping calculators, video players, chat widgets, analytics pixels, and increasingly, AI-powered assistants. None of these are exotic edge cases: they’re standard infrastructure for modern digital business, and each one executes with privileged access to whatever is on that page, including data a customer just typed into a form.

What makes this harder to govern than traditional infrastructure is that the browser isn’t static. It’s generated – per user, per session, often per request. Two customers loading the same page can receive meaningfully different JavaScript depending on their devices, locations, browsing histories, and which third-party scripts happened to load that day. Each session is, in a real sense, its own application.

This is the moment all inputs and outputs of the business flow through. Not the data center. The browser.

The Most Privileged Environment in the Enterprise, and the Least Controlled

When a customer opens a site, everything assembles at once: application logic executes, third-party scripts activate, customer data is rendered, payment flows initialize, and AI systems construct prompts using live context. Within milliseconds, a company’s proprietary logic, customer information, external services, and AI agents converge in a single runtime environment. Not in a data center. Not behind a firewall. Inside the browser.

The browser is now one of the most powerful environments in an enterprise, but one of the least governed. There is heavy investment in security, identity, privacy, and compliance across networks, cloud systems, and backend infrastructure. But once code and data reach the browser, many of those protections fade. Third-party tools inherit broad access. The logic is exposed by design. Data can be transmitted externally with limited real-time control.

The data makes the exposure concrete:

• Over 70% of application attacks now target the application layer, where business logic and client-side execution are directly exposed — not the network perimeter most security budgets were built around.
• Automated traffic, bots, scripts, and scrapers probing exposed workflows and authentication flows now account for more than 40% of all web traffic.
• Nearly 9 in 10 websites leak user data to external third parties, frequently without any visibility into how many entities ultimately receive it.
• Web skimming attacks, which operate entirely inside the browser session, have compromised more than 70,000 websites to date.

None of these are failures of the infrastructure security stack. They’re symptoms of a gap that infrastructure security was never designed to close, because the browser was never treated as a place that needed enforcement. It was treated as a delivery mechanism: somewhere code gets sent, not somewhere code needs to be governed. That assumption is now the problem.

Why Existing Tools Fall Short

This isn’t an argument that the existing security stack is poorly built. It’s an argument that it was built to answer different questions than the ones the browser is now asking.

Monitoring tools tell what happened. They don’t stop it from happening. Most client-side “security” today is really observability: a dashboard that flags an anomaly after a script has already executed, already accessed the DOM, or already sent data somewhere. Some platforms attempt to intervene by blocking scripts when suspicious behavior is detected, but these tools are primarily designed around a detect-and-alert model. Detection occurs after execution. Monitoring answers what happened. It provides limited ability to define and enforce precisely what is allowed to happen during execution.

CSP and SRI protect load integrity, not runtime execution. Content Security Policy restricts where scripts can load from and where data can be sent. Subresource Integrity verifies that a script hasn’t been modified before loading. Both are valuable, but assume trusted scripts behave as expected. Once an approved script executes, neither CSP nor SRI controls what it accesses, how it processes data, or whether it expands its collection scope within permitted destinations. Modern client-side risk stems from overprivileged third parties, configuration drift, and AI-driven context expansion within legitimate sessions. These controls were not designed to govern that.

WAFs protect traffic, not browser execution. A Web Application Firewall inspects requests and responses as they move between the client and the servers. Once JavaScript executes inside the browser, WAF visibility ends. It cannot see how scripts interact with the DOM, access sensitive fields, assemble contextual data, or transmit information to approved third-party destinations. From the network’s perspective, those actions occur inside legitimate sessions. A WAF secures the doorway. It does not control what happens inside the room.

Supply chain security ends at deployment. SBOMs and dependency scanning do excellent work cataloging what was built and knowingly included. But client-side execution evolves after deployment. Third-party scripts update independently, tag managers inject new code dynamically, and AI-generated components appear without traceability. These tools identify risky components before shipping. They do not detect or govern risky behavior after deployment. A large post-deployment risk surface remains unmanaged.

AI governance tools manage models, not their inputs. AI governance platforms focus on the model lifecycle: training data, versioning, explainability, bias detection, and output monitoring. They assume inputs are already governed. In practice, many inputs originate in the browser: user interactions, application state, and contextual signals are composed client-side before being sent to AI services. Without control at this upstream layer, AI governance operates on partial information.

Privacy platforms capture consent — they don’t govern execution. After consent is granted, scripts execute freely. Data may be accessed beyond intended scope. Third-party services may collect more than expected. AI components may infer sensitive attributes. Privacy platforms define policy. They don’t enforce it at runtime. This creates a persistent gap between declared intent and actual behavior.

Across every category, the same pattern emerges: policies stop at the edge, and execution continues in the client runtime.

The Missing Layer: A Single Runtime Control Plane

Visibility is necessary. But visibility is not the same thing as control. Knowing a script accessed a payment field after the fact doesn’t prevent the breach; it documents it. What’s been missing is a layer that can sit inside the browser runtime itself and make real-time decisions: which scripts are authorized to run, what data they’re allowed to touch, and what happens the instant a previously well-behaved script starts doing something it wasn’t authorized to do.

That’s the architectural gap. Not “another monitoring tool for the browser,” but a genuine control plane: least-privilege enforcement, behavioral drift detection, and real-time blocking, operating at the exact point where code, data, and AI agents converge.

In the posts that follow, we’ll go deeper into what that looks like across each risk domain: defending client-side code against AI-assisted reverse engineering, closing the supply chain gap that opens the moment a page goes live, governing what AI agents are actually allowed to read, rebuilding data privacy enforcement beyond the consent banner, and moving threat detection from alert after the fact to block in real time.

The starting point for all of it is the same: the browser is no longer the edge of the application. It is the edge of the enterprise. It’s time architecture caught up to that fact.

The security operations center is undergoing its biggest structural shift in two decades. The recent launch of the Agentic SOC Alliance signals a major milestone: enterprise defense is officially standardizing around an autonomous operating model built on three core layers: Context, Harness, and Model.

It is a well-crafted architecture designed for an undeniable reality. Yet, in defining this next-generation framework, the industry has an opportunity to expand the definition.

Within the Alliance’s blueprint, the durable Context layer explicitly feeds autonomous agents with structured telemetry across three core pillars: Network, Endpoint, and Identity. This foundation is essential. However, as enterprise work migrates from local desktop environments to web-first interfaces, the definition of what constitutes complete Endpoint and Identity evidence must naturally evolve to include the browser runtime.

Why SOCs Exist (and Why They Are Going Agentic)

At its core, a SOC exists to protect an organization’s crown jewels such as sensitive customer records, intellectual property, financial transactions, and proprietary business logic. For twenty years, defenders guarded those assets using a human-speed workflow: queue, enrich, triage, investigate, escalate.

That pipeline worked well when attacks unfolded over days or weeks. It breaks down completely in the era of AI-driven, machine-speed adversaries who can discover a vulnerability, weaponize an exploit, and execute lateral movement within hours.

As the Agentic SOC Alliance rightly points out, human-paced triage cannot be optimized fast enough to close this gap. Security operations must be rebuilt around autonomous AI agents that can ingest context, evaluate evidence, and orchestrate responses at machine speed.

However, machine-speed reasoning is only as effective as the sightline behind it. If an agent is blind to where data is actually first created, as well as where it lives and moves, even the fastest model will draw flawed conclusions.

Where High-Value Data Is Exposed Today

To understand why the browser session is central to modern risk, look at where high-value data is actually rendered, entered, and processed. The browser is no longer just a passive viewer for static web pages; it is the active execution environment for both customer-facing applications and internal workforce operations.

Whether an organization is running a public-facing e-commerce store, a banking portal, or internal operations, the crown jewels pass directly through the browser Document Object Model (DOM) before reaching backend servers or disk storage:

• Payment & Cardholder Data (PCI): Credit card numbers, CVVs, and billing addresses typed directly into customer-facing checkout pages and payment gateways.
• Personally Identifiable Information (PII) & Health Records (PHI): Customer identities, SSNs, financial records, and medical histories handled across banking platforms, customer portals, and SaaS environments.
• Intellectual Property & Proprietary Code: Source code, strategic roadmaps, and trade secrets rendered inside internal web applications or pasted into web-based AI tools.
• Competitive & Commercial Data: Pricing strategies, sales pipelines, and financial performance data viewed and edited in web-based business applications.

Because this data is decrypted and rendered client-side, traditional server logs and host agents never see the micro-interactions taking place in the browser window, leaving payment scraping, formjacking, third-party script harvesting, and prompt leaks invisible to traditional security tools.

Client-Side Risks the SOC Must Reason On

Because the browser runtime has become the primary execution surface for both modern enterprise applications and AI workloads, client-side security risks directly impact SOC operations. To build true autonomous defense, an Agentic SOC must ingest real-time browser telemetry across three core operational risk categories:

Web Supply Chain Vulnerabilities & Third-Party Script Misbehavior: Modern web applications rely heavily on external JavaScript libraries, analytics tags, and embedded widgets. When third-party scripts are compromised or altered, whether through digital skimming (Magecart), formjacking, or unauthorized API hooks, they execute with full access to the rendered page context. Without client-side telemetry, compromised scripts can quietly siphon sensitive payment data, PII, and credentials directly out of the DOM before any network packet reaches backend servers.

Client-Side Data Leakage & Outbound AI Exposure: Critical data exfiltration increasingly occurs inside unmanaged browser sessions. This includes inbound data leakage triggered by malicious browser extensions or DOM-tampering scripts, as well as outbound data exposure caused by employees pasting proprietary source code, customer records, or financial models into unsanctioned browser-based AI tools. Without browser signal, these micro-actions appear as normal HTTPS transport to host and network sensors.

Reverse Engineering & Tampering of Client-Side Code: As modern applications move core business logic to frontend JavaScript, adversaries use automated tools and specialized AI models to inspect, de-obfuscate, and probe client-side code in real time. Attackers analyze client-side logic to uncover hidden API endpoints, manipulate application state, bypass authentication controls, and craft targeted exploits. Traditional EDR and NDR tools remain completely blind to client-side reverse engineering and dynamic debugging occurring within the browser runtime.

Expanding the Context Layer: How Browser Signal Fits In

Integrating browser visibility into the Agentic SOC architecture does not require altering the Alliance’s framework or inventing a competing standard. Instead, browser and session telemetry seamlessly enriches and completes the existing Endpoint and Identity Context pillars.

• Extending Endpoint Context (Host OS + Browser Runtime): Traditional EDR sees process execution, system calls, and binary behavior on the underlying operating system. However, the modern user spends their day inside the browser runtime. Extending Endpoint context into the browser session allows autonomous agents to observe DOM-level actions, extension behaviors, third-party script executions, and client-side code scraping that host-level EDR sits beneath.
  
• Extending Identity Context (Authentication + In-Session Behavior): Traditional IAM telemetry validates access at the front door—tracking authentication events, SAML assertions, and MFA challenges. Extending Identity context into the active session gives AI agents post-authentication visibility, verifying how authenticated tokens and active user sessions are actually behaving once inside an application.

The Value of Complete Evidence

The Agentic SOC Alliance emphasizes that providing agents with structured, discoverable context leads to “fewer tokens, faster answers, and lower reasoning complexity.”

When an AI agent investigates an incident with full access to both host-level and session-level telemetry, it avoids the trap of false assumptions. If a third-party script quietly harvests data out of a form or an attacker uses AI tools to probe proprietary frontend code, host-level EDR sees a standard browser process, NDR sees encrypted HTTPS traffic to a trusted endpoint, and IAM shows a valid login.

By feeding the browser session signal into the shared Context layer, the autonomous agent receives complete ground-truth evidence, allowing it to accurately confirm or dismiss threats without spending cycles reconstructing missing telemetry.

Closing the Gap: Bringing the Browser into the Context Layer

To fulfill the promise of machine-speed defense, browser telemetry and execution controls must be integrated directly into the Agentic SOC operating model as a first-class Context provider.

Closing this gap requires three capabilities:

1. Client-Side & Browser Telemetry: Ingesting real-time visibility into DOM events, third-party script execution, browser extension activity, and client-side data flows alongside traditional host and network signals.
2. Real-Time Enforcement: Enforcing least-privilege controls inside the browser runtime, restricting third-party scripts to only the DOM elements and data they strictly require, while blocking malicious script harvesting, AI-driven code probing, unauthorized data pastes, and session theft at the exact moment and location they occur.
3. Discoverable Signal for AI Agents: Structuring browser activity into a semantically rich operational graph. Browser telemetry must be presented as actionable context that autonomous agents can query without burning tokens on raw log parsing.

Building a Unified Architecture for Machine-Speed Defense

Bringing enterprise browser telemetry into the Agentic SOC ecosystem strengthens the overall defense model by making every layer of the architecture more effective.

In a unified joint architecture, telemetry sources work in concert across the shared Context layer:

• NDR surfaces network transport anomalies, protocol patterns, and lateral movement.
• EDR monitors host health, underlying OS binaries, and system processes.
• IAM tracks identity boundaries, authentication requests, and access rights.
• Enterprise Browser Telemetry captures rendered session activity, DOM actions, third-party script execution, and in-browser data movement.

When the Harness layer orchestrates an autonomous agent to investigate an alert, the agent queries a unified operational graph. It can trace an incident seamlessly from an initial third-party script-harvesting event in the browser session to a session token anomaly to an endpoint process change to a network communication attempt, enabling precise, automated containment at machine speed.

Conclusion: Driving Accuracy Through Complete Context

The transition toward an Agentic SOC represents a vital advancement for enterprise cybersecurity. Building operations around autonomous AI agents gives defenders the leverage needed to match the speed of modern AI-driven attacks.

Because an AI agent’s reasoning is bounded by the evidence it can access, ensuring the Context layer captures the full scope of enterprise activity is critical. Incorporating browser and session telemetry into the existing Endpoint and Identity pillars provides autonomous agents with the deep visibility required to protect modern workflows, proprietary code, and client-side data.

Text-based CAPTCHAs

The original and most recognizable form of CAPTCHA presents users with distorted text that must be correctly identified and entered. These systems use various obfuscation techniques:

• Character warping and distortion
• Addition of noise, lines, or background patterns
• Overlapping characters
• Varied fonts and sizes
• Character rotation and perspective shifts

Text-based CAPTCHA systems that were considered effective until recently have become ineffective due to the sophistication of OCR (Optical Character Recognition) algorithms. Modern machine learning models exceed 99% success rates on text-based systems, thus making these CAPTCHA versions outdated for high-security purposes.

Image-based CAPTCHAs

As text-based systems became more vulnerable, image recognition CAPTCHAs emerged as a stronger alternative. These typically present users with a grid of images and ask them to identify specific content. Common variants include:

• Selecting all images containing a particular object (e.g., “Select all images with traffic lights”)
• Identifying a specific category of images (e.g., “Select all animals”)
• Arranging images in a logical sequence
• Identifying the odd image out from a set

The reCAPTCHA v2 system from Google introduced human-image recognition assessment to exploit the performance discrepancies between people and computers. Sophisticated neural networks combined with computer vision systems have caused the recognition gap to significantly decrease. Technology today has developed AI systems that match human performance when recognizing images in multiple use cases.

Audio CAPTCHAs

Developed primarily as an accessibility alternative for visually impaired users, audio CAPTCHAs present spoken characters or words, often with background noise or distortion. Users must listen to the audio and type the spoken content.

The accessibility feature of audio CAPTCHAs makes them susceptible to attacks from speech recognition systems which have proven their effectiveness at defeating the system. Among the tasks these modern speech-to-text tools perform is the perception of distorted audio at a level beyond human ability, especially when background noises interfere.

Interactive and Puzzle-Based CAPTCHAs

These systems combine direct user interaction with problem-solving elements, creating a more engaging verification experience. They require users to perform specific manipulations or solve visual puzzles:

• Sliding a puzzle piece into the correct position
• Rotating images to achieve proper orientation
• Dragging and dropping elements in a logical sequence
• Jigsaw puzzles where users must assemble fragmented images
• Matching games requiring users to pair related items
• Pattern completion tasks

Companies like FunCaptcha (now Arkose Labs) pioneered this approach, creating game-like verification experiences that attempt to balance security and user experience. These systems often analyze not just whether the puzzle was completed correctly, but also how it was completed, adding behavioral analysis as an additional security layer.

Behavioral/reCAPTCHA (v2, v3, Invisible)

The latest evolution in CAPTCHA technology has moved toward passive, behavioral analysis rather than explicit challenges.

• Google’s reCAPTCHA v3 assigns risk scores based on user behavior without requiring explicit verification
• Behavioral systems analyze mouse movements, typing patterns, and navigation behavior
• “Invisible” CAPTCHAs run in the background, only triggering visible challenges when suspicious activity is detected

The latest systems deploy machine learning algorithms to distinguish human behavior from bot activity, providing users with enhanced security without compromising the user experience. Security concerns about privacy arise from the way these systems collect and interpret large amounts of user behavioral data.

Security Risks Associated With CAPTCHAs

While CAPTCHAs are designed to protect websites and users from automated threats, they are far from infallible. Open-source technology and resourceful cybercriminals continue to advance together which creates security risks from CAPTCHAs that both diminish their protective functions and produce new system vulnerabilities. The security weaknesses in online systems result from both CAPTCHA limitations and malicious exploitation techniques that expose vulnerabilities to harm both security, privacy and trust in online systems.

1. CAPTCHA Solving Services and AI Advances

The development of AI alongside machine learning has improved automated tools so they can defeat CAPTCHAs. Security providers who operate under the names of CAPTCHA solvers use either artificial intelligence techniques or low-cost human resources to easily bypass CAPTCHA barriers. Some key risks include:

• AI-Powered Bots: AI models can now process distorted text and recognize images with a high degree of accuracy, rendering traditional CAPTCHAs ineffective.
• Cheap Human CAPTCHA Solving Services: Cybercriminals leverage services that employ human workers to solve CAPTCHAs for minimal costs, defeating their purpose.
• Increased False Positives: More sophisticated CAPTCHAs often become overly complex, mistakenly blocking legitimate users while still being vulnerable to bots.

2. CAPTCHA Exploitation by Cybercriminals

Rather than deterring attackers, CAPTCHAs can sometimes be leveraged for malicious purposes, including:

• Phishing Scams: Cybercriminals create fake CAPTCHA pages on phishing websites to lull users into a false sense of security before stealing login credentials.
• Man-in-the-Middle (MITM) Attacks: Malicious actors intercept CAPTCHA responses, using them to gain unauthorized access to systems.
• Malware Deployment: Some malicious sites present CAPTCHAs to make users believe they are interacting with a legitimate service before infecting their devices with malware.

3. Privacy and Data Collection Concerns

Many CAPTCHA systems, particularly Google’s reCAPTCHA, rely on extensive tracking of user behavior, leading to serious privacy concerns. These include:

• Tracking Browsing Behavior: reCAPTCHA monitors how users interact with web pages, collecting data about their browsing habits.
• Google Account Dependencies: Some CAPTCHAs require users to be logged into Google, linking their activities to their Google account.
• User Profiling: The data collected can contribute to fingerprinting techniques, raising ethical concerns regarding user privacy.

4. User Experience and Accessibility Issues

CAPTCHAs often degrade user experience and accessibility, leading to frustration and potential exclusion of certain users:

• Frustrating Challenges: Many CAPTCHAs are difficult to solve, leading to form abandonment and reduced conversions.
• Accessibility Barriers: Visually impaired and dyslexic users struggle with text- and image-based CAPTCHAs, while audio CAPTCHAs often suffer from poor quality.
• Increased Cognitive Load: Users with cognitive disabilities may find CAPTCHAs overwhelming, making online interactions more difficult.

Emerging Threats and Mitigation Strategies

The security effectiveness of CAPTCHAs has declined due to advanced security challenges that have breached their traditional standards. The advancement of technology together with attacker development exposes design weaknesses in CAPTCHA systems by creating new threats beyond their original capabilities. At the forefront are AI-driven innovations, but other risks lurk in the shadows, demanding creative and robust responses. New mitigation strategies develop to confront these threats directly by enhancing or developing alternative CAPTCHA-based security systems.

AI-Powered CAPTCHA Breaking

Artificial intelligence has turned the process of breaking CAPTCHAs into a sophisticated practice. Deep learning tools and generative AI provide bots with the ability to break text-based CAPTCHAs through OCR, analyze image grids using neural networks similar to human vision, and replicate mouse-click actions for behavioral CAPTCHAs. Attackers obtain access to CAPTCHA-solving tools through commercial plug-and-play and cloud services which make defeating CAPTCHA easier for a wide range of attackers leading to increased operational scale.

Here, we can see below how an AI-powered CAPTCHA solver works, such as a bot quickly solving an image-based CAPTCHA

Here is another example below:

AI solvers achieve up to 90% success rates on text and image CAPTCHAs. Google’s reCAPTCHA v2 and v3 have been bypassed using AI-powered bots. The effectiveness of CAPTCHAs declines rapidly, prompting businesses to seek alternative security measures.

Beyond AI, additional dangers loom. Crowdsourced CAPTCHA-bypassing leverages human workers through CAPTCHA farms, blending automation with low-cost labor to tackle complex challenges. Zero-interaction exploits target backend flaws—such as unvalidated server responses or vulnerable APIs—allowing attackers to bypass CAPTCHAs entirely. Meanwhile, user behavior shifts driven by frustrating CAPTCHAs push legitimate users toward insecure workarounds or phishing traps, indirectly amplifying risks. Together, these threats form a multi-front assault on CAPTCHA reliability.

The Importance of a Layered Security Approach

The battle requires combined security measures, as no single method is sufficient on its own. Security against attackers becomes more challenging when CAPTCHAs are combined with multi-factor authentication (MFA), which requires text codes or biometric authentication. Adding intrusion detection, rate limiting, or IP reputation checks further fortifies defenses. This approach reduces pressure on CAPTCHAs as the sole gatekeeper, distributing security across complementary layers to catch what slips through. It’s a holistic mindset: diversity in protection breeds strength.

Alternative Solutions to CAPTCHAs

Organizations need to find substitute security measures to improve defense capabilities while maintaining user comfort through the ongoing struggles of CAPTCHAs against artificial intelligence and automated bots. Companies operating under these risks should adopt alternative measures to CAPTCHAs which include:

• Biometric Verification: Biometric solutions tap into what’s uniquely human: physical or behavioral traits. Options like facial recognition, voice authentication, or even typing rhythm analysis (keystroke dynamics) verify identity without requiring puzzles.
• Device Fingerprinting: Device fingerprinting shifts the focus from user challenges to machine identity. By analyzing a device’s unique traits—browser version, screen resolution, installed fonts, timezone, or even subtle hardware quirks—this method builds a “fingerprint” to verify legitimacy.
• Honeypots: Honeypots are a stealthy, user-invisible approach to bot detection. These traps embed hidden fields or links in a webpage—elements that humans naturally ignore but bots, programmed to interact with all available inputs, can’t resist touching.
• Multi-Factor Authentication (MFA): Combining passwords with additional authentication steps, such as SMS codes or biometric verification.
• Risk-Based Authentication: Risk-based authentication (RBA) ditches one-size-fits-all challenges for a dynamic, context-aware approach. By assessing factors like IP location, login frequency, or device reputation, RBA calculates a risk score. Low-risk users (e.g., someone logging in from a familiar device) breeze through, while high-risk ones (e.g., a new IP from a known botnet) face additional hurdles—perhaps a secondary code or question.
• Cryptographic Attestation: For a cutting-edge twist, cryptographic attestation uses hardware-based security—like Trusted Platform Modules (TPMs) or secure enclaves—to prove a device’s authenticity. A website might request a cryptographic token from the user’s device, verifying it’s not a virtualized bot.

Conclusion

Advanced security threats have made CAPTCHAs less effective even though they initially served a critical role in online defense systems. Reliability in CAPTCHAs decreases because of the combined impact of CAPTCHA-solving services alongside AI advancements and privacy concerns, together with user experience problems. Businesses should look into different authentication and security techniques that combine high protection with ease-of-use.

Modern technology has created uncertainty about whether CAPTCHAs operate as protective measures or whether they represent a security risk. Online security demands continuous evolution because threats in the cybersecurity domain keep becoming more sophisticated.

As web applications grow more complex, client-side code has become a prime target for attackers. From third-party scripts to browser-based vulnerabilities, threats on the client-side are often overlooked until it’s too late.

In this article, we explore everything you need to know about client-side attacks and monitoring: what they are, why they matter, common attack types, and how to detect and mitigate them effectively.

What Are Client-Side Attacks?

Client-side refers to operations performed in the user’s web browser, rather than on the server hosting the website or application. In the context of web apps, client-side attacks typically target the JavaScript running in the browser, exploiting vulnerabilities to manipulate web pages, steal form data, hijack sessions, or inject malicious scripts, rather than compromising the user’s device directly.

What Are Some Examples of Client-Side Attacks?

Attackers use various methods to exploit the trusted relationship between users and the websites and apps they use. Some examples include:

• Content Spoofing – Modifying content on a web page or app to trick users into thinking it is legitimate.
• Cross-Site Scripting (XSS) – Injecting malicious code into legitimate web pages viewed by users. The two most common ways in which this can happen are tricking a user into clicking a link containing malicious code, which then executes within the user’s web browser. Or embedding malicious code on a website where it is stored, for example, on message board posts, webmail, and web chat software.
• Drive-By-Downloads – Users inadvertently download malicious code by simply visiting a compromised website; the user requires no action.
• Man-In-The-Browser (MitB) – Installing malicious code in the user’s browser which can intercept and manipulate data in real time as it is transmitted.

The above is not an exhaustive list of client-side attacks. Others involve hijacking, namely taking control of systems, software, or network communications, and are variously known as customer hijacking, session hijacking, formjacking, or clickjacking. Sometimes, client-side attacks are referred to by the more literal name of third-party browser script attacks.

What is the Relationship Between Client-Side Attacks and Digital Skimming?

Generally, attackers deploy a client-side attack to conduct digital skimming. Digital skimming attacks involve stealing sensitive data input by users into web forms. Frequently, this is payment data from online checkout pages, although it also includes personally identifiable information (PII) from other web forms.

Digital skimming is also known by various names, including e-skimming, data skimming, and formjacking. Then there are the more specific terms of JavaScript attacks or Magecart attacks, which hint at how digital skimmers exploit vulnerabilities in a website’s code or infrastructure to harvest data.

Why are Businesses Vulnerable to Client-Side Attacks?

If we were to summarize why businesses are vulnerable to client-side attacks in one word, it would be JavaScript. In the early years of the web, pages were built entirely in HTML. So, with each new click, a new page was loaded. And with every small change to a page, the entire page had to be refreshed. However, JavaScript and a group of interrelated web-programming technologies made it possible to send and receive data in the background, without having to reload the page.

This move from static to dynamic web pages improved the ease of creating pages, the functionality, and the user experience. However, the comfort and elegance of using JavaScript are also the source of its weakness.

Around 99% of all websites now use JavaScript as their go-to client-side coding language. The use of third-party add-ons has also grown. As the name suggests, these add-ons are tools built by third-party developers to provide extra features to a web page, and can be seamlessly integrated.

Examples include AB testing, analytics, advertising, retargeting, and online payment. The business intelligence behind a website has now moved from web servers, owned and managed by companies, into the consumer web browser, powered by JavaScript, distributed APIs, and microservices.

As a result, any JavaScript running on a web page can access all data entered into form fields on that page. With no separation between different parts of the application, this increases the attack surface for possible breaches.

What are the Implications to Businesses of Client-Side Attacks?

It’s difficult to overstate the impact of client-side cyberattacks to a business’s brand, reputation and bottom line. It can include bankruptcy and business failure.

For example, DNA testing firm 23and Me filed for bankruptcy in March 2025, following a 2023 cyberattack that exposed the personal data of 7 million customers. The breach resulted in a $30 million settlement, staff layoffs, the resignation of the co-founder and the collapse of a company once valued at $6 billion.

New York University (NYU) suffered a data breach that exposed the personal information of more than 3 million applicants, including names, test scores, family backgrounds and financial aid details. A hacker then took control of the university’s official website in late March 2025 and modified content, purporting to show specific admissions data categorized by race.

Cyberattacks hit UK supermarkets Marks & Spencer and The Co-op during March/April 2025. M&S customers were unable to use contactless payment in-store, shop online, which accounts for around £3.8 million in daily takings for M&S, or use click and collect services. The disruption and uncertainty wiped more than £600 million off the stock value in just over a week.

Meanwhile, the Co-op was forced to shut down part of its IT systems, including its stock management system, following a cyberattack. This led to empty shelves in some of its 2,000 stores. The group confirmed that hackers had also accessed customer data from its membership program, such as names and contact details.

What are the PCI DSS v4 Implications of Client-Side Attacks?

Given the ubiquity and innate security vulnerabilities of JavaScript, including on payment pages, the PCI Security Standards Council (PCI SSC) published an updated version of the PCI Data Security Standard (PCI DSS) in March 2022. Version 4 of the PCI DSS contains two new requirements to protect against and detect digital skimming attacks on payment pages. These requirements have been in effect since April 1, 2025.

• Requirement 6.4.3 – the first new PCI requirement is designed to minimize the attack surface and manage all JavaScript present in the payment page.
• Requirement 11.6.1 – the second new PCI requirement aims to detect tampering or unauthorized changes to the payment page and generate an alert when changes are detected.

What is Client-Side Attack Surface Monitoring?

Client-side attack surface monitoring is a cybersecurity practice that focuses on continuously identifying, analyzing and mitigating potential entry points for attacks on the client-side of an application or website.

It involves monitoring the behavior of applications and websites running on the user’s device, looking for suspicious activity and vulnerabilities that attackers could exploit.

As with most things in web application security, client-side security and cybersecurity in general, this involves a multi-layered approach. There are no silver bullets to detect, verify, monitor and block malicious code.

How do Businesses Protect Against Client-Side Attacks?

Given the dynamic nature of the web and JavaScript, businesses are advised to deploy a combination of the following measures to protect against client-side vulnerabilities.

1. Real-Time Monitoring

One of the best ways to guarantee full visibility and control on the client-side is to implement real-time monitoring. Businesses must be able to detect unauthorized script activity on their websites at any time. That essentially means in real time. What’s more, businesses should receive alerts if their websites or applications are under attack. Plus, be able to act immediately and block or deactivate any malicious scripts.

In technical terms, this means analyzing the behavior of scripts to identify anomalies such as excessive network requests, unusual data manipulation or unexpected interactions with other elements on the website, which could indicate a malicious attack.

2. Get Visibility Into Third-Party Scripts

It’s also recommended that businesses are fully aware of all the third-party scripts that are present on their website.

It’s helpful to maintain a dynamic inventory of all the scripts present on a website, including first-party and third-party code. It’s also one of the requirements mandated by PCI DSS v4, which mandates that e-commerce businesses maintain a full inventory of every script on their payment page.

In technical terms, verifying the integrity of JavaScript libraries means comparing JavaScript code with known and trusted scripts. This helps to determine whether a library or website domain has been tampered with or replaced by a malicious variant, and prevents the execution of compromised code.

3. Other Client-Side Attack Prevention Strategies

There are a number of other strategies businesses can implement to prevent client-side attacks. These include but are not limited to:

• Update and patch all software and apps associated with a website on a regular basis.
• Use monitoring and inspection technology to alert in case of any unauthorized script activity.
• Split front-end applications into smaller components (e.g., facing, authentication and admin) to compartmentalize them and thereby reduce scope in the event of a breach.
• Store sensitive website data in a dedicated meta field and keep API keys hidden from public view.
• Use SSL certificates for all websites and ensure they are kept up to date.
• Be cautious when selecting and implementing third and fourth-party scripts (those that a third-party supplier sources from elsewhere).

How Does Jscrambler Help Prevent Client-Side Attacks?

Jscrambler is the leader in client-side protection and compliance. We were the first to merge advanced polymorphic JavaScript obfuscation with fine-grained third-party tag protection in a unified client-side protection and compliance platform.

Our end-to-end solution does more than protect data — it empowers businesses. With Jscrambler, development teams are free to take full advantage of client-side JavaScript, safe in the knowledge that they have access to sweeping protection against current and emerging cyber threats, data leaks, misconfiguration, and IP theft.

Trusted by big-name brands such as Air France-KLM, Netflix, NBCUniversal, Gap Inc. and Banco Santander, Jscrambler’s top client-side attack prevention features include:

• Website Inventory – Real-time visibility of all scripts running on the website and how they access and transfer data. Provides an accurate picture of the overall exposure to third-party risk.
• Form Fencing – The granularity of Jscrambler’s form-fencing feature allows the client to control which scripts can read and access form data, keeping malicious actors from siphoning sensitive information that users enter into forms.
• Webpage Threat Mitigation – Powerful and granular rules engine that provides complete control of each script running on your website. Allows proactively or reactively blocking scripts that exhibit malicious behavior
• Real-Time Alerts – Immediately flag high-risk behaviors and gain real-time reaction capabilities and notifications about external scripts.
• Polymorphic Code Obfuscation – An extra layer of security and complexity to keep attackers out.
• Code Locks – Prevent code from running outside set parameters for browser, date, or domain.

Ready to Prevent Web Client-Side Attacks?

Protect your business against client-side attacks, script injections, and unauthorized access to sensitive data by harmful third-party tags, pixels, and trackers with Jscrambler. Contact our experts today.