Frequently Asked Questions

Externalsight is an External Attack Surface Management (EASM) platform. It runs 48 deterministic full-scan scanners against internet-facing domains, scores results across 8 weighted categories on a 0–100 scale, and generates actionable remediation steps for every finding.

It supports continuous background monitoring via a built-in scheduler, email notifications, webhooks, and PDF report generation — all without installing any agents on your infrastructure.

No. Externalsight is entirely agentless. It operates as an outside-in scanner from the public internet — no endpoint agents, no firewall rule changes, no code deployments on your side.

It mimics the initial discovery phase of an external adversary, mapping publicly accessible records and misconfigured services exactly as an attacker would see them.

Create a free account, add your domain in the Dashboard, and click Scan. The scan pipeline runs immediately and results appear within a few minutes. Your dashboard shows the composite risk score, all findings grouped by severity, and remediation steps for each issue.

A full scan has a 420-second total pipeline ceiling. Scanners run concurrently across 4 phases, and each individual scanner has a 90-second timeout. Scanners that hit their timeout are marked unavailable rather than error, so the score is still computed from all scanners that did respond.

Domain limits are enforced per subscription plan:

• Recon (free) — 1 domain
• Sentinel — 3 domains
• Fortress — 10 domains

Yes — you must own or have explicit authorization to test any domain you add. Externalsight operates identically to a benign internet crawler and does not exploit vulnerabilities, but you are solely responsible for ensuring you have the legal right to scan any domain you submit.

Externalsight runs 48 deterministic full-scan scanners organized into 4 sequential phases. Within each phase, scanners run in parallel via a ThreadPoolExecutor. DAST runs as a separate plan-gated active-testing workflow.

• Phase 1 — DNS / SSL / HTTP: DNS resolution, SSL/TLS configuration, HTTP headers, redirect chains, zone transfers, DNSSEC, WHOIS, passive DNS, host header injection
• Phase 2 — Discovery: Subdomains, open ports, certificate transparency, technology fingerprinting, API endpoint discovery, JavaScript endpoint extraction, GraphQL detection, robots.txt / sitemap parsing
• Phase 3 — Secrets & Exposure: Passive credential exposure signals, exposed secrets, phishing / brand spoofing, cloud storage exposure (S3, GCP, Azure, Firebase), email spoofing, IP intelligence and reputation
• Phase 4 — Advanced Intel: ASN discovery, reverse WHOIS, subsidiary mapping, CVE enrichment, Shodan threat intelligence, WAF/CDN detection, CORS misconfigurations, CSP validation, cookie security, subdomain takeover, admin panel detection, open redirects, sensitive file exposure

Dynamic Application Security Testing (DAST) is an active scanning mode that probes running web applications for runtime vulnerabilities. Externalsight's DAST module checks for three specific categories:

• Error page information disclosure — detecting stack traces, framework version banners, or SQL error messages exposed in HTTP error responses
• XSS reflection — using safe, alphanumeric-only markers to test whether inputs are reflected unsanitized in responses
• SQL injection error detection — sending read-only payloads and pattern-matching the response for database error strings, without executing any destructive queries

DAST is available on Sentinel and Fortress plans only.

• Recon — DAST not available
• Sentinel — 3 DAST scans per calendar month
• Fortress — 10 DAST scans per calendar month

The quota resets on the 1st of each UTC month. Remaining quota is tracked in the database and checked before each DAST scan is initiated.

No. Externalsight is strictly a non-exploitation platform. It does not execute malicious payloads, attempt privilege escalation, perform brute-force attacks against authentication portals, or exploit any vulnerability it discovers.

Even the active DAST probes are non-destructive: XSS checks use safe alphanumeric markers, and SQL injection checks use read-only patterns that cannot modify data. The platform interacts with public-facing HTTP servers, queries DNS, and inspects TLS handshakes — nothing more.

No. Every finding is backed by concrete, reproducible network evidence. Externalsight does not use generative AI or heuristic guessing to produce findings.

