Burp history import is a workflow that uses captured traffic exported from Burp Suite to create or enrich an API service definition. It helps teams assess undocumented or fast-changing APIs by relying on observed requests and responses instead of waiting for formal specifications to be written or updated.
Expanded Definition
Burp history import sits at the intersection of API discovery and attack-surface mapping. It takes real request and response data captured in Burp Suite and turns that history into a usable service definition, which is especially valuable when an API is undocumented, partially documented, or changing faster than an internal contract can be maintained.
The term is narrower than general API documentation because it depends on observed traffic rather than a published specification. It is also narrower than full API inventory management because the imported history is usually a starting point for analysis, not a complete source of truth. The practical boundary matters: imported history can reveal endpoints, parameters, and flows that teams forgot to document, but it cannot prove that every code path, role, or edge case has been observed. In guidance-vs-consensus terms, there is broad agreement that traffic-derived discovery improves coverage, but organisations differ on how much confidence they assign to it as a canonical source.
A useful way to think about it is as evidence-driven reconstruction of an API surface, not a replacement for design-time specification.
Examples and Use Cases
Practitioners use Burp history import in a few common ways when the live application is the only reliable source of truth:
- Importing captured browser or mobile-app traffic to map endpoints before a formal OpenAPI document exists.
- Enriching an existing API definition with parameters, methods, and response shapes that were missing from the original spec.
- Comparing observed traffic against expected routes to spot shadow endpoints or legacy versions still in use.
- Building a testable service definition from a real session trace during security testing or regression validation.
- Feeding traffic history into review workflows when multiple teams own different parts of the same API estate.
The main trade-off is coverage versus fidelity. History import is strong at showing what was actually used, but weak at showing what was intended, deprecated, or blocked by access controls. That distinction matters when teams use the imported output to drive testing or governance decisions.
Where APIs evolve quickly, this workflow is often faster than waiting for complete documentation to catch up.
Security Implications
Security value comes from visibility. If teams rely only on static specifications, they may miss undocumented endpoints, stale versions, or request patterns that indicate a wider attack surface than expected. Burp history import can therefore expose the gap between what developers believe is published and what clients are actually calling.
That gap has concrete consequences. Undocumented endpoints may lack the same authentication checks, rate limits, or logging coverage as formal interfaces. Imported history can also expose high-risk request structures, such as sensitive identifiers in URLs, oversized parameters, or unusual error responses that help testers understand how the API behaves under stress.
For NHI management, the same workflow can reveal machine-to-machine calls that are not obvious in application diagrams. If service accounts, tokens, or API keys appear only in observed traffic, teams may discover that access is being exercised by non-human identities that were never formally inventoried. That is often the first clue that service ownership, credential scope, or offboarding logic is incomplete.
The common practitioner observation is that traffic-derived discovery is only trustworthy when it is paired with validation against source code, gateway logs, or an authoritative specification.
Domain and Governance Relevance
Burp history import matters most in API governance because it creates an evidence trail for what an application actually exposes. That helps security, engineering, and platform teams reconcile operational reality with design intent, which is often the difference between a complete review and a partial one.
In identity-heavy environments, especially where service-to-service communication is common, the workflow also helps surface non-human identity dependencies that are easy to overlook. Observed traffic may show which workloads call which APIs, which credentials are reused across paths, and where access patterns have grown beyond the original trust model. That makes the output useful for inventory, ownership, and scope review, not just testing.
The governance question is not whether imported history is useful. It is how much authority to assign it. NHI Management Group recommends treating it as operational evidence that supports assurance work, while keeping a clear distinction between observed usage and approved service definition. That distinction prevents stale traffic from becoming a false source of policy truth.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Imported history can reveal unseen service identities and API callers. |
| Recommendation — Inventory observed service identities and assign an owner to each imported API path. | ||
| CIS Controls v8 | 8 — Audit Log Management | History import relies on captured traffic and benefits from log-backed validation. |
| Recommendation — Correlate imported Burp history with logs to validate coverage and detect gaps. | ||
| NIST CSF 2.0 | ID.AM-01 — Asset Inventory | The workflow supports reconciling actual API assets with documented inventory. |
| PR.AC-1 — Identity and Access Management | Observed requests may expose how non-human identities authenticate to APIs. | |
| Recommendation — Update your asset inventory from observed API traffic and flag undocumented interfaces. Review captured requests for overbroad API access and tighten least-privilege scope. | ||
| MITRE ATT&CK | T1595 — Active Scanning | Imported traffic often comes from recon and testing that map exposed API surfaces. |
| Recommendation — Use imported traffic to enumerate exposed services and prioritize follow-on testing. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
