third_party_detector_skill

This skill identifies third-party services such as payments, analytics, auth, CRM, and support from signals across a target.

Python

42

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill transilienceai/communitytools --skill third_party_detector

SKILL.md9.7 KB

Overview

This skill identifies third-party services used by a target application across payments, analytics, authentication, CRM, support, error monitoring, A/B testing, CDN, and social integrations. It consolidates signals from JavaScript, HTML, HTTP headers, DNS records, and job postings to produce a weighted inventory of integrated services and likely integration types. The output helps security researchers and pentesters prioritize potential attack surfaces and privacy exposures.

How this skill works

The detector parses script URLs and global JavaScript variables, extracts domains from CSP headers, inspects DNS TXT records, and scans job postings for technology mentions. It matches those raw signals against a catalog of service patterns and assigns weights by signal type to estimate confidence. Results list detected technologies, signal evidence, aggregated weights, and likely integration types (client-side SDK, chat widget, server-side API). The skill also provides confidence guidance per signal class.

When to use it

During reconnaissance to map third-party services on a target web app
Before a penetration test to identify external dependencies and attack surface
When evaluating privacy or data-flow risks from analytics and trackers
To prioritize bug bounty research by focusing high-confidence integrations
When auditing supply-chain exposure from embedded SDKs and widgets

Best practices

Combine multiple signal types (script URL + JS global + CSP) for higher confidence
Treat CSP and job-posting matches as medium/low confidence and validate manually
Record the exact evidence (URL, CSP domain, TXT record) for reproducibility
Note client-side SDKs separately from server-side APIs to guide exploit paths
Watch for multiple analytics or monitoring tools—each can leak telemetry

Example use cases

Detecting Stripe and PayPal integrations to target payment flow testing
Finding Google Analytics, Segment, or Mixpanel to assess data exfiltration risk
Identifying Intercom or Zendesk chat widgets that expose client-side attack vectors
Spotting Sentry or Datadog RUM to locate client-side error reporting endpoints
Confirming Auth0 or Okta presence to focus authentication and token handling checks

FAQ

Accuracy depends on signal type: script URLs and DNS TXT records are highly reliable, CSP domains are medium confidence, and job postings are lower confidence. Combining signals raises overall confidence.

Can it detect server-side only integrations?

Server-side-only services may not appear in client-side signals; they are often inferred from CSP entries, API domains, or job postings and should be validated by server interactions or additional scanning.