Script Detection: What a Page's <script> Tags Reveal
Script detection reads a page's script tags: the URLs it loads scripts from and the inline script code between the tags. Both frequently name a library: /wp-includes/js/, cdn.shopify.com, react.production.min.js.
Why it matters
Scripts are where most client-side technology announces itself: from analytics snippets to framework bundles to vendor CDN paths. A page loading from cdn.shopify.com is running Shopify. A page loading react-dom.production.min.js is using React. This makes script detection one of the highest-yield vectors.
The script URL also frequently encodes the version: /jquery.min.js?ver=3.6.0 yields both the library name and its exact version in a single match. For many libraries, the script URL is the only source of version information.
How it works
Scalpel Stack scans the page's HTML for all <script> tags, collecting their src attributes and the inline script text. Both are matched against the fingerprint database as separate detection channels.
External scripts (those with src) are matched against URL patterns in the database. Patterns look for known CDN hostnames, recognizable paths, and version query strings. A pattern like /jquery.min.js or cdn.shopify.com fires immediately.
Inline scripts are matched against regex patterns in the database: snippets from analytics platforms, feature detection code, or configuration blocks that are nearly identical across all uses. A Google Analytics tracking snippet is almost always the same, so a pattern match is reliable.
The amount of inline script that is scanned is capped for performance and safety: huge pages and malicious payload attacks are avoided.
What does not matter
A script can be minified and its version string stripped. A bundled app might load app.min.js with no indication of what frameworks it contains. A page could deliberately load a script from a misleading URL, though this is rare.
Content Security Policy (CSP) restrictions can prevent inline script inspection, though this isn't common in practice.
Code example
A page with external scripts might look like this:
<script src="https://cdn.shopify.com/s/files/1/0000/0000/0000/t/123/assets/app.js"></script>
<script src="https://cdn.jsdelivr.net/npm/react@18.2.0/umd/react.production.min.js"></script>
<script src="/wp-content/plugins/yoast-seo/js/index.js"></script>
Matching these against the fingerprint database yields:
- Shopify from the
cdn.shopify.comhostname - React 18.2.0 from the React CDN path
- Yoast SEO plugin from the
/wp-content/plugins/path
An inline snippet from Google Analytics might look like:
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
</script>
This pattern is recognizable enough to fingerprint.
How Scalpel Stack shows it
Evidence lines using the scriptSrc or scripts vector badge record the matching script URL or inline snippet (truncated for readability). The matched text is rendered as inert text only, never executed, so a malicious inline script can never run the content inside the extension.