← All posts

What technology is this website using, and is any of it outdated

CentralCSP Team ·

Last update:

You want to know what a website is built with. Maybe it is a competitor's site, a vendor you are about to onboard, or your own site after three agencies and a tag manager have been through it. The quick answer: paste the URL into the free Technology Checker. It lists the JavaScript libraries and frameworks the page uses, the version of each, whether that version is current, and the known CVEs that affect it.

The longer answer depends on why you are asking. Knowing that a page runs jQuery is trivia. Knowing that it runs jQuery 1.12.4, from a release line that ended years ago and affected by four published CVEs, is a finding. This post covers both: how to see what a website uses, and how to tell whether any of it needs attention.

How to find out what technology a website uses

Everything a browser downloads is visible from outside. That covers more than people expect:

  • JavaScript libraries and frameworks: jQuery, React, Vue, Angular, Lodash, Bootstrap, and the libraries bundled inside third-party widgets.
  • Third-party services: analytics, tag managers, chat widgets, payment SDKs, A/B testing tools.
  • The platform: a CMS such as WordPress or Shopify often shows in its asset paths and markup.
  • Part of the server side: response headers such as Server or X-Powered-By can name the web server or the language, when the site has not removed them.

What you cannot see is anything the browser never receives: server-side code, databases, internal services, and the exact build process. Any tool that claims to read those from a URL is guessing.

There are four ways to collect the visible part, from fully manual to fully automatic.

Check by hand in the browser

For one page and a few minutes, the browser's developer tools answer most questions.

  1. View the page source. Script tags, stylesheet links, and generator meta tags often name the platform outright, for example a wp-content path for WordPress.
  2. Open the Network panel, filter on JS, and reload. Each script URL is listed. A versioned filename or CDN path such as jquery-3.7.1.min.js names the library and its version.
  3. Read the response headers of the main document in the same panel. A Server: nginx/1.18.0 or X-Powered-By: PHP/7.4 header names software and version. Those banners are an information disclosure in their own right, covered in Information disclosure headers.
  4. Ask the library itself in the console. Most popular libraries expose their version on their global object:
jQuery.fn.jquery   // "3.7.1"
angular.version    // AngularJS only, { full: "1.8.3", ... }

The manual route has two blind spots. A library bundled inside another file, such as a vendor widget's widget.js, has no telling filename. And the console only answers for the copy that owns the global, so a page that loads two jQuery copies shows you one. The jQuery version guide goes through that case in detail.

Browser extensions and lookup sites

The tools most people find first answer "what is this site built with" broadly.

  • Wappalyzer is a browser extension for Chrome, Firefox, Edge, and Safari that shows the stack behind the page you are on. A free plan covers a monthly quota of lookups, and paid plans add company data and lead lists.
  • BuiltWith looks up a domain on its website and returns a technology profile, backed by years of adoption data. Its business is lead generation and market data.
  • WhatRuns is a free browser extension in the same spirit, and can notify you when a site you follow adds or removes a technology.

They are good at the breadth question: the CMS, the hosting provider, the analytics and marketing stack. They are not built for the security question. None of them tells you whether the version a page runs is outdated, has reached end of life, or is affected by a published CVE.

Developer tools that check for vulnerable versions

Retire.js is the long-standing open source answer to the security question. Its command-line scanner matches JavaScript files against a database of known vulnerable versions and can write the result as a CycloneDX software bill of materials (SBOM). It scans files you already have, such as a build output or downloaded scripts; a separate headless site scanner covers live pages. Its Chrome extension is not in the Chrome Web Store and its Firefox extension is deprecated, so the command line is the maintained route.

Lighthouse used to cover this too, with an audit that flagged front-end libraries with known vulnerabilities. That audit was removed in Lighthouse 10, so a clean Lighthouse report says nothing about library CVEs.

Both are developer tools. They suit a pipeline or a terminal, not a quick look at a URL by someone who does not run Node.js.

Check versions, end of life, and known CVEs from one URL

