Spotlight Interview: Simon Wijckmans, Founder and CEO of c/side

Your tech career has spanned web security, product management, and enterprise sales. What led you to start c/side and focus specifically on client-side security?

I worked at Cloudflare and learned a lot about web security there—I was particularly intrigued by how little security monitoring happens in the browser of users. Browsers are an incredibly powerful attack surface area and they basically bypass other security efforts, yet there weren’t many solutions out there to address it. After Cloudflare I spent some time at other dev tool companies like Vercel. But I realized the browser security problem was still present, a potent security threat hardly that needed to be better covered. I founded c/side to address this.

You’ve stated that traditional cybersecurity solutions haven’t adequately addressed the problems c/side solves—what specific gaps did you identify that c/side aims to fill?

The big one is that a firewall usually only monitors inbound attacks, not the actions in a browser. Then there are solutions in the industry that do not even check the actual payloads of scripts and rely mostly on threat feed intel. Our solution works entirely differently and can stop these attacks before they execute by simply preventing the scripts from being served in the first place. Now, we can’t stop attackers from trying, but our proxy solution (where we load these scripts and check them before the browser renders them) allows for a lot more control. It effectively stops the attack from impacting our customers’ websites, and keeps them safe for their users.

c/side’s mission is to make web security accessible to all. How does this philosophy differentiate c/side from established cybersecurity vendors?

This shows in three key areas: pricing, transparency, and accessibility. An independent tool like ours doesn’t come as an add-on to a bloated offering by a big firm. It doesn’t require you to get an expensive base package to secure this crucial part of your web supply chain. Our pricing is transparent, with no surprises.

Users, which include hotel businesses, can just sign up and use our product. On many other product page, we see “get a demo” or “contact us”—we fundamentally disapprove of stopping users from taking action. If your product is any good, you would trust people to go hands-on before they sign an agreement. Security should be accessible to keep the web safer for all. At least that’s our opinion.

From your perspective, how significant is the risk posed by third-party code scripts that hotels commonly and increasingly use on their websites for functionalities like booking engines, payment processing, and guest services chatbots?

Most of these client-side attacks happen on sites and pages where money is transferred. Attackers often aim to capture the credit card details of unsuspecting people, and hospitality businesses—where guests are booking hotel rooms in the hundreds or thousands of dollars—are a perfect target.

Any site that takes online payments is required per PCI DSS 4.0 rules (by March 2025) to have systems in place to monitor scripts on their payment pages. Even by using our free tier, you can check this off your list and be compliant (with the added benefit that we’ll stop any of these kinds of attacks and inform you so you can remove the script). The risk increases with the more third-party tools you use, and the older those tools are (as we tend to see legacy solutions having a higher susceptibility to attacks).

What specific vulnerabilities do third-party scripts tend to introduce to hotel websites?

The hospitality and leisure industry as a whole relies on a ton of third-party tools on its websites—we’re talking anything from booking mechanisms, chatbots, analytics, translation plugins, email-capture forms, etc. The more you have, the higher the risk you run and bad actors recognize that the hospitality industry tends to attract a wide range of tools that aren’t always using the latest and greatest protections.

Are hotels especially vulnerable to these types of attacks compared to other industries? If so, what factors contribute to this vulnerability?

Besides the ones mentioned, it’s a fact that most hotel websites are managed by agencies of freelancers (unless they’re part of a bigger hospitality group). When an attack happens—and especially a stealthy one like a client-side attack where information is skimmed—there are just fewer eyeballs on the site’s operation to quickly spot them. When a JavaScript client-side attack is successful, it often remains undetected for days or even weeks. Attackers are leeching on unsuspecting guests who get their privacy breached while booking a well-deserved vacation. Even worse, security threat feeds may not flag a malicious domain for months.

Are smaller, independent hotels more at risk than larger hotel chains, or vice versa? What factors influence the targeting of these attacks?

It’s debatable. Certainly, both need to pay attention. On the one hand, big chains have more reservations and transactions, so they are a more juicy target if attacked successfully. But smaller players usually have way less focus on security—and a couple of those also add up. In fact, the impact on a smaller hotel could be more substantial, as it is more likely that the financial damage of an attack can be devastating to a business.

You need to prepare for the worst and hope for the best. So any hotel site—and especially those that have a lot of customer data, online payments, and third-party tools plugged into their site—are at risk. We try to make our product accessible to smaller businesses with our tiered pricing model, so unlike most other security solutions you are not at a major disadvantage over the larger firms. 

What are the potential consequences of a successful web supply chain attack for a hotel, both in terms of immediate damage (e.g., data breaches, financial losses) and long-term repercussions (e.g., reputational damage, loss of customer trust)?

