This is it. Blog number five in my series on client-side security approaches. If you have managed to stick with me through the entire series, thank you! If this is the first blog you have come across, welcome! For those of you who are new to this series, I covered the following five approaches to client-side security:
- Web Application Firewalls
- Content Security Policy
- Penetration Testing, Vulnerability Assessments, and Security Assessments
- Vulnerability Scanning
- JavaScript Security Permissions
We’re at the finish line. I’m going to talk about the new kid on the block. I’m going to walk you through what JavaScript Security Permissions are and how to deploy them across all of your web assets.
What are JavaScript Security Permissions?
For those of us who are more tech savvy… I know what you’re thinking. There is no such thing as JavaScript security permissions!!! What is this hack even talking about? Hold up! Hang tough! Let’s take this step by step.
First Step: What is JavaScript?
As discussed in my blog “Love it or Hate It, JavaScript is Here to Stay”, JavaScript serves as one of the core technologies used to build web applications and websites accessed by consumers. Over 97% of websites use it for client-side web page behavioral elements. Eighty percent of websites use a third-party JS library or web framework for their client-side scripting. What this means is that websites are assembled with various pieces of third- or fourth-party JS code, which does not have any security permissions built into it. JS is inherently vulnerable to cyber attacks. It allows threat actors to deliver malicious scripts to run on a client computer via the Web.
Second Step: What are permissions?
Simply put, permissions are a way for application developers and security analysts to control access to a specific system and device level functions in an application, page, or other software. Traditional applications, that is, those not written in JavaScript, generally come with a menu of options or functions that may be made visible or hidden from a user based on their permission level. Most permissions must be granted at runtime by the user. The user has the right to revoke permissions at any time.
Types of permissions include the applications ability to:
- Access features on the user’s machine (such as their camera or mic).
- Review and collect personal data (such as private identifiable information, data entered into forms, IP address, location data).
- Grant rights to modify the functionality of the application or software.
Third Step: What are JavaScript Security Permissions?
Traditional software and applications, a.k.a. those not written in JavaScript, come with a menu or functions to set user permissions. JavaScript is the wild wild west… and, yes, Will Smith (as a consumer) is gettin’ jiggy with it. By default, JS environments do not have a security permissions model built in. Third-party JavaScript code can have an unrestricted level of access to sensitive data at the browser level, so the attack surface is broad and wide open. So do JavaScript security permissions exist? Yes, yes they do.
There’s this little client-side security product called PageGuard on the market. It adds security permissions and controls to JavaScript. Application developers and security teams simply have to add a few lines of code to their web sites and web applications, then PageGuard automatically applies security configurations and permissions for continuous protection from malicious client-side activities and third-party scripts. PageGuard’s proprietary technology integrates directly into the runtime environment of every user browser session to enable proactive monitoring and defense.
PageGuard essentially deploys the Zero Trust model on JavaScript applications and runs continuously in the background to automatically detect unauthorized scripts and anomalous code behavior. After detection, PageGuard blocks all unauthorized and unwanted behavior in real-time across an organization’s web assets.
In short, PageGuard monitors and responds to browser-level security events in real-time by auto-instrumenting itself on every website and by applying security configurations to every user browser session. I assure you, it’s not too good to be true.
What JavaScript Security Permission Limitations do I Need to be Aware of?
There are none. If an application development or security team deploys JS security permissions on all of their client-side pages and applications, then third-party JS code can’t be tampered with and data can’t be exfiltrated by threat actors. Coupled with proactive scanning of client-side assets, application security and cybersecurity teams will receive alerts with context, to repair client-side security issues, all while being protected.
Are JavaScript Security Permissions Right for Me?
If you work for a company that conducts business with customers digitally via marketing landing pages, e-commerce technologies, user portals, and other technologies that allow your company to communicate and collaborate directly with their customers, then YES, you do need to add JavaScript security permissions!
In Closing
Threat actors are industrious. They are really good at poking holes in even the best security controls, products, and infrastructure. However, with JavaScript, they don’t have to breach a network. If they want PII or credit card data, all it takes is one bad third-party script. By deploying JavaScript security permissions, you can cut their ability to steal your data and your customers data off, period.
We have now reached the end of my five part blog series. Let’s recap our journey real quick. Here’s a brief overview of the top five client-side security approaches and their limitations.
Web application firewalls can’t protect businesses from:
- Sophisticated skimming malware
- Drive-by skimming
- Supply chain attacks
- Sideloading attacks
- Chainloading attacks
Content security policies come with weaknesses that expose businesses to e-skimming breaches. These include:
- Excessive “allow list” rules or whitelisting
- CSP bypass techniques
- Incorrect CSP implementation
- CSP implementation tradeoffs
Pentesting, vulnerability assessment & security assessments have some strong limitations. They are:
- Time and resource intensive
- Limited in scope to certain applications, technologies, and networks
- Require a very skillful penetration tester with a high level of expertise to be successful
- Rely on the use of specialized tools and technologies to uncover vulnerabilities and threat
Vulnerability scanners are not well suited for client-side security because they:
- Are designed to scan server side assets, not web applications and websites
- Aren’t able to detect and enumerate all JavaScript scripts and vulnerabilities
- Can only see a single domain, not all of the links that are part of it
Finally, JavaScript security permissions, do not have any limitations. They just work.
As discussed in the first blog of the series “Everything You Need to Know About Web Application Firewalls”, implementing effective client-side security is crucial to ensure the safety of your customer data, the integrity of your user experience, and the functionality of your web applications and websites. Having a safe and secure digital presence is the core tenet that drives your businesses ability to grow and succeed. If you are on the long arduous journey to build a client-side security program, I encourage you to check out our Inspector and PageGuard products. They are specifically designed to continuously scan and protect your business from attackers being able to execute JS attacks. If you would like to see our products in action, please request a demo.
