Need: AI Security

Jscrambler WPI 101 – Getting Started

Web applications are facing growing threats from client-side attacks that seek to steal sensitive data and disrupt user experiences. Jscrambler’s Webpage Integrity (WPI) defends against these increasingly targeted risks by safeguarding web assets and payment pages against supply chain attacks, data exfiltration, DOM tampering, and more, while maintaining a seamless user experience and supporting compliance with data privacy-related regulations.

Understanding the Need for Webpage Integrity

With more websites relying on third-party scripts, the client-side attack surface has expanded significantly. Attackers exploit vulnerabilities in these scripts and forms to skim payment data, inject malicious code, or manipulate webpage behavior. Such attacks not only lead to financial losses but also cause critical damage to brand trust and compliance risks. Ensuring the integrity of every script running on the website is crucial for preventing data breaches and complying with regulations and standards, such as PCI DSS v4.

Key Features of Jscrambler Webpage Integrity

Jscrambler’s Webpage Integrity solution provides comprehensive capabilities designed to secure client-side environments:
  • Webpage Inventory: Automatically discover and monitor all third-party scripts (and all other scripts) present on the website, analyzing their origin, behavior, and prevalence to identify risk factors.

Inventory dashboard

  • Sensitive Data Overview: Get detailed reporting on events involving access to sensitive data on webpages (forms, cookies, browser storage, text elements), with filters to isolate alerts by vendor, page, or event type.
  • Form Fencing: Actively block unauthorized scripts from accessing form fields to prevent data skimming and leakage.
  • PCI DSS Compliance Module: Gain tools and reports to help meet PCI DSS version 4 requirements, particularly regarding script integrity on payment pages (6.4.3 and 11.6.1).

PCI DSS Vendor Services dashboard

  • Custom Policies: Define precise security rules without disrupting your user experience. Jscrambler’s customizable policies let you block, alert, or ignore specific script behaviors, such as unauthorized data access, directly on the client side. Instead of stopping scripts from running, WPI silently intercepts and neutralizes risky actions, preserving both page functionality and the integrity of sensitive data.
The Webpage Integrity product uses a hybrid architecture that combines Agent-Based Protection and Agentless Monitoring.  This flexibility lets organizations deploy rapid, lightweight monitoring on less critical pages while applying active, real-time blocking to high-risk areas such as login, payment, and other sensitive data entry forms. Data from both deployment types is integrated into a single unified dashboard, providing a seamless view of client-side risks and compliance status.

App Management dashboard

Step-by-Step Implementation Process

Integrating Jscrambler WPI follows a structured approach to ensure effective deployment and tuning:
  1. Kickoff & Team Alignment
To help things run as smoothly as possible, the Jscrambler team asks that you form a small cross-functional group on your side. Start by assigning the champion (e.g., someone with the title AppSec Lead, Architect, Security Manager, or Risk Manager) from your team for the duration of the integration process. That person will have regular meetings with the team and be the main point of contact. It is also essential to allocate some developer resources (DevOps) for the agent injection on the pages to be monitored in the beginning stage of the deployment. For PCI DSS compliance, it is recommended to loop in your Compliance/Fraud manager for alert triage.
  1. Planning and Scoping
After defining the WPI plan for the client, collaboration is key to identifying the websites and respective pages where the agent should be injected. During this phase, the sensitive forms to be monitored are also mapped, the customer’s first-party vendors are configured, and access permissions are set up for the group of users who will operate the dashboard.

Sensitive Data configurations

  1. Deployment