Calculating the cost is almost impossible, since every situation is different. But yes, fines for breaching GDPR or PCI DSS are very real and can be hefty for hospitality businesses. Lawsuits also often follow after a cyber attack, since capturing the stolen money or the thieves is almost unheard of. Cyber insurance may not cover the incident if PCI DSS compliance was not met.

After an attack, vendors might have reason to renegotiate contracts, insurance costs might go up, etc. But beyond that immediate financial damage, businesses in the hospitality industry are well aware of how rating culture impacts reputation and trust.

It’s also worth noting that after a successful attack, the time spent addressing the issue (to make sure it doesn’t happen again) and upgrading your security also comes with costs.

Can you provide a real-world example of a web supply chain attack that has impacted a hotel or the hospitality industry in general?

In the recent high-profile Polyfill attack, over half a million websites were impacted—it’s almost certain hotel sites were on that list. Previously, the ‘Magecart’ group attacked multiple sites through third-party JavaScript client-side attacks. Among these was, most notably, British Airways, but also AMResorts (the parent company of multiple hotel brands), owned by Hyatt Hotels Corp. The attack compromised the online booking system, with malicious scripts siphoning off payment card information from users booking their stays. This was a classic example of a JavaScript client-side attack.

What are some practical steps that hotel IT teams can take to better protect themselves against web supply chain attacks, even before implementing a solution like c/side?

Be of which web scripts you have running on your site—and know exactly what they do and what they have access to. Remove any unused scripts immediately, because as we saw in the recent Polyfill attack, the domain that used to serve that script was bought and then used in an attack (even though that script should’ve been removed years prior by 99% of sites that were impacted). c/side can also help with identifying which scripts to remove, as well as protecting those that you still decide to keep.

How does c/side’s script proxy, performance, and analysis engine help mitigate these vulnerabilities? Also, how does c/side integrate with existing hotel website infrastructure and security systems?

Integrating is extremely easy. Simply input our script as the first script to load in the website header, confirm that in the dashboard, and we’re up and running. Our proxy is by far the safest way to secure against these, and we’ve solved any latency issues by optimizing scripts and caching where possible (without mitigating security, of course).

While security is our primary use case, in a lot of cases we make sites run faster, which can correlate with higher conversion rates. 

In the dashboard, once you sign up you’ll see all the scripts and how often they’re used. We also provide a ‘normalized’ version that is human-readable where possible, to help you understand what each script does.

What level of technical expertise is required to implement and manage c/side’s solution?

Since it’s just that one line of code and placing it in the header section of a site, any junior developer or marketing staff should be able to set it up. Our documentation is there to help guide anyone towards creating a safer website.

What are the key benefits that hotels can expect to realize by implementing c/side’s solution?

Peace of mind that the client side of their website is covered. When an attack happens, it will be stopped and you will be notified in order to fully take the threat out. This usually involves removing the script (at least temporarily until the third-party company supplying the script takes action).

What emerging threats in the web security landscape are you most concerned about, particularly as they relate to the hospitality industry?

Over the past few years ‘the supply chain’ has been a hot topic of web security concern. This refers to all of a site’s third-party dependencies, those living on registries like NPM, and also, equally, the ones fetched directly from the user’s browser on a third-party domain. Unfortunately, the industry has focused mostly on open source dependencies on registries, as that is a major attack surface and also easily analyzed. The browser, therefore, is unprotected and more easily exploitable as scripts get delivered dynamically. The combination of lacking tooling with a high level of ability for sophisticated attacks is the key to a very powerful attack vector. 

Stealthy attacks delivered through third-party scripts are increasingly worrisome, as user credentials can be stolen and used to steal sensitive information on other platforms (where reused passwords or payment information can be stolen directly).

What is c/side’s vision for the future of web security, and how do you see the company evolving in the coming years?

We start with securing third-party scripts on sites. And while our product is already powerful, we have some more room to improve and become even more solid. Customers are now giving us feedback, which will only improve our offering and user experience. Once that’s completely covered, we aim to expand more into other areas of client-side security. It’s why we named our company, more broadly, c/side—relating to “client-side.”

What advice would you give to hotel executives who are evaluating their cybersecurity posture and considering investments in new security solutions?

Hotel leaders need to at least be aware of the threat and not put this on the back burner. Have a talk with your developers or partners and ask what they advise. Attacks are increasing and the impact (immediate and aftermath) is real, severe, and costly. Using a tool like ours is set up in minutes and you can cross it off your list and sleep soundly knowing that there is one less attack surface to worry about.