RSI Security recently partnered with JScrambler to host the webinar Securing Hospitality: Mitigating Third-Party Tag Risks in a Dynamic Digital Landscape. Our Director of Information Security and Compliance, Mohan Shamachar, hosted and was joined by JScrambler’s Product Marketing Manager, Katia Kupidonova, and Director of Sales Engineering, Jeffrey Cleveland.
Cybersecurity and Compliance in Hospitality
Opening up the webinar, Shamachar introduced the other two presenters and covered some house rules to set expectations for attendees. Most importantly, he emphasized that the webinar would be interactive and that participants were encouraged to participate by posting questions.
He also provided an agenda of the main subject areas the presenters would cover:
- An overview of hospitality cybersecurity
- A breakdown of third-party JavaScript risks
- Some risk mitigation strategies for these threats
- A live demonstration of RSI Security’s solution
Shamachar also noted that the event would feature an interactive Q&A and a summative wrap-up with practical next steps to help attendees optimize their cyber defenses.
The State of Cybersecurity in the Hospitality Industry
Shamachar began by summarizing some of the most common and pressing challenges to cybersecurity in the hospitality industry. These challenges include but are not limited to:
- High turnover rates and large-scale data processing – Hotels, restaurants, and other organizations deal with huge volumes of sensitive customer information, like payment details and personally identifiable information (PII), which are prime targets for attackers.
- Frequent ransomware attacks and data breaches – These same organizations are often targeted by ransomware and other attack vectors to shut down servers and can potentially grant unauthorized access to sensitive databases, user accounts, and more.
- Multiple digital entry points to sensitive systems – Attackers can also leverage many different interfaces to target these organizations. Common examples include reservation platforms, point-of-sale (POS) systems, mobile apps, and even third-party integrations.
- Complex regulatory compliance pressures – Additionally, organizations in this space are often subject to multiple regulatory frameworks simultaneously. For instance, a hotel might need to comply with the Payment Card Industry (PCI) Data Security Standard (DSS), the General Data Protection Regulation (GDPR), and the California Consumer Privacy Act (CCPA) all at once. Failure to abide by these rules can be extremely costly.
Shamachar also outlined some challenges specific to payment card security, drawing on his experience as a PCI Qualified Security Assessor (QSA). Beyond multiple entry points, digital infrastructure in hospitality also features multiple channels and attack surfaces. In addition, there are challenges inherent to the legacy systems many organizations use, along with the extended networks of third-party software integrations that hospitality often depends on.
Shamachar then provided an overview of the third-party tags and payment security landscape:
- eCommerce payment scenarios – Organizations may provide access to payments by:
- Redirecting to a third-party site or app with an embedded iFrame, hosted fields, JavaScript Forms, or Direct Posts via an application programming interface (API).
- Developing and deploying an iFrame integration entirely in-house.
- Payment page tags – There are other tags that may run on a payment page, like:
- JavaScript code embedded to execute scripts from internal or external domains
- Scripts for analytics, advertisements, engagement, booking, or loyalty programs
- Scripts to collect sensitive information such as payment and authentication data
Shamachar noted that these scenarios and tags are vulnerable to attack vectors such as hijacking, unsecured data transmission, and supply chain risks like cross-site scripting.
This led to a discussion of PCI DSS Requirements related to these payment page risks:
- Requirement 6.4.1 – Public-facing web applications need to have any new threats and vulnerabilities addressed on a regular, ongoing basis to protect against known attacks.
- Requirement 6.4.2 – Public-facing web applications also need to have automated technical solutions deployed to continuously detect and mitigate web-based attacks.
- Requirement 6.4.3 – Payment page scripts launched in consumers’ browsers need to be monitored carefully to detect and prevent attacks and mitigate threats that manifest.
- Requirement 11.6.1 – Unauthorized changes to payment pages need to be detected and responded to, and change and tamper detection mechanisms must be deployed.
Shamachar then gave way to Cleveland and Kupidonova to elaborate on JavaScript risks.
Understanding Third-Party JavaScript and its Risks
Cleveland began by providing some additional context for what third-party JavaScript is and why organizations use it on their websites, especially payment pages. Namely, this code can provide critical functionality to a page, up to and including processing payments. It also enables data collection and sharing across internal and external platforms, feeding AI and other toolsets.
However, collecting proprietary information and feeding large external models and databases is a risk factor. In particular, Cleveland explained what third parties can do with sensitive data:
- They can harvest user inputs without the application owner or the user knowing
- They can add extra (malicious) code undetected, or even hijack sensitive events
- They can fully modify the behavior of a webpage, eliciting unwanted actions
- They can tamper with other code in connected systems to the same effect
- They can exfiltrate compromised information to external domains
All of these risks, especially the last one, pose threats to both general security and regulatory compliance. While these actions can happen from any script, including internal or in-house developed code, third-party scripts are particularly dangerous because they’re harder to track.
Cleveland then pivoted to note how these risks impact hospitality in particular.
Third-party tags in hospitality can collect information they shouldn’t have access to, like booking codes, login data, and other forms of PII. One major impact of the new PCI Requirements noted above is that they put the onus on organizations to take stock of and justify the scripts they use.
Rather than simply eliminating all scripts, hospitality organizations should instead strategize ways to utilize these scripts securely, especially for those that offer critical functionalities.
Cleveland provided an overview of two common third-party attacks tied to these scripts:
- iFrame hijacking, which defrauds users with a fake or otherwise malicious field
- Double-entry skimming, which intercepts data before or on a legitimate page
Cleveland then asked Kupidonova to touch on the impacts these kinds of risks can have.
Kupidonova began by noting that the average cost of a data breach in 2024 was $3.82M, and 31% of hospitality organizations reported experiencing a breach at least once in their lifetime. This is why the most significant changes to the PCI DSS with version 4.0 relate to these risks, as Cleveland noted that 6.4.3 and 11.6.1 both relate specifically to the risks of third-party scripts.
Kupidonova explained that the impact these risks can have include but are not limited to:
- User data leakage as a result of sensitive data breaches
- Loss of customer trust as users feel they aren’t protected
- Brand reputation damage in the form of bad press and reviews
- Potential class action lawsuits, especially in the US but also globally
- Deterioration of partner relationships as a corollary to the issues above
Kupidonova then gave the floor to Shamachar to talk about ways to mitigate these risks.
JavaScript Risk Mitigation Strategies for the Hospitality Industry
Shamachar began this segment by outlining the importance of continuous operations and compliance. This includes 24/7 protection of customers’ sensitive data and regulatory upkeep, maintaining compliance, reputation, and customer trust at all times rather than at finite intervals.
One benefit of always-on security controls is that they stave off potential noncompliance fees and penalties. With respect to PCI in particular, these can include both up-front fines and more indirect punishments, like being unable to process payments from specific credit providers.
However, this approach requires timely operations and compliance documentation.
Shamachar also provided some guidance for what hospitality organizations should be doing to maintain compliance and secure sensitive data. He noted that the PCI DSS requires conducting due diligence to ensure that third parties themselves are compliant. Practices to utilize include:
- Minimizing the amount and kind of JavaScripts used and the kinds of data they collect
- Reviewing what’s being collected, stored, and processed, and monitoring scripts
- Isolating iFrames onto separate pages to minimize duplication and related risks
- Ensuring transmission is secure—a fundamental practice tool that’s often overlooked
- Implementing content security policies to control the sources of allowed scripts
- Using subsidy resource integrity (SRI) to verify the integrity of third-party scripts
- Performing regular code reviews and pen-testing across third-party scripts
Cleveland added some more best practices to consider, from JScrambler’s perspective:
- Understanding exactly what kinds of scripts are being used—and why
- Making sure each third-party vendor has an owner within the organization
- Reducing the overall number of third-party vendors to the minimum possible
- Implementing policies and practices to govern the addition of new vendor scripts
Kupidonova then provided some statistics related to third-party script risks to illustrate exactly why implementing practices like these is so critical. On average, a website contains at least 60 third-party tags that access sensitive data, and over half collect data they shouldn’t for security and compliance reasons. However, only 13% of companies report being extremely confident they know what kinds of information these tags are collecting. And 33% reported not regularly auditing third-party tags, while 10% didn’t even know if they were.
Luckily, JScrambler’s tool is able to block 42% of form data events targeting sensitive data via third-party scripts. Kupidonova segued into a break before the live demo to show exactly how.
Live Demonstration of JScrambler and RSI Security’s Solution
Next, Cleveland led a brief live demonstration of JScrambler’s real-time monitoring and script control tools and how they can be used to mitigate the threats of third-party tags. To note, JScrambler’s solution prioritizes website monitoring through either an agentless model or a WPI agent. In the agentless model, synthetic user sessions enable periodic monitoring of different pages in the browser for issues like skimming, which can lead to leakage and exfiltration of data. In the agent-based deployment, the system includes a small portion of JavaScript in any page within the monitoring scope and monitors users’ access sessions throughout their duration. Both services make the data available in the aggregate for in-depth analysis. The system provides useful insights to the organization through a dynamic dashboard that optimizes visibility. Both models are easy to implement, and only the agented version requires enabling scripts.
Cleveland then demonstrated the dashboard live, sharing his screen to show attendees exactly what it looks like to use the tool. He navigated through functions that are useful for managing the inventory required as of PCI DSS 4.0, along with several sub-categories and functionalities of vendor-specific pages. He walked through exactly how JScrambler works on the admin side.
Wrapping up, Cleveland moved into an open-ended Q&A and final thoughts segment.
Optimize Your PCI Compliance Today
Closing out the webinar, Kupidonova added some final thoughts about the timeline merchants need to adhere to for PCI 4.0 compliance. Namely, March 31st is when organizations have until, and Kupidonova recommended allowing 30-day intervals for several distinct processes, such as vendor research and qualification, proof of concept, procurement, deployment, and assessment.
Shamachar also added that, given the recent developments with PCI DSS 4.0, one major thing QSAs are looking for is whether or not organizations are doing whatever they can to prevent e-skimming. Shamachar and the entire team and RSI Security help countless organizations achieve PCI compliance. We know the right way is the only way to keep your data secure, positioning your hospitality business for rapid, sustainable growth—with RSI Security’s help.
To learn more about how RSI Security powers efficient PCI compliance and cyberdefenses, in the hospitality industry and across all niches and locations, don’t hesitate to get in touch today!
Contact Us Now!