What is the difference between HAR-based discovery and seed paths?

Why This Matters for Security Teams

HAR-based discovery and seed paths solve different coverage problems, and confusing them leads to blind spots in application testing. A HAR file reflects the navigation a real browser made, so it is useful for reproducing authenticated workflows, session-dependent calls, and routes that only appear after user interaction. Seed paths, by contrast, are deliberate inputs used to force testing of endpoints that are known, suspected, or too sensitive to rely on crawling alone. That distinction matters when teams are validating access controls, hidden admin functions, or API surfaces that do not link cleanly from the UI.

Security teams often overestimate crawler coverage and assume that recorded traffic equals complete discovery. Current guidance around NIST Cybersecurity Framework 2.0 emphasises repeatable risk reduction and control verification, which maps well to treating both methods as complementary inputs rather than substitutes. HAR-based discovery is strongest when the goal is realism. Seed paths are strongest when the goal is completeness. In practice, many security teams discover missing endpoints only after an authenticated workflow or a hidden route has already been exercised by an attacker rather than through intentional coverage planning.

How It Works in Practice

HAR-based discovery starts with browser-initiated traffic. A tester records a session, then extracts the request paths, query parameters, and endpoint sequence from the HAR file. This is especially useful in modern apps where JavaScript, redirects, and authentication gates make traditional crawling incomplete. Because the HAR reflects actual behaviour, it can preserve the context needed to reach routes that only exist after login, feature selection, or state changes.

Seed paths work differently. They are manually curated routes, usually supplied as a list of URLs or patterns that the scanner should test regardless of whether it can discover them naturally. Good seed paths often come from source code review, API documentation, threat modelling, earlier incidents, route inventories, or known administrative surfaces. They are useful for:

• forcing coverage of hidden or unlinked endpoints
• testing legacy paths that are not exposed in the main UI
• reaching privileged functions with direct navigation
• validating API routes that a browser would never click to

Operationally, the best approach is to combine both. HAR-based discovery gives the scanner realistic session context, while seed paths compensate for incomplete discovery and architectural shortcuts. This is aligned with broader application security practice and with control thinking in the NIST Cybersecurity Framework 2.0, where asset visibility and validation are part of maintaining a trustworthy security posture. Where route discovery is weak, teams should enrich HAR data with authenticated seed lists, then reconcile the findings against expected application inventory and authorization boundaries.

These controls tend to break down when applications generate routes dynamically per user, tenant, or feature flag because the discovered paths may not be reusable across environments.

Common Variations and Edge Cases

Tighter coverage usually increases test maintenance overhead, requiring organisations to balance realism against completeness. HAR-based discovery is not always the better choice. In highly stateful applications, HAR captures only one path through a workflow and can miss alternate branches. It can also be brittle if tokens expire quickly, if content is personalised, or if the session is dependent on timing, browser state, or device-specific behaviour.

Seed paths also have limits. They can become stale if routes are renamed, removed, or gated behind changing authorization logic. Best practice is evolving around whether seed sets should be manually maintained, generated from API schemas, or derived from production telemetry. There is no universal standard for this yet, so teams should choose the method that best matches their release cadence and route volatility. For API-heavy systems, seed paths often outperform HAR because the browser may never naturally surface machine-to-machine endpoints. For authenticated business applications, HAR often provides better context because it captures real navigation and required headers.

Where possible, teams should validate both against expected security outcomes, not just scan volume. That means checking whether sensitive endpoints are actually tested, whether authentication context is preserved, and whether direct access controls behave as intended. This is particularly important when application routes are hidden behind JavaScript rendering, API gateways, or tenant-specific logic.

Related resources from NHI Mgmt Group

• What is the difference between network detection and identity-based discovery for AI agents?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between secret scanning and non-human identity discovery?