The successful deployment starts with injecting the Jscrambler agent into the web pages to be monitored, or with the Agentless monitoring component for those aiming to bring payment pages into compliance. Embedded Agent Injection The Jscrambler team shares the snippet instructions for injecting the Jscrambler agent. Usually, the DevOps from the customer side completes this action. The agent injection can be carried out in one of two ways: via code injection or via Tag Manager, in which case no development resources are needed. In an Agent-Based approach, the agent should be injected into previously configured websites and pages. It is recommended that the Jscrambler agent be one of the first scripts loaded on each page to ensure maximum visibility and control. This early injection provides stronger security coverage and ensures that monitoring and blocking can occur before any malicious scripts have a chance to execute. How the Jscrambler Agent Works The agent operates invisibly within end-users’ browsers to monitor script behavior, network requests, and DOM interactions. Importantly, all data transmitted to Jscrambler’s backend is anonymized to protect user privacy, with no personally identifiable information collected. This approach ensures near real-time visibility into any unauthorized or suspicious activity without compromising compliance. Best Practices for a Successful Implementation
  • Inject the agent as early as possible in the page load process to block threats before they can cause harm.
  • Appoint a dedicated project champion, such as a Security or Risk Manager, to coordinate communication and facilitate decision-making with Jscrambler’s team.
  • Use the initial configuration phase as an opportunity to continuously identify benign versus malicious actions in the environment, refining rules and alerts accordingly.
Agentless Monitoring allows WPI to run without any code changes or script deployments on the customer’s side. Instead of embedding an agent into live pages, Jscrambler uses a synthetic user that automatically visits the target pages and executes our data collection routines. This approach simulates real user behavior to detect and classify third-party scripts and potential skimming threats. The agentless option allows customers to move forward even when they can’t easily insert the agent into a web property, such as when they don’t have direct control over the application. To enable agentless monitoring on the web property, provide the Jscrambler team with the URLs of the properties and their corresponding payment pages you wish to monitor. Once the URLs are shared, the Jscrambler team will set up your account and provide the necessary login credentials for you and any additional users. Our team will also configure the websites and payment pages to be monitored by the Agentless Monitoring component.
  1. Configuration & Training
During the training period, insights gathered from the dashboard help confirm that the configured websites, pages, and other settings are correct or identify where small adjustments are needed. For use cases such as Form Fencing, control rules over sensitive forms should be validated to ensure they are properly defined and effective. Jscrambler’s team will be available throughout this process to assist with configuration review and verification. To ensure smooth configuration, weekly meetings can be held, and the topics discussed can include, but are not limited to:
  • Volume: Exact pages where the Jscrambler agent should work
  • Rules to alert about specific actions
  • New configuration requests
  • Custom events tracking
  1. Production
In the final stage, live threat monitoring and alerting begin, with ongoing adjustments to maximize security without impacting the user experience.
  1. Ongoing Operations, Support & Response
As a final step, an ongoing operating rhythm should be established to deliver long-term value from the platform. With the WPI dashboard, it is easy to do reviews, stay on top of the threats, automate compliance reporting, and stay audit-ready. Quarterly performance reviews with the Jscrambler Customer Success Manager can help optimize policies: analyzing blocked activity, updating allow-lists for new vendors, and refining rules as threats evolve. For incidents, rely on predefined rules to act quickly on alerts, including restricting access for suspicious scripts and escalating to Jscrambler support when needed.

Deployment Approaches: Agent-Based vs Agentless

  • Agent-Based Deployment: Embeds a hardened JavaScript agent directly within the website, enabling real-time detection and active blocking of malicious scripts. This method is preferred for high-risk pages needing comprehensive protection.
  • Agentless Monitoring: Not only applicable to this use case, but it also offers a faster path to PCI DSS compliance by passively scanning specified payment pages and tracking third-party services without impacting performance. It is ideal for initial rollouts or pages where direct agent insertion is not feasible.

Compliance and Security Confidence

Jscrambler’s infrastructure is PCI DSS-compliant, ISO 27001-certified, and GDPR-aligned. Regular internal and external penetration testing underpins the product’s security posture, providing customers with assessment-ready reports and increased assurance when protecting critical web applications.

