Website Technology Detector

Discover the underlying technologies used to build any website, including web servers, frameworks, CMS, and more.

Evidence ASSESSED

Checked against: Response headers, cookies and markup fingerprints

RED TEAM 0 findings BLUE TEAM control did not hold

Detection Methodology

We use non-intrusive fingerprinting techniques to identify website stacks:

HTTP Headers: Analyzing Server, X-Powered-By, and Set-Cookie headers for version info.
HTML Source: Searching for distinctive patterns in script tags, meta tags (like generator), and CSS class names.
Well-Known Paths: Checking for the existence of platform-specific directories like /wp-content/ or /sites/default/.
DNS Signatures: Identifying hosting platforms via nameservers and CNAME targets.

Our Technology Detector identifies the software stack behind any website — web server, CMS, frameworks, JavaScript libraries, analytics and CDN — from response headers, markup patterns and asset paths.

What is Technology Detection?

Technology detection infers what software a website runs from the evidence it exposes publicly. No single indicator is conclusive; the picture is built from several.

Response headers are the most direct source. Server and X-Powered-By name the web server and language outright, and framework-specific headers such as X-Drupal-Cache or X-Generator identify the application layer. Markup contributes generator meta tags, characteristic class naming and comment patterns. Asset paths are often decisive — /wp-content/ means WordPress as reliably as anything.

Version detection is less certain. Some software announces its version directly, but more often it is inferred from the presence or absence of features, or from the fingerprint of a specific library file.

Infers the software stack from publicly exposed evidence
Response headers frequently name the server and language directly
Asset paths are among the most reliable indicators
Generator meta tags identify many content management systems
Version detection is less certain than product detection

Why Technology Detection Matters

Attackers fingerprint before they attack. Knowing a site runs a particular CMS version narrows the work from broad probing to checking the handful of published vulnerabilities that affect it. This is the first step of most opportunistic compromises, and it is entirely passive.

Running the same detection against your own estate is how you find what you have forgotten. An inventory built from documentation is always out of date; one built from what the systems actually expose is not. It also reveals unnecessary disclosure — version numbers in headers serve no functional purpose and simply narrow an attacker search.

Attackers fingerprint software before selecting an exploit
Version disclosure narrows the search to known vulnerabilities
Reveals outdated components across your own estate
Builds an inventory from reality rather than documentation
Identifies third-party dependencies you may not have known about

How This Technology Detector Works

The tool fetches the page and matches its response against known technology signatures.

Validates the URL input against format and SSRF safety checks
Fetches the page and captures the full response headers
Examines headers for server, language and framework identifiers
Matches markup patterns, generator tags and asset paths against signatures
Reports the detected technologies with version information where available

How to Use the Technology Detector

Enter the URL you want to analyse
Run the detection to fetch and fingerprint the response
Review the identified components and any version information
For your own sites, check whether any detected version is outdated
Consider suppressing version disclosure where it serves no purpose

Understanding Your Technology Detection Results

Detections come from different sources with different reliability:

Field / Value	Meaning
`Web server`	nginx, Apache, IIS or similar, usually named directly in the Server header along with a version that is rarely necessary to disclose.
`Programming language`	Frequently exposed through X-Powered-By or session cookie naming. PHP, ASP.NET and Node.js are commonly identifiable this way.
`CMS`	WordPress, Drupal, Joomla and others, identified from asset paths, generator meta tags and characteristic markup. Usually the most reliable detection.
`Framework`	Laravel, Django, Rails and similar, inferred from cookie names, header patterns and error page formats.
`JavaScript libraries`	jQuery, React, Vue and others, detected from script filenames and global variables. Versions are often visible in the file path itself.
`CDN`	Cloudflare, Fastly, Akamai or similar, identified from headers they add. Their presence means the origin server details are hidden.
`Version numbers`	Where detected, these are the most sensitive disclosure. A specific version maps directly to a list of published vulnerabilities.

Common Problems & How to Fix Them

Disclosing the exact version tells an attacker precisely which published vulnerabilities to try, with no probing required.

In nginx set server_tokens off. In Apache set ServerTokens Prod and ServerSignature Off. In PHP set expose_php = Off. In ASP.NET remove the X-Powered-By header through configuration.

This is obscurity rather than security — it does not fix anything — but it removes free reconnaissance and costs nothing.

An outdated component with published vulnerabilities is actively exploitable, and automated scanning finds it without any targeting.

Update it. Where updating is blocked by a compatibility problem, apply a virtual patch at the WAF as an interim measure and treat the update as a priority rather than a backlog item. Outdated CMS plugins are the single most common route to website compromise.

Many content management systems add a generator meta tag naming the product and version, which is the easiest fingerprint to collect.

Remove it. Most CMS platforms have a setting or a small snippet for this. Also check for version strings appended to stylesheet and script URLs, which disclose the same information through a different route.

Either the site is behind a CDN that normalises headers, or headers have been deliberately suppressed.

This is generally a good sign for your own site. For assessment purposes it simply means fingerprinting must rely on behavioural signals rather than declared ones, which is slower but not impossible.

Client-side libraries with known vulnerabilities are exploitable through cross-site scripting and prototype pollution, and old jQuery versions in particular remain widespread.

Update the libraries, use subresource integrity so a modified file is refused by the browser, and remove libraries that are no longer used rather than leaving them loaded.

Best Practices

Suppress version numbers in Server, X-Powered-By and generator tags
Run detection against your own estate to build a real inventory
Keep every detected component updated, particularly CMS plugins
Remove unused libraries rather than leaving them loaded
Use subresource integrity on third-party scripts
Re-check after every deployment, since headers are easily reintroduced
Treat a CDN as hiding rather than removing the origin fingerprint

Security Recommendations

Remember suppressing version disclosure is obscurity, not a fix — the underlying component still needs updating
Prioritise updating any component with published vulnerabilities, since automated exploitation requires no targeting
Audit third-party scripts, as each is code executing with full access to your pages
Be aware attackers fingerprint passively, so there is no log entry warning you it happened
Check that error pages do not disclose framework versions and stack traces
Include technology detection in regular assessment rather than only at deployment

Frequently Asked Questions

By matching evidence the site exposes publicly — response headers, generator meta tags, asset paths, cookie names and markup patterns — against known signatures. Asset paths such as /wp-content/ are among the most reliable indicators.

Suppressing version numbers is worthwhile and costs nothing, since a specific version maps directly to a list of published vulnerabilities. Hiding the product entirely is harder and less useful — the priority is keeping it updated.

Only marginally. It is obscurity, not a control, and a determined attacker will fingerprint behaviourally regardless. It does remove free reconnaissance for opportunistic scanning, which is worth the trivial effort.

Usually a CDN normalising headers, or deliberate suppression of identifying information. For your own site this is a reasonable outcome. It makes fingerprinting slower rather than impossible.

Most content management systems have a setting or a short snippet to remove it. Also check for version strings appended to stylesheet and script URLs, which disclose the same information through a different route.

Because exploitation is automated. Once a vulnerability is published, scanning for affected versions happens at internet scale within days, and no targeting is required. Outdated CMS plugins are the most common route to website compromise.

Fetching a page and reading its response is ordinary browsing. Acting on the information to attempt exploitation is not. Detection itself is passive and unremarkable; what follows determines whether it is legitimate.