Quick answer: Attack surface discovery is the work of systematically mapping every internet facing asset an organization owns: subdomains, undocumented API endpoints, the endpoints and parameters buried inside JavaScript bundles, and single page application routes. The real attack surface of a modern web application reaches far beyond its main domain and often does not even appear in the organization's own inventory. AI assisted automation deepens this discovery, because it pivots through certificate and DNS records, follows the JavaScript chunk graph, and captures XHR requests from live network traffic. The decisive principle is this: every discovered asset is a lead, not proof. A found API endpoint may not be live, reachable, or vulnerable, so discovery output is tested through authorized and controlled verification. Discovery always stays inside scope, and no active attack is run against third party or CDN hosts.

An attacker enters through the door that is missing from the defender's map. The outcome of a penetration test or red team engagement is often decided not at the moment of exploitation, but long before it, during discovery. A subdomain the team cannot see, a forgotten staging environment, or an admin endpoint that exists only inside JavaScript can render the rest of a security budget meaningless. Attack Surface Management (ASM) exists precisely to close that blind spot.

This article covers the sources and methods for mapping the real attack surface of a modern web application. Our focus is four layers: subdomain enumeration, hidden API endpoints, JavaScript bundle mining, and single page application routes. We also examine how AI accelerates and deepens the process. Let us be honest from the start: automation increases the volume and speed of discovery, but it does not by itself guarantee the certainty of the result.

Why the real attack surface is bigger than it looks

The attack surface is the sum of all the contact points where an attacker could try to enter a system or exfiltrate data. Most organizations picture this surface as just the main website, yet the real picture is far wider. A campaign subdomain spun up by marketing, a server a developer stood up for testing and forgot, legacy infrastructure inherited from an acquisition, the backend APIs a mobile app talks to. All of these are part of the surface, and none of them appear on the home page.

Passive information gathering extracts the first layer of this map without sending a single packet to the target. As we describe in our OSINT reconnaissance and passive information gathering article, certificate records, search engine results, and web archives are data that already sits in the open. The techniques in our passive reconnaissance with Google dorking and Shodan guide expose indexed panels and exposed services without touching the target. The next step of discovery is to combine these passive leads with active verification and turn them into a list of live assets.

Discovery source, what it finds

The table below summarizes the main sources of attack surface discovery, whether each is passive or active, what kind of asset it produces, and its limit. The most important column is the last one: every source produces a candidate, not a confirmed finding.

Discovery source Passive / Active What it finds Limit and caveat
Certificate transparency (CT logs) Passive Subdomains, certificate SAN entries May be a historical record, liveness check required
Passive DNS and aggregator services Passive Old and active subdomains, record types Data may be stale
Search engine, dorks, and web archive Passive Indexed pages, old endpoints, leaked files Deleted content may still be listed
DNS brute force and permutation Active Hidden subdomains not in any wordlist Generates traffic, wildcard false positives
JavaScript bundle analysis Active, low noise API endpoints, parameters, internal host names Endpoint may be dead code or unreachable
Chunk graph and lazy route following Active, low noise Routes and panels loaded only for certain roles Finding a route does not mean access
Live network XHR and fetch capture Active Real endpoints triggered at runtime Anything behind authentication may be hidden
Port and service scanning Active Open ports, services, version banners A version fingerprint is a hypothesis

The rhythm of the table teaches a lesson on its own: passive sources offer a rich starting list without taking risks, while active sources confirm and deepen that list. The two do not replace each other, they run in sequence.

Subdomain enumeration: certificate and DNS pivoting

Subdomain enumeration is the work of surfacing every name record tied to a root domain. The most productive passive source is certificate transparency logs. Because every TLS certificate is recorded in a public ledger, the SAN (subject alternative name) fields of certificates issued to an organization often reveal subdomains never advertised to the outside, such as vpn, test, payment, or internal. Passive DNS services, in turn, store previously resolved names, letting you see old systems that have since been removed but may still be reachable.

Pivoting is where discovery truly deepens. A certificate's SAN list leads to new domains, a domain's IP address leads to neighboring sites on the same host, and a CNAME chain leads to the real origin at a cloud provider. AI assisted automation speeds up two tasks here: it generates candidate names through permutation and resolves them in bulk, then clusters the meaningful ones. Even so, the honest limit must not be forgotten. A subdomain that resolves does not automatically mean it is live, in scope, or yours. A wildcard DNS configuration can resolve any random name and create a false sense of abundance. An abandoned CNAME record can point to a possible subdomain takeover, but that is a possibility, not proof. Turning the claim into evidence requires authorized and controlled verification.

JavaScript bundle mining: chunk graph and live XHR

Modern web applications carry most of their logic inside the JavaScript bundles sent to the browser. These bundles are the richest yet least examined mine in attack surface discovery. A bundle contains API calls, the parameters an endpoint expects, internal host names, feature flags, and sometimes, through a bad habit, embedded keys. Most of these endpoints are absent from the official API documentation. Endpoints that do not appear in the official inventory are called shadow APIs, and our shadow API discovery and inventory security article explores this topic in detail.

The real depth hides in the chunk graph. Bundlers split code into chunks that load only when needed. The code for an admin panel screen never reaches the screen until you enter that role, but the name and path of that chunk are written into the main bundle's chunk map. By following this map and recursively resolving the chunks, it is possible to map routes and endpoints that could never be seen without logging in. Source maps left exposed in production by mistake go even further, reversing the minification to reveal the original file tree and even the comments.