Getting Started Tips

  • Get a full overview of all third-party vendors present on your website, and find out which teams, people, or processes can add JavaScript to the site. Is there a change management or approval process for this?
  • If you need to quickly gain visibility into web pages and third-party risks, start with Agentless Monitoring.
  • Share as many insights as possible during the configuration phase so that Jscrambler team can build tailored protections.
  • Leverage Jscrambler’s intuitive dashboards and real-time alerts to quickly respond to evolving threats.

Conclusion

Jscrambler’s WPI delivers essential, real-time protection against client-side threats that traditional security solutions often miss. Deploying WPI is a decisive step toward securing the client-side and future-proofing web applications against evolving attacks.  

Jscrambler WPI 101 — Skimming Detection

Welcome back to the WPI blog series! Jscrambler WPI 101 is a series of articles about Jscrambler’s product Webpage Integrity (WPI), its main use cases, innovative features, and tips on maximizing the product’s benefits. 
 

This article focuses on the WPI use case for Skimming Detection and explains how Webpage Integrity enables you to protect your business against web skimming and data leakage.
 

The Dangers of Web Skimming


As web skimming attacks become more sophisticated, businesses face increasing pressure to secure their client-side environments, especially on sensitive pages like payment pages and login portals. Skimmers often operate silently, injecting malicious scripts into third-party code or exploiting weak points in the browser to siphon off personal and financial data without ever being detected.


To combat this, Jscrambler’s WPI Skimming Detection provides a proactive line of defense. Leveraging advanced static code analysis, it inspects every script running on your website, evaluating not just the code itself but how and where it executes. The system is designed to identify behaviors commonly associated with skimming, such as obfuscation, data encryption, unauthorized form injections, and access to sensitive information.


When a potential skimmer is detected, the Jscrambler platform offers detailed visibility into the threat, including which third-party vendors are involved and where the skimmer was found. This visibility empowers security teams to act quickly and precisely, removing the threat before any damage is done.


Preventing Digital Skimming with Jscrambler


The Jscrambler Skimming Detection engine aims to classify every individual third-party script present on a website and determine whether a potential skimmer is behind it. 


The skimming detection capabilities within the Jscrambler dashboard are slightly different depending on whether you’re using the full Webpage Integrity (WPI) product or a PCI DSS Module of the WPI. However, they pursue the same goal—helping you eliminate skimming risks to zero.


Inventory

A good way to get an instant overview of skimming threats is to check the Inventory in the WPI dashboard. The Inventory feature provides comprehensive visibility into all vendors and their scripts on the website, offering a better understanding of the various scripts in use. It allows users to identify the scripts’ purpose, location, and impact on sessions and assess the associated level of risk based on verified actions and the potential types of threats they pose. 


example-of-inventory-view-with-no-skimming-issuesAn example of an Inventory view with no skimming issues identified.


This goes beyond simply raising awareness of threats. The Inventory dashboard presents a qualitative measure that helps prioritize security actions and implement mitigation measures to address the impact of vendors present and active on the website.


example-of-an-inventory-view-with-potential-skimmer-identifiedAn example of an Inventory view with a potential skimmer identified.


In addition, the Inventory feature provides visibility into threats related to sensitive data present or entered on the website. It enables verification of which scripts have access to specific data and ensures compliance with the appropriate data access permissions.


Skimming Detection 

Now that you’ve spotted a skimmer in your Inventory view, what is behind it? You can go deeper to discover what happened and get more insight into the skimming risks. This is possible thanks to the Skimming Detection feature that is responsible for identifying and classifying scripts based on their potential security threats, including those associated with Magecart and skimming attacks. Skimming attacks are notorious for extracting sensitive information from websites, posing significant risks to both website owners and their users.


At its core, Skimming Detection is all about analyzing the scripts running on your website and flagging those that could be dangerous. Every script is scanned and categorized based on its behavior and the aspects detected in its code. If it looks clean, it’s marked as safe. But if it shows signs of malicious intent—especially those linked to Magecart-style skimming—it’s flagged as a threat.