If it flags a missing DMARC record, the DNS record physically does not exist. If it flags an exposed S3 bucket, the scanner received an unauthenticated HTTP response from that bucket. If it alerts on a misconfigured Content-Security-Policy header, that header was absent or malformed in the actual HTTP response.

Externalsight exclusively uses Google (8.8.8.8) and Cloudflare (1.1.1.1) as DNS resolvers. System DNS is never used.

This is a deliberate design choice: system DNS can be a split-horizon internal resolver that returns private IPs, which would make all external attack surface findings meaningless. Using public resolvers guarantees results reflect the public internet view of your domain — which is exactly what an external attacker sees.

The score engine computes a 0–100 composite risk score across 8 weighted security categories — TLS security, DNS security, HTTP headers, exposed services, secrets and credential exposure, cloud exposure, application security, and infrastructure posture. A higher score means lower risk.

After individual scanner scores are computed, the chain engine applies correlation rules across results. For example, if no WAF is detected and HTTP headers are simultaneously misconfigured, the combined risk is elevated beyond what each finding warrants independently, reducing false comfort from partial coverage.

• 0–49 (Critical/High risk): Significant exposure requiring immediate remediation. Shown in red in the dashboard.
• 50–74 (Medium risk): Notable findings that require attention and a remediation plan. Shown in amber.
• 75–100 (Low risk): Well-configured perimeter with minimal exposure. Shown in green.

Each individual finding is classified into one of five severity levels: CRITICAL, HIGH, MEDIUM, LOW, and INFO. Severity is determined by the severity classification engine based on the scanner type, what was found, and any chain correlation adjustments applied.

Chain analysis applies cross-scanner correlation rules after all individual scans complete. Rather than scoring each finding in isolation, the chain engine identifies compound risk — situations where two co-existing weaknesses are more dangerous together than either is alone.

Example: a missing WAF combined with misconfigured HTTP security headers creates a compounded exposure that the chain engine escalates. This reduces alert fatigue by surfacing genuinely dangerous configurations rather than generating noise from individual low-severity findings.

After technology fingerprinting identifies specific software and version numbers on your attack surface, the enrichment engine cross-references a locally cached National Vulnerability Database (NVD) using CPE mappings. This surfaces known CVEs associated with the exact software versions discovered — without making repeated external API calls on every scan.

The local NVD cache is stored at data/nvd_cve_cache.json and is refreshed periodically. CPE mappings are cached in data/cpe_mapping.json.

Yes. Externalsight generates PDF reports via WeasyPrint using a purpose-built Jinja2 report template. Reports include the composite risk score, all findings organized by severity category, and the full remediation steps for every detected issue.

• Recon (free) — 1 domain, 3 full scans/month, 2 full scan records retained, passive EASM scanning, no monitoring
• Sentinel — 3 domains, 15 full scans/month, 50 category scans/month, 48-hour background monitoring, webhooks, 3 DAST scans/month
• Fortress — 10 domains, 50 full scans/month, 120 category scans/month, 24-hour background monitoring, email alerts for all severities, webhooks, 10 DAST scans/month

• Recon — 2 full scan records per domain
• Sentinel — 3 full scan records plus 12 summaries per domain
• Fortress — 3 full scan records plus 12 summaries per domain

Sentinel and Fortress plans include continuous background monitoring. The Recon free plan does not include any automated monitoring — scans must be triggered manually.

• Sentinel — 48-hour interval only
• Fortress — 24-hour interval only

• Recon — No email notifications
• Sentinel — No email notifications; webhook alerts are supported
• Fortress — Email alerts for all severities: CRITICAL, HIGH, MEDIUM, and LOW

Webhooks are available on Sentinel and Fortress plans. They allow you to POST security findings to external endpoints — useful for Slack integrations, SIEM pipelines, ticketing systems, or any custom alerting workflow.

When a paid plan expires, your account reverts to the Recon free tier. Plan expiration is enforced on protected API routes — features gated to paid plans (monitoring, notifications, webhooks, DAST) become inaccessible until the plan is renewed. Your existing scan data is not deleted on expiration.

