Cybersecurity & Technology: A Tour of GatewayAPI's Engine Room
Cybersecurity is an essential part of GatewayAPI’s foundation. We have implemented a number of comprehensive security measures to protect data and prevent misuse of our platform for smishing, AIT and similar malicious activities.
In a previous blog post, Cybersecurity in the Messaging Industry and Our Strategic Response to Emerging Threats we gave an overview of our overall approach to security.
In this blog post, we want to take an in-depth look at the specific technical security measures we have recently implemented.
The goal is to inspire others to investigate potential blind spots in their tech stacks and to raise awareness of possible attack vectors. We will also share the tools and methods that have proven particularly effective for us.
We start the post by looking at one of the most reliable methods to prevent malicious code execution: A Content Security Policy.
Content Security Policy
A Content Security Policy (CSP) acts as an additional browser-based firewall. A website that implements CSP can specifically whitelist which scripts, images, stylesheets, web services, etc. the website can use. By implementing a strict CSP policy, it becomes impossible for unauthorized sources to run code on a website, as the browser goes in and blocks the attempts.
As is often the case with new standards, it has taken many years for CSP to become fully mature for all technologies and frameworks and to be widely supported. It was therefore not considered for the GatewayAPI front-end back in 2015. CSP level 3 was introduced in 2023 with better support for our tech stack and framework. It was therefore obvious for us to implement this security measure.
As mentioned, CSP is the best guarantee against malicious code execution in our opinion. We would therefore also argue that all web applications should implement strict CSP rules to protect themselves.
This is how we have implemented it in GatewayAPI
We have implemented CSP v3 with strict rules, meaning there is no longer unsafe-inline or unsafe-eval for Javascript.
Implementing CSP was a big task as we used different frontend libraries and our own approaches that were basically not designed with CSP in mind. I.e. buttons that were rendered from dynamically rendered templates containing onclick=” handlers or Javascript libraries that manipulated the style attributes of elements directly instead of through the real Javascript APIs.
Another issue was supporting third-party tools that execute dynamic code. Especially Google Tag Manager, which is allowed to inject dynamic code, had to be handled. To do this, we implemented nonce generation in our web server, Nginx, which was then passed on to Google Tag Manager.
Supporting CSP has become much easier with modern libraries built with it in mind, but since our front-end code is about nine years old, it took some effort to upgrade it to strict CSP compliance, including patching older third-party libraries. Although it was a lot of work, it was well worth the effort as it drastically improved security.
The security risks of Google Tag Manager
Google Tag Manager (GTM) is a powerful tool that makes it easy to manage tags and scripts on your website. But along with the many benefits come significant security risks that are often overlooked.
One of the biggest issues is that GTM allows anyone with sufficient access to the account to insert arbitrary JavaScript code into your website. This also includes JavaScript from a wide variety of trusted third parties, which can often be selected from GTM’s library. Although Google has implemented some security measures, there are still potential vulnerabilities, especially when GTM is used as a marketing tool.
Often third parties or marketers access GTM with extended rights to facilitate their work. However, if one of these people or organizations is compromised – for example, through a phishing attack – GTM can potentially act as a backdoor to insert malicious code into your website.
By default, GTM allows users with full access to publish any kind of JavaScript code without delay or approval process. This can lead to serious security issues if access control is not tight or if there is a lack of continuous monitoring of the scripts deployed through the platform.
This is how we have implemented it in GatewayAPI
We have limited who has access to publish changes in production to a very narrow set of trusted employees. We have also set up notifications that are sent to a shared channel in our Slack when someone publishes changes in Tag Manager.
Obfuscated Javascript
Obfuscation and minification do not change the code or its functionality, but make it more difficult for third parties to read. It is also possible to remove obfuscation, so you can never rely on obfuscation as security alone. But making life harder for hackers is definitely a good idea as it may deter some from even attempting to hack. A bit like making sure you have the least attractive house on the street when it comes to burglars.
This is how we have implemented it in GatewayAPI
Our Javascript code is now only delivered in minified and obfuscated form. At build time, all Javascript code is combined into a single Javascript file, which is then obfuscated and minified. For Javascript, UglifyJS 3 was used, and for CSS, Minify was used, which uses CleanCSS 5 among others.
Security scans and penetration tests
Despite extensive code review, security flaws can slip through – even for experienced developers. Similarly, vulnerabilities can arise that no one was aware of at the time. There may also be vulnerabilities in third-party libraries that would not normally be discovered in a code review.
To get a better understanding of what could be improved, we researched different automated scanning and penetration testing tools. We decided to use HostedScan to continuously track our progress in strengthening security.
HostedScan performed daily scans and reported the results, which we then used to evaluate our next steps. With the size of GatewayAPI.com, it took almost 12 hours to complete, which was expected as the tool is very thorough.
As with the penetration test, the platform groups the issues it finds by severity. This also helped us focus on the most critical issues first.
We also performed an external penetration test, which you can read more about here.
Conclusion
It is crucial for all organizations to continuously assess and improve their security measures to protect themselves against emerging threats. The security scan and penetration testing performed on GatewayAPI revealed some weak points that were immediately addressed.
We always strive to be transparent, which is why we would like to share our findings in the hope that this blog post can inspire other companies to give their systems a service check as well. Keeping up to date with best practices and the latest security features is essential to stay one step ahead of the hackers.