For endpoints that static analysis cannot see, live network capture steps in. A headless browser drives the application while every XHR and fetch request it produces is recorded, so endpoints that fire only on a button click or inside a specific flow are also captured. The static and live methods complement each other. The limit here is equally clear: seeing an endpoint string inside a bundle does not show that the endpoint is live, reachable, or vulnerable. The string may be dead code, it may sit behind a closed feature flag, it may require authentication, or it may belong to a third party. Discovery draws a map, it does not claim that every door on that map is open.

The difference between passive and active discovery

Passive discovery builds a map from third party data without ever touching the target. Active discovery sends requests directly to the target to verify and complete that map. The balance between the two is both an ethical and a technical decision.

Dimension Passive discovery Active discovery
Contact with target None, compiled from third party data Yes, requests go directly to the target
Trace and logging Invisible in target logs Visible in target logs
Freshness May be stale Immediate and current
Coverage May stay incomplete More complete
Authorization needed Low Scope and written authorization required

The right approach is to build a wide, risk free base through passive discovery, then turn that base into live assets through active discovery within the limits of authorization. The passive stage must never be skipped, because the most critical findings often hide in old certificate records and archived pages.

The coverage principle and the asset boundary

Attack surface discovery has a compass that points in two directions. The first is the coverage principle: every subdomain and every page must be scanned, with no corner left unexamined. An attacker looks for the weakest link, so if discovery focuses only on the main application and skips dozens of secondary assets, the most critical flaw may sit exactly in the one that was skipped. This is why multi agent automation matters. As we explain in our autonomous penetration testing agents and multi agent swarm article, every discovered subdomain can trigger its own discovery and testing flow, so the whole surface is processed simultaneously and consistently. Discovery output then feeds the scanning layer described in our the difference between AI assisted vulnerability scanning and a traditional scanner article. To map open ports and services on discovered live hosts, the network reconnaissance and port scanning with Nmap step comes into play.

The second direction is the asset boundary, and it is as binding as the coverage principle. A web application talks to many hosts that are not yours: font servers, analytics services, payment providers, content delivery networks (CDNs). These third party hosts are noted in the inventory during discovery, because they belong on the map of the attack surface, but no active attack or vulnerability test is run against them. Only passive reconnaissance applies. Authorization and scope cover only the assets under your control. Testing a CDN endpoint means touching someone else's infrastructure without permission, which is both an ethical and a legal violation. A good discovery engine centers on the target domain and automatically drops third party hosts into observation only mode.

The KAOS and DSET approach

KAOS, DSET's local artificial intelligence engine, maps the attack surface first when it assesses a target: it collects subdomains through certificate and DNS pivoting, resolves JavaScript bundles and the chunk graph, captures XHR requests from live network traffic, and adds every asset it finds to the discovery list. In the multi agent flow, each subdomain triggers its own backend and vulnerability review, so the coverage principle is applied in practice. For more on KAOS, see our KAOS AI cyber security scanning tool page.

Here the principle at the backbone of this content cluster bears repeating: detection is not proof. KAOS does not declare an endpoint found in JavaScript or a resolved subdomain to be a vulnerability on its own. These findings are marked as candidate assets, then their liveness and reachability are confirmed in a controlled way. The engine carries an over claim brake: it does not report a discovery signal as a confirmed vulnerability, because a scanner finding is a hypothesis and verification is required. Third party and CDN hosts are automatically placed in observation only mode and kept out of active testing, so authorization and scope are preserved. The goal is to see the whole attack surface, but to speak only about authorized assets and only on the basis of evidence.

Frequently asked questions

What is the difference between attack surface discovery and vulnerability scanning? Attack surface discovery is the stage of finding and mapping all of an organization's internet facing assets: subdomains, API endpoints, routes inside JavaScript, and open services. Vulnerability scanning is the stage of searching those mapped assets for known flaws. Discovery asks which doors exist, while scanning tests whether those doors are locked. If discovery is incomplete, scanning stays incomplete too, because an asset that is never seen cannot be tested. They are consecutive but separate steps, and good discovery defines the scope of the scan.

Is an API endpoint found inside a JavaScript bundle a confirmed security flaw? No. Seeing an endpoint string inside JavaScript does not prove that the endpoint is live, reachable, or vulnerable. The string may be unused dead code, it may sit behind a closed feature flag, it may require strong authentication, or it may belong to a third party outside your scope. The finding is a valuable lead and it enters the test list, but it can only be reported as a security flaw after authorized and controlled verification. This distinction between detection and proof is the foundation of a responsible discovery process.

How are third party and CDN hosts handled during discovery? Third party and CDN hosts are recorded in the inventory during discovery, because they are part of the application's attack surface and show what you depend on. However, no active attack or vulnerability test is applied to these hosts, only passive observation. The reason is both legal and ethical: touching someone else's infrastructure without authorization is a scope violation. The correct approach is to apply authorization only to assets under your own control and to list external dependencies for visibility alone.

Sources

To map your organization's real attack surface completely, from subdomains to JavaScript bundles, to verify discovery findings on an evidence based footing, and to keep scope boundaries intact, contact DSET. Our team provides end to end support for your attack surface management and asset discovery processes from the Ankara Hacettepe Teknokent center.