What is Shadow Code?
Application developers often rely on open source libraries and third-party scripts in order to innovate faster and keep pace with evolving business needs. These libraries and third-party scripts in turn call other scripts, creating a digital supply chain of fourth-, fifth- and Nth-party scripts powering your web applications and websites.
Shadow Code is any code introduced into an application without formal approval or security validation. It is the application development equivalent of Shadow IT. It introduces unknown risks into the application and makes it difficult for the business to ensure data security and privacy, and to comply with regulations.
Shadow Code in Web Applications
Shadow Code takes many forms. Here are just some of the ways it spreads through your web applications.
- Open source libraries used in first-party scripts developed and hosted by you
- Legitimate third-party scripts introduced without a formal approval process
- Fourth-, fifth- or Nth-party scripts that are loaded by your vendor without your direct knowledge
- Malicious scripts such as digital skimmers injected through brute-force attacks on your infrastructure or through your script supply chain
- Third-party plugins for your Content Management Systems or e-commerce platform
- Malicious code injected into first-party scripts by rogue insiders
Learn why only 8% of organizations have full insight into the Shadow Code that runs on their application.
Shadow Code Examples
- Social sharing buttons, e.g., Twitter, LinkedIn, Facebook
- Advertising iframes, e.g., Google Ads, Facebook
- Payment iframes, e.g., Braintree, Paypal, Stripe, WePay
- Chatbots, e.g., 7.ai, Inbenta, Intercom
- Analytics and metrics scripts, e.g.. Google Analytics, Heap, HotJar
- A/B testing scripts for experiments, e.g.. Optimizely, Google Optimize
- Helper libraries, e.g,. jQuery, animation libraries
Consequences of Shadow Code
Information security teams need to be enablers rather than blockers of innovation, while also protecting the organization from cybersecurity risks. Agile processes such as CI/CD don’t leave room for traditional security audits that can take weeks or months to complete. As a result, infosec teams often have to inventory and audit scripts retroactively. By the time they finish one cycle, the application has already changed, leaving security teams constantly playing catch up and wasting considerable resources in the process.
Security and Compliance Challenges
Shadow Code introduces unknown risks into a web application. You cannot secure what you cannot see. The visibility gaps with Shadow Code and lack of effective controls make it challenging for any organization to ensure the privacy of their customers’ personal data and to comply with data privacy regulations such as the California Consumer Privacy Act (CCPA) and the Global Data Protection Regulation (GDPR). These regulations require that businesses regulate access to users’ personal data.
Client-side Data Breaches
Digital skimming and Magecart attacks are a direct result of Shadow Code lurking in web applications. These attacks inject malicious code into first- or third-party web scripts to harvest personally identifiable information (PII) from websites, including logins, passwords and credit card numbers. These attacks have impacted major websites resulting in hefty fines and compliance penalties.
Reducing the Risk from Shadow Code
Information security teams can follow a few best practices to regain control of Shadow Code without becoming blockers.
- Set up an agile notification and approval process for any third-party scripts or external libraries used in your applications. This will ensure basic visibility and facilitate a smoother feedback loop between developers and information security teams.
- Use code analysis and verification tools to detect vulnerabilities earlier in the cycle. Static Application Security Testing (SAST) tools can find vulnerabilities in first-party scripts while Software Composition Analysis (SCA) solutions can inventory and analyze open source libraries in your own applications. Features such as Subresource Integrity (SRI) allow browsers to verify the script at runtime and ensure that it has not been tampered with.
- Content Security Policy (CSP) is another capability native to browsers that can be used to reduce the risk of malicious Shadow Code being injected into your website. By enforcing allowlists, CSP can prevent unauthorized scripts from being loaded as well as prevent malicious scripts from exfiltrating data. However, CSP will not protect against a first-party compromise or insider threats where the attacker has access to resources on the allowlist.
- Invest in client-side application security solutions that provide continuous real-time visibility and control over all scripts running on your website. These solutions can detect if a new script gets loaded on the client side or if an existing script starts exhibiting suspicious behavior indicating a potential compromise. Such solutions can also automate CSP management and facilitate a trust-but-verify model for security.