Externalsight uses APScheduler to run three background jobs continuously when monitoring is enabled:

• Every 5 minutes: Check domains due for re-scan, queue new scans with randomized jitter (0–600 seconds) to distribute load
• Every 30 minutes: Reap stale scans stuck in running status beyond the expected completion window
• Every 24 hours: Run the validation framework against ground-truth domains to verify scanner accuracy

To prevent alert fatigue, Externalsight enforces two layers of email throttling:

• Rate limit: A maximum of one email per 6 hours, regardless of how many findings are detected in that window
• Deduplication: Identical findings seen within the past 24 hours are suppressed and will not trigger a repeated alert

Quiet hours allow you to define a UTC time window during which email notifications are suppressed — even if a monitoring scan completes and new findings are detected. For example, configuring quiet hours from 22:00 to 08:00 prevents overnight alert emails. Scans still run; only the notification delivery is delayed until quiet hours end.

An alert fires when a background monitoring re-scan detects a new finding or a change in your attack surface posture. The notification is only sent if:

• The finding's severity matches your plan's allowed severity levels
• The same finding has not been seen within the 24-hour deduplication window
• No email has been sent within the past 6-hour rate limit window
• The current time is outside your configured quiet hours (if enabled)

Yes, via webhooks on Sentinel and Fortress plans. Configure a webhook URL in your notification settings and Externalsight will POST findings as JSON to that endpoint whenever a new alert is triggered. This works with Slack incoming webhooks, any SIEM with an HTTP collector, or custom integrations.

No other user can access your data. Supabase Row-Level Security (RLS) policies are enforced at the database level — every query is automatically filtered by your user ID. No API endpoint or database query can return another user's scan reports, domain list, alert history, or findings.

Scan results (the full report JSON) are compressed with zlib + base64 encoding before being stored in Supabase PostgreSQL to reduce payload size. They are stored in the scans table alongside scan metadata (status, timestamps, domain reference).

• DNS resolution: Google (8.8.8.8) and Cloudflare (1.1.1.1)
• CVE data: National Vulnerability Database — cached locally in data/nvd_cve_cache.json
• Credential exposure signals: Derived from internal scanner evidence
• Secret scanning: Publicly observable scanner evidence only
• Certificate transparency: crt.sh for subdomain discovery
• Threat intelligence: Shodan — optional integration
• Auth & database: Supabase (PostgreSQL + JWT RS256/ES256)

All API requests are authenticated via Supabase JWT tokens (RS256 or ES256 algorithm). The JWT is passed in the Authorization: Bearer <token> header on every request. The auth middleware validates the token signature, expiry, and extracts the user ID before any protected route handler executes. There are no API keys or session cookies for API endpoints.

Subdomain results depend on public evidence: certificate transparency logs, passive DNS data, DNS records, sitemap and robots.txt references, and live resolution. Private, internal, recently created, or wildcard-only hostnames may not appear until public sources expose them.

If you believe an asset is missing, run a fresh scan after DNS propagation completes and confirm the hostname resolves publicly from the internet.

unavailable means a scanner could not produce reliable evidence within its timeout or dependency constraints. It is different from a confirmed vulnerability. The overall score is still computed from scanners that returned valid results.

This can happen when an upstream service is slow, a domain does not expose the relevant protocol, or the target blocks a specific type of read-only request.

Most scans finish within the configured pipeline ceiling. If a scan remains in running longer than expected, the background cleanup job can mark stale scans so they do not block future activity.

Common causes include temporary DNS failures, target timeouts, upstream intelligence service delays, or network interruptions during result persistence.

Your score can change when DNS records, certificates, headers, exposed ports, cloud storage permissions, detected technologies, or known CVEs change. It can also move when a previously unavailable scanner returns new evidence.

Use scan history to compare findings over time and focus first on new CRITICAL and HIGH severity items.

Yes. You can run a new manual scan after applying a fix. For DNS, TLS, CDN, and email-security changes, wait for propagation before rescanning so public resolvers and certificate sources reflect the update.