The Technology Checker is the URL-first version of that security question. Enter a page address and it reports one row per technology:

  • Version. The version in use, or a dash when no version could be read.
  • Version status. Up to date, outdated, dormant (the project has not shipped a release for a long time), or end of life (the release line no longer receives fixes).
  • Latest in line. The newest release in the same line, so you know the smallest upgrade that helps.
  • Highest severity. The most severe known vulnerability affecting that version.

Expand a row to see where the technology was detected and each known vulnerability: its CVE id, severity, a short summary, the version that fixes it, and links to the advisories.

Two things to keep in mind when you read a result:

  • A listed CVE is not proof the site is exploitable. It means the detected version falls in a range a public advisory marks as affected. Whether it can be exploited depends on how the page uses the library, and some vendors backport a fix without changing the version number.
  • End of life matters even with no CVE. A release line that no longer receives fixes will keep the next vulnerability forever. That is often the earlier, quieter signal.

The checker is free and needs no account. Results are not saved, so export what you want to keep. Only check sites you own or are authorised to assess; the checker reads the same public resources a browser downloads, and nothing else.

Which tool answers which question

CentralCSP Technology CheckerWappalyzerBuiltWithRetire.js
InputA URLThe page open in your browserA domainLocal files, or a separate headless site scanner
Names the technologiesYes, with a focus on JavaScript libraries and frameworksYesYesJavaScript libraries only
Library versionsYesSomeNot its focusYes
Known CVEs per versionYesNoNoYes
End-of-life statusYesNoNoNo
SBOM exportCycloneDX, CSV, PDFNoNoCycloneDX
FreeYes, no accountA free planA basic lookupYes, open source

Pick by question. For "what CMS and marketing stack does this company run", a lookup site answers faster. For "is any library on this page outdated or vulnerable", you need versions matched against advisories, which is what Retire.js and the Technology Checker do.

Export an SBOM of a website

A list on screen is fine for a quick look. A supplier review, a security questionnaire, or an audit wants a file. The Technology Checker exports the same result three ways:

  • CycloneDX 1.6 JSON, the standard SBOM format, with each technology as a component and each known vulnerability linked to the component it affects. Security and compliance tools read it directly.
  • CSV, one row per technology and vulnerability, for a spreadsheet or a ticket.
  • PDF, a dated report in the same layout as our scanner reports, for a reviewer who wants a document.

A dated SBOM of the scripts a payment page loads is useful evidence when you work through the PCI DSS v4 script requirements, which CentralCSP helps you meet; the PCI DSS page covers how.

When a one-off check is not enough

A check reads one page, once. Your site has other pages, and the set of scripts changes with every deployment and every tag manager publish. The library that was current on Monday can have a CVE on Friday.

Continuous coverage needs the browser to report what it runs. Content Security Policy (CSP) hash reporting does that, and Technologies in CentralCSP turns the reports into a live inventory of every library version your visitors load, with alerts when a new advisory affects one of them. How to detect vulnerable JavaScript libraries on a live website explains the mechanism, and the supply-chain page has the tour. To try it on your own site, start free with CentralCSP.

FAQ

Can I check the technologies of a website I do not own?

The technologies a page loads are public: every visitor's browser downloads them. Reading them is passive and is what any browser does. Run security checks only on sites you own or are authorised to assess, and treat what you find on someone else's site as their information to act on.

Can a website hide the technologies it uses?

Partly. A site can remove version banners from its headers, rename files, and bundle libraries into one file, which defeats filename and header checks. The libraries still run in the browser, so they can usually still be identified, though not always with a version.

Why does a technology show no version?

Some files do not expose a version, and some services, such as a CDN or a tag manager, have no version that applies to the page. The checker then lists the technology without a version.

Is the Technology Checker a Wappalyzer alternative?

For the security question, yes. Wappalyzer and BuiltWith answer which technologies a site runs, across a wide catalogue. The Technology Checker focuses on JavaScript libraries and frameworks and adds what a security review needs: the version status, end of life, known CVEs with their fixed version, and an SBOM export.

Sources