This classification helps you stay ahead of attacks by giving you visibility into which scripts (and which vendors) could be putting your customers at risk.


Giving You Control: Manual Reclassification

Sometimes, a script might get flagged even when you know it’s safe. That’s why we have built-in flexibility. If your technical team reviews a script and determines it’s not a threat, you can manually mark it as safe right from your dashboard. That change is reflected within minutes, ensuring your data stays current and actionable.


Vendors and Risk Scores

The Skimming Detection system doesn’t stop at individual scripts—it also looks at vendors. If a vendor has even one script flagged as Skimmer, the vendor itself gets tagged accordingly, and its risk score spikes to reflect that elevated threat level. Clean up the scripts, and the vendor’s risk profile improves. It’s that simple.


This system makes it easier to prioritize threats, monitor your third-party ecosystem, and protect your site from one of the web’s most dangerous types of attacks.


Skimming Detection for PCI DSS Compliance 


The Skimming Detection section of the dashboard alerts merchants when skimming activity is detected in their vendor services. If no skimming is found, you’ll see a reassuring message. If any skimming is detected, you’ll be able to access a link that shows you which specific vendors are compromised.


By analyzing the behavior of web scripts and the context in which they execute, the system detects various indicators commonly associated with skimming activity, such as:



  • Obfuscation

  • Stealth techniques

  • Data encryption

  • Injection of forms, iframes, and other elements

  • Access to sensitive data

  • Suspicious networking behavior


By evaluating these and other factors within the script and page context, the result provides a comprehensive assessment of whether potential skimming activity is present on the website.


If our system detects a potential skimmer—a malicious script designed to steal sensitive data, especially payment information—you’ll see it in the dashboard right away. You’ll see which vendors are involved and where exactly the threat was found, whether on a specific website or payment page. This visibility empowers your team to act quickly and precisely, minimizing risk and exposure.


PCI-DSS-module-view

PCI DSS Module view with a “Potential skimmer found” notice.


No skimmers? No problem. When our system gives the all-clear, you’ll see a reassuring “No skimmer found” message. It’s peace of mind that your site is clean and your customers’ data is safe, for now.


PCI-DSS-module-ni-skimmer-foundPCI DSS Module with a “No skimmer found” notice.


Next Steps After Skimming Detection


Jscrambler Webpage Integrity allows you to react to skimming alerts, review the malicious script or scripts in question, limit their access to data, and block them from performing malicious actions or data transfers. 


In summary, the WPI product can block all unauthorized behaviors from third-party vendor scripts without preventing the script from loading on the page or performing authorized behaviors. This prevents actions such as skimming of payment, login, or other PII (Personally Identifiable Information) data, even if a vendor script contains both malicious code and useful code that is critical to the end-user experience.


As long as the script remains on the page, even if WPI is preventing all behaviors, it will still be included in the vendor inventory. The website administrator should remove a certain third-party vendor script to prevent its continued presence.


To learn more about the blocking capabilities of the Jscrambler WPI, check out the Form Fencing feature that specifically restricts third-party scripts from accessing form data. And stay tuned for the next WPI 101 series article that will cover PCI DSS compliance and how it helps meet the requirements 6.4.3 and 11.6.1, and goes beyond them with the blocking capability.


Jscrambler WPI 101 – Form Fencing

Welcome to our new blog series! Jscrambler WPI 101 is a series of articles about Jscrambler’s product Webpage Integrity (WPI), its main use cases, innovative features, and tips on how to maximize the benefits of using the product.
 

The focus of this article is the WPI use case for Form Fencing. Forms are integral to many online businesses that sell goods and services online. Forms gather important customer data and allow you to easily collect payment. Before we cover how WPI’s Form Fencing works, let’s see what kind of forms Webpage Integrity protects and the ways in which they are deployed on websites. In the section below, we’ll primarily review the payment forms as they collect the most sensitive data that criminals target – cardholder data. 

