Exposure · Check
Detected technology stack — what an outside observer can fingerprint about your site
We aggregated the passive signals already collected during the scan — Server header, X-Powered-By, meta generator tags, body markers (`__NEXT_DATA__`, `Shopify.theme`, `data-wf-page`), third-party origins your scripts load from, your CDN/WAF, and your MX records — into a single inventory of detected stack components. The same inventory is what an external attacker can derive without sending any active probes.
Why it matters
Visibility into your own footprint is the prerequisite for every other hardening decision: cross-reference each component against current CVE feeds, vendor security advisories, and your patch pipeline. Strip what you don't need (Server version banners, X-Powered-By, /readme.html files) so the inventory shrinks for the next attacker that scans you.
Real-world risk
The detected components are what an external attacker can fingerprint from your site without sending active probes. Each one points at a CVE list and a vendor security advisory feed they can monitor for the next exploit that fits your build.
Fix steps (in order)
- Cross-reference each detected component against your patch pipeline: CMSes, framework versions, server banners, and the third-party scripts loaded on your homepage.
- Strip unnecessary fingerprint surface: hide the Server version banner, drop X-Powered-By, remove /readme.html and similar version-disclosing files.
- Audit third-party origins: each one is supply-chain surface area. Confirm each is intentional, scoped to the pages that need it, and pinned with Subresource Integrity where possible.
- Subscribe to vendor security advisories for the top components (CMS, framework, CDN/WAF, payments processor) so you hear about CVEs the same week they're announced.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (tech_stack_fingerprint) clears once the externally-observable signal is in place.