Third-party scripts are often JavaScript code used to add additional functionality or features to a website or application, such as tracking analytics, displaying ads, or providing social media integration. It is also used to leverage code that has been developed and tested by others rather than having to write it from scratch.
To include third-party JavaScript on a website or application, the script tag is used to specify the script’s source. The browser will then load and execute the script when the webpage is loaded.
What are examples of third-party scripts?
- Social sharing buttons such as Facebook, Twitter, and G+
- Video player embeds such as YouTube and Vimeo
- Analytics and metrics scripts
- Advertising iframes
- Helper libraries such as date formatting, functional libraries, and animation
- Experimental A/B testing scripts
Signup forms and payment processors
What are the risks and drawbacks of using third-party scripts?
It is important to carefully consider the potential risks and drawbacks of using third-party scripts when integrating them into a website or application.
There are several potential negative impacts of using third-party scripts on a website or application:
- Security vulnerabilities: Third-party scripts can potentially introduce security vulnerabilities if the source is not reputable or the script itself is not properly secured. This can put the website or application at risk of being exploited by malicious actors.
- Performance issues: Third-party scripts can often have a negative impact on the performance of a website or application. This can happen if the script takes a long time to load or execute or if it consumes a large number of resources. This can lead to a slower and less responsive user experience.
- User privacy: Some third-party scripts may collect or transmit user data, potentially impacting user privacy. This can be a concern for users who are concerned about their data being shared or sold to third parties. This also opens organizations to potential governance, risk, and compliance (GRC) violations, including the European General Data Protection Rule (GDPR), California Consumer Privacy Act (CCPA), and the Payment Card Industry Data Security Standard.
- Dependency issues: Using third-party scripts can also create dependencies on those scripts, which can be problematic if the source is no longer available or the script is updated in a way that breaks the functionality of the website or application.
Is your current security enough?
The best place to start is to gain a deeper understanding of your company’s digital supply chain. Your security team can quickly assess your company’s exposure to its consumer-facing site by discovering the answers to these questions:
- How many vendors are plugged into your company’s consumer-facing site?
- What purpose does each serve?
- Are the plugins required on highly sensitive pages?
- Does their code give them read/write access to forms?
Traditional server-side security doesn’t address these JavaScript risks because client-side scripts operate completely outside of the security capabilities an organization deploys to secure the server side of their web applications.
Other security measures that may already be in place fall short as well. Application security validation testing or dynamic application security testing are not designed to test every use case or operate dynamically, nor can they test the code residing on a third-party or fourth-party remote server. They are also not capable of providing real-time scanning of all web traffic across the entire user population.
Likewise, using content security policy (CSP) and/or subresource integrity (SRI) features are not enough to protect client-side web applications from today’s threats. While CSP and SRI can be powerful tools for website protection and data management, they have significant limitations that impact the ability of website owners to use these measures effectively against client-side threats.
Because it’s difficult or impossible with existing security tools to detect these attacks, the majority aren’t discovered for weeks or months, increasing the scope of damage and mitigation costs significantly.
How can you better manage third-party scripts and reduce the risks they introduce?
The next step is to deploy a solution specifically designed to provide client-side web application protection using a prevention-first approach versus only a detect-and-alert approach.
With most security teams already overworked, understaffed, and drowning in alerts, solving the client-side problem can’t add more burden for the security team.
Solutions relying on a detect-and-alert approach flag potentially malicious activity and ask the team to investigate and respond to what can be thousands of false positives.
Instead, your company needs a solution that prevents the problem from the start, doesn’t impact site performance, and requires little to no human oversight to work. Consider the following:
- Implement a control system to identify and control all 3rd party JavaScript on your web pages. It is critical to control the access of all 3rd party JavaScript on your web pages; therefore, ensuring the control system can identify and control each external JavaScript is crucial to the process.
- Make sure Nth-party JavaScript is either blocked or managed by the system. Many 3rd party JavaScript providers will work in cooperation with other providers to increase their efficiency; as their partners, they have the same unlimited DOM access and, therefore, should either be blocked or managed in the same manner as a 3rd party.
- Make sure the “whitelisted” 3rd party cannot bypass the security applied policies. Some access policy platforms will use easily bypassed methods to limit 3rd party access, such as CSP/SRI or JavaScript Proxying. These are easily bypassed and are considered ineffective.
- Ensure security controls remain effective even if 3rd party resources change 3rd party resources change rapidly and are often generated dynamically.
- Implement security controls that protect the entire duration of a visitor’s session. Auditing and inventorying known 3rd party resources is ineffective as additional resources can be called into a session at any time, from moments after page load to minutes or even hours later.
- Ensure controls implemented do not introduce additional vulnerability. Security controls introduced to address 3rd party risk may inherently present some risks themselves.
What to look for in an optimal client-side security solution?
A client-side security platform that uses real-time, client-side sandboxing and permissions-based isolation and reflection to protect your company and customers’ data and prevent successful data exfiltration or leakage. This is accomplished as follows:
- Isolating and monitoring JavaScript execution in an end user’s browser in real-time, as the user interacts with your web page
- Using real-time JavaScript sandboxing to restrict the access that each script has to a web page as well as control that script’s behavior
- Allowing or restricting access to different parts of the page and the data that they contain
- Monitoring and managing the flow of data from the page to other places
- Enforcing security controls