Form Fencing: The Dangers of Form Data Leakage 


Safeguarding user data is critical. Websites rely on third-party analytics libraries to track user behavior, but these integrations can sometimes become a security liability. Let’s imagine that there is a website that uses a third-party analytics library to store user session data. While this functionality is essential for business insights, it also opens the door for potential exploitation.

Imagine a scenario where the third-party library is compromised by malware. Let’s suppose the attackers manipulate a function to access all form inputs and exfiltrate sensitive information. Initially, the function only stores basic user details like email, user ID, first name, and last name.

However, with the malware in place, additional sensitive data—such as addresses and credit card details—could be stealthily collected and sent to an unauthorized external server, all without detection. This kind of data breach can be catastrophic, leading to identity theft, financial loss, and reputational damage.

Preventing Unauthorized Data Collection with Fencing Rules


To counteract such threats, businesses can leverage WPI’s Form Fencing, a proactive security measure that ensures that only authorized first-party scripts and third-party vendors collect and transmit data. With Form Fencing, organizations can create specific rules to monitor and prevent third-party scripts from accessing form fields.

Preventing-Unauthorized-Data-Collection-with-Fencing-Rules


Setting up a Fencing rule is straightforward:

  • Navigate to the Rules page and create a new rule.

  • Define a clear name and description for easy identification.

  • Specify which website pages should be monitored.

  • Identify the values to configure the rule with the form ID/name or the input ID/name (for example, bookingCode for input booking code and lastName for the input last name).

  • Configure the targets.

    Setting-up-Fencing-rule-is-straightforward

  • Configure the action to prevent form data from being accessed by unauthorized scripts.

  • Deploy the rule and activate the WPI protection agent.

Once in place, this rule ensures that any attempt to extract unauthorized information is immediately blocked and flagged in the dashboard.
 

Payment Form Deployment Types WPI Addresses


There are different ways in which you can deploy a form to be displayed on a website and collect payment data. The most vulnerable forms are usually forms that collect card payment data; they are the most common target of digital skimming attacks. Below are the most common types of payment forms.

Direct API Integration Forms

Deployment: The merchant collects payment details and sends them securely via an API to the payment processor. In this case, the WPI agent should be injected by the merchant who is responsible for rendering the payment form.

Direct-API-Integration-Forms


JavaScript-Based Payment Forms

Deployment: A secure JavaScript library (e.g., Stripe.js) collects payment data directly and sends it to the processor. In this case, the WPI agent should be injected by the merchant who is responsible for rendering the payment form.

 JavaScript-Based-Payment-Forms



Stripe.js-Braintree-Hosted-Fields


Example: Stripe.js, Braintree Hosted Fields


Hosted Payment Forms

Deployment: A third-party payment processor hosts the form, so WPI should be deployed and provided by the Payment Service Provider (PSP).

Hosted-Payment-Forms



Form Fencing for PCI DSS v4 compliance 


PCI DSS requirements 6.4.3 and 11.6.1 will become effective on March 31st, 2025. Both requirements were developed to ensure that online merchants’ payment pages are sufficiently protected to detect and prevent skimming attacks. 

If you are a Merchant who hosts a payment form yourself, then you can use a Form Fencing feature as a Compensating Control or follow a Customized Approach to become PCI DSS v4 compliant. Therefore, you don’t need to worry about authorizing scripts.

Form-Fencing-PCI-DSS-v4-compliance 

Additionally, Form Fencing works as an extra layer of defense that can shield your forms from skimmers even before you authorize scripts.

As cyber threats continue to evolve, proactive security solutions like Form Fencing are essential in protecting sensitive information. By implementing Form Fencing, businesses can safeguard user data, maintain compliance with data protection regulations, and enhance trust with their customers. Don’t wait for a breach to occur—instead, take control of your data security today.