Paid monitoring plans also pick up changes automatically on the configured interval.

Start with CRITICAL and HIGH findings, then review chain-analysis results because combined weaknesses often represent the most realistic attack path. After that, fix internet-exposed services, missing email authentication, weak TLS, cloud exposures, and missing security headers.

Each finding includes remediation guidance so engineering teams can move from evidence to action without guessing.

A CDN or WAF reduces exposure but does not automatically fix every security issue. Headers, TLS behavior, cookies, CORS policy, exposed origin hints, subdomain takeover candidates, and application responses can still be visible at the edge.

If the finding references an origin IP or direct service, check that your origin is not reachable outside the CDN path.

Email authentication records help prevent domain spoofing and phishing. Externalsight checks whether SPF, DKIM, and DMARC are present and configured strongly enough to protect the domain from obvious impersonation risk.

If you do not send email from a domain, a restrictive SPF record and DMARC policy can still help prevent abuse of that domain.

Review the evidence shown with the finding first: DNS response, HTTP header, TLS property, exposed URL, service banner, or matched pattern. If your environment intentionally uses that configuration, document the accepted risk internally.

If the evidence looks stale, rescan after propagation or service deployment completes. For support, include the domain, scan timestamp, finding name, and expected behavior.

Yes. Domain management is tied to your authenticated account, and domain limits are enforced by plan. Removing a domain frees capacity for another authorized domain under your current plan.

If monitoring is enabled for that domain, remove or disable monitoring before relying on it for future alerts.

You can export PDF reports for scan results and share them with stakeholders who need remediation context. Reports include score, severity grouping, finding details, and remediation steps.

Because reports can include sensitive information about your attack surface, share them through your organization's approved channels.

Include your account email, the domain, approximate scan time, plan name, browser and operating system if the issue is UI-related, and the exact error or finding name you are asking about.

For scanner questions, include the evidence shown in the result so support can distinguish a product issue from a live configuration change.

Check whether your plan supports email notifications, whether monitoring is enabled, whether the finding severity is included in your plan, and whether quiet hours or the 6-hour rate limit suppressed delivery.

Also confirm your account email is correct and that your mail provider is not filtering security notifications.

Webhooks require a Sentinel or Fortress plan and a reachable HTTPS endpoint. Confirm the URL is saved correctly, the endpoint accepts POST requests, and your integration returns a successful response quickly.

Webhook delivery only occurs when an alert is triggered, so deduplication, quiet hours, severity gating, or no new findings can make it look inactive.

A 429 response means too many requests were made in a short period or a plan quota was reached. This protects scanner capacity, upstream services, and your account from accidental repeated actions.

Wait before retrying, avoid repeated refreshes during scan execution, and check whether a plan-specific limit such as DAST quota has been reached.

No. Externalsight is designed for externally reachable domains and public internet evidence. It does not install internal agents or scan RFC1918 private networks from inside your environment.

For internal security testing, use an internal vulnerability management or authenticated scanning workflow approved by your organization.

After applying the fix and waiting for any required propagation, run a new scan and compare the finding list, score, and evidence against the previous report. The finding should disappear or change to reflect the new public configuration.

For recurring issues, monitoring can confirm that the fix remains in place over time.

Historical reports preserve what Externalsight observed at the time of that scan. Fixing an issue does not rewrite older reports. Run a new scan to generate fresh evidence and confirm the current state.

DNS and certificate changes can also take time to propagate through public resolvers and transparency sources.

Yes. Externalsight is useful before audits because it highlights externally visible gaps such as missing security headers, weak TLS, exposed services, email spoofing risk, cloud exposure, and vulnerable technologies.

It does not replace a full compliance assessment, but it helps teams clean up public-facing evidence before auditors, customers, or attackers review the same surface.

No. Externalsight provides continuous external attack surface visibility and evidence-backed scanner results. A penetration test goes deeper into exploitation, business logic, authentication, and manual attack chains.

Use Externalsight between penetration tests to catch drift, new exposures, and configuration regressions as your public surface changes.