lesson_12: reading technology signals
01 — why stack detection matters
technology detection is the practice of reading visible signals from a target and asking: what can be reasonably inferred from what is exposed?
A website can reveal parts of its stack through hostnames, dns records, response headers, html markers, asset paths, framework globals, cdn hints, and third-party scripts.
That does not mean every signal is proof.
A signal is a clue.
A stack detector should collect clues, show evidence, explain confidence, and expose visibility limits.
This is the purpose of stackprint: it performs shallow, browser-side inspection and shows only stack-relevant evidence.
micro meaning
• technology detection = reading visible stack clues
• signal = observable evidence
• finding = interpretation of a signal
• confidence = strength of the interpretation
• visibility limit = something the tool cannot see
• evidence matters more than labels
02 — shallow inspection is a design choice
stackprint is a shallow technology detector.
That means it does not crawl deeply, exploit anything, brute force paths, scan ports, or attack the target.
It looks at a small set of public-facing signals and asks what those signals can reasonably indicate.
In this tool, the inspection plan is simple:
• normalize the target url
• extract the host
• check public dns records
• try one browser-readable html fetch
• inspect visible headers
• inspect visible html
• report stack evidence
• show red visibility limits when the browser cannot see enough
Shallow inspection is useful because it teaches restraint.
The goal is not to “detect everything.”
The goal is to show what is visible from this execution context and what remains hidden.
micro meaning
• shallow means limited scope
• public probes reduce risk
• one target keeps the operation controlled
• visible evidence drives findings
• limits are part of the result
03 — target input is not decoration
When the user enters a target, they are defining where the analysis will point.
Example target:
The tool normalizes the input, extracts a host, and builds a target context.
If the user enters only a hostname, the tool can add https:// so the browser has a complete url to request.
The target is then used for:
• host-based checks
• dns-over-https lookups
• browser-readable html fetch
• header inspection
• html marker inspection
This matters because a url, a host, a root domain, and a page path are not the same thing.
micro meaning
• target url is the full address
• host is the hostname being analyzed
• root guess is a simplified domain guess
• path can affect what html is returned
• target choice affects evidence
04 — hostname can be evidence
Sometimes the hostname itself contains useful stack information.
Examples:
• deltice.github.io suggests GitHub Pages
• project.vercel.app suggests Vercel
• site.netlify.app suggests Netlify
• store.myshopify.com suggests Shopify
• project.pages.dev suggests Cloudflare Pages
These signals are strong because platform-managed hostnames are often directly tied to the platform.
But even strong hostname signals should still be presented as evidence, not magic truth.
A custom domain may hide the platform.
A platform hostname may be used for staging, demos, or abandoned assets.
micro meaning
• hostname suffix can reveal platform hints
• managed platform domains often carry strong evidence
• custom domains can hide infrastructure
• hostname evidence is useful but not complete
05 — dns is infrastructure evidence
dns turns names into records.
Stack detection can use dns to look for hosting, cdn, and managed-service hints.
This tool checks public dns records such as:
• A
• AAAA
• CNAME
• NS
A CNAME can point toward a managed platform.
An NS record can reveal a dns provider.
An A or AAAA answer may show address-level routing, though ip addresses alone often need careful interpretation.
Examples of dns hints:
• cloudfront.net may suggest Amazon CloudFront
• vercel-dns.com may suggest Vercel
• fastly.net may suggest Fastly
• myshopify.com may suggest Shopify
• cloudflare.com may suggest Cloudflare dns or edge infrastructure
micro meaning
• dns is naming infrastructure
• CNAME often reveals managed platforms
• NS can reveal dns provider
• A / AAAA show address answers
• dns evidence helps classify hosting and edge layers
06 — dns-over-https makes dns browser-readable
The tool uses dns-over-https so a browser-based page can ask public dns questions.
Instead of running a local command such as dig, the browser calls public dns resolver endpoints that return dns answers as web-readable data.
This is useful for an embedded educational tool because it works without a backend server.
The browser can ask:
• what A records exist?
• what AAAA records exist?
• is there a CNAME?
• which NS records are visible?
This turns dns evidence into something the user can inspect directly in the page.
micro meaning
• dns-over-https exposes dns answers through https
• browser tool can use public resolver APIs
• dns evidence can be gathered without a backend
• public records are useful for shallow classification
07 — html can expose framework markers
A page’s html can contain framework or platform markers.
Examples:
• NEXT_DATA may indicate Next.js
• /_next/static/ may indicate Next.js
• NUXT may indicate Nuxt
• /_astro/ may indicate Astro
• wp-content/ may indicate WordPress
• cdn.shopify.com may indicate Shopify
• data-wf-page may indicate Webflow
• docusaurus may indicate Docusaurus
These are useful because many frameworks and platforms leave recognizable asset paths, runtime globals, css names, meta tags, or script references.
But html evidence depends on what the browser can actually fetch and read.
If CORS blocks the html fetch, the tool may not see these markers.
micro meaning
• html marker is visible page evidence
• asset path can reveal framework structure
• runtime marker can reveal frontend framework
• meta tag can reveal self-identification
• html visibility controls what the detector can inspect
08 — headers can reveal runtime and edge layers
response headers can expose useful stack hints.
Examples:
• x-vercel-cache may suggest Vercel
• x-vercel-id may suggest Vercel
• x-nf-request-id may suggest Netlify
• cf-cache-status may suggest Cloudflare
• cf-ray may suggest Cloudflare
• x-amz-cf-id may suggest CloudFront
• x-powered-by: php may suggest PHP
• x-powered-by: express may suggest Express
• x-aspnet-version may suggest ASP.NET
Headers can reveal hosting, edge infrastructure, backend runtimes, cache behavior, or application frameworks.
But headers are often hidden, removed, normalized, blocked, or unavailable from browser-side JavaScript.
That means missing headers are not proof that the technology is absent.
micro meaning
• headers can reveal stack layers
• edge headers can reveal cdn or hosting platform
• x-powered-by can reveal runtime
• missing header does not prove absence
• browser visibility affects header evidence
09 — CORS creates a visibility boundary
CORS means cross-origin resource sharing.
For a browser-based detector, CORS is one of the most important limits.
A server may return a page to a browser tab, but browser JavaScript may not be allowed to read that page’s content from another origin.
That means a tool like stackprint may be unable to inspect:
• html body
• script paths
• meta tags
• visible response headers
• framework markers
When this happens, the tool should show a red visibility limit instead of pretending the stack is unknown with certainty.
A blocked fetch means:
the browser could not expose enough evidence to this page.
It does not mean:
the target has no detectable stack.
micro meaning
• CORS controls browser-side readability
• blocked html limits framework detection
• blocked headers limit edge/runtime detection
• visibility limit is a valid finding
• absence of evidence is not evidence of absence
10 — confidence is not truth
A stack detector should not simply print a technology name and act certain.
It should explain confidence.
A strong signal may come from a platform hostname, explicit generator tag, known asset path, or platform-specific header.
A weak signal may come from a generic script name, common css pattern, or broad keyword.
Example:
wp-content/ is a strong WordPress hint.
react-dom alone is a weaker React hint because many sites include React without revealing the whole stack.
A good detector should show:
• what was detected
• why it was detected
• which evidence triggered the finding
• how confident the detector is
• whether visibility was limited
micro meaning
• confidence is an estimate
• evidence supports a finding
• weak signal needs caution
• strong signal still needs context
• detector output is evidence, not authority
11 — stack signals can overlap
Modern websites are layered.
One target can use many technologies at once.
A site may use:
• Cloudflare for dns and edge protection
• Vercel for hosting
• Next.js for frontend rendering
• Google Tag Manager for tags
• HubSpot for marketing forms
• Stripe for payment scripts
• Sentry for error monitoring
This means stack detection is not usually one answer.
It is a layered picture.
The detector should avoid collapsing all evidence into one label.
micro meaning
• stack is layered
• cdn is not the same as framework
• hosting is not the same as cms
• analytics is not the same as application runtime
• multiple findings can all be true
12 — provider evidence is not ownership proof
Detecting a provider does not prove ownership.
If a target uses Cloudflare, that does not prove Cloudflare owns the application.
If a hostname points to CloudFront, that does not prove Amazon owns the website.
If a page loads Google Tag Manager, that does not prove Google owns the business.
Technology detection identifies visible infrastructure and software hints.
It does not automatically prove business ownership, authorization, scope, or responsibility.
micro meaning
• provider is infrastructure evidence
• owner is an attribution question
• stack signal is not legal scope
• cdn usage is not application ownership
• classification must not overclaim
13 — tech detection is classification, not exploitation
stackprint is a classification tool.
It asks:
what public technology signals are visible?
It does not ask:
how can this target be attacked?
That distinction matters.
Good reconnaissance starts by understanding the surface before escalating to heavier tools.
A shallow detector can help decide:
• what kind of site this appears to be
• whether the host is behind a cdn
• whether a framework marker is visible
• whether a cms marker appears
• whether browser visibility blocks deeper inspection
• whether next steps require another tool or permission
micro meaning
• classification reduces uncertainty
• reconnaissance is not automatically exploitation
• stack evidence helps choose next questions
• permission still controls what should happen next
14 — rules are only as good as their evidence
The detector uses rules.
A rule says:
if this marker appears, then this technology may be present.
Example:
NEXT_DATA suggests Next.js.
wp-content/ suggests WordPress.
x-nf-request-id suggests Netlify.
cf-ray suggests Cloudflare.
Rules are useful because they make detection explainable.
But rules can also be incomplete, outdated, or fooled by copied strings, cached pages, third-party widgets, or old assets.
That is why every rule should produce evidence, not only a label.
micro meaning
• rule maps evidence to finding
• marker triggers detection
• evidence keeps the finding inspectable
• false positive is possible
• explainability is part of trust
15 — dns, headers, and html see different layers
No single source sees the whole stack.
dns can reveal naming, cdn, hosting, or managed platform hints.
headers can reveal server, cache, runtime, or edge behavior.
html can reveal frontend framework, cms, analytics, scripts, and asset paths.
Each layer answers a different question.
• dns asks: where does the name point?
• headers ask: what metadata came back with the response?
• html asks: what visible page markers exist?
• hostname asks: does the name itself reveal a platform?
A better detector combines layers.
micro meaning
• dns sees naming infrastructure
• headers see response metadata
• html sees page-level markers
• hostname sees naming clues
• combined evidence improves interpretation
16 — red limits are part of the result
A red visibility limit is not a failure of the interface.
It is important information.
If the browser cannot read the html or headers, the detector should say so clearly.
That helps the user understand why results may be thin.
A limited result can still include:
• hostname evidence
• dns evidence
• platform suffix evidence
• public resolver evidence
But it may miss:
• html framework markers
• generator meta tags
• script paths
• response headers
• frontend runtime markers
micro meaning
• limit explains what is invisible
• red finding prevents false confidence
• partial evidence can still be useful
• blocked html reduces detection depth
• honest uncertainty is better than fake certainty
17 — what this lab makes visible
This lab turns shallow tech detection into an observable process.
It surfaces:
• target host
• root guess
• dns answers
• html visibility
• html byte count
• rules hit
• confidence
• analysis plan
• terminal log
• signal index
• selected evidence
• red visibility limits
That matters because users should see how a conclusion was reached.
The label alone is not enough.
The evidence path is the lesson.
micro meaning
• plan shows method
• terminal shows process
• metrics show inspection shape
• findings show interpretations
• evidence shows why the finding exists
18 — what the user should learn
The user should leave understanding that technology detection is not magic.
It is evidence-based classification.
The important questions are:
• what signal was visible?
• where did the signal come from?
• which layer produced it?
• how strong is the evidence?
• what was invisible?
• what should not be concluded from this?
A good stack detector teaches both evidence and restraint.
It should help the user avoid two mistakes:
• believing every label too strongly
• ignoring visibility limits completely
micro meaning
• signal is observation
• finding is interpretation
• confidence is judgment
• limit is boundary
• restraint makes the detector useful
19 — final line
stack detection is not guessing a logo.
it is reading visible technology evidence.
dns shows naming infrastructure.
headers show response metadata.
html shows page-level markers.
cors shows what the browser is not allowed to see.
Good stack literacy begins with three questions:
• what evidence is visible?
• what does that evidence actually support?
• what remains outside the tool’s visibility?