Post cover image

August 26, 2026

🔥 unhar | Extract JavaScript & HTML from HAR Files + Auto-Fetch Source Maps

Modern web applications are increasingly difficult to analyze from a single page.

By Pentester Club

7 min read

JavaScript may be loaded dynamically, split into dozens or hundreds of chunks, delivered through CDNs, triggered only after user interaction, or hidden behind different application routes.

For security researchers and bug bounty hunters, this creates a practical problem:

None

How do you turn captured browser traffic into a clean, structured collection of JavaScript and HTML that can be analyzed locally?

This is where unhar becomes interesting.

unhar — GitHub Repository

According to its available documentation and recent project descriptions, unhar processes .har files, extracts unique JavaScript and HTML resources, preserves URL structure, attempts to retrieve available source maps, beautifies JavaScript, and extracts inline scripts from HTML. (TG.ME)

🌐 What Is a HAR File?

HAR stands for HTTP Archive.

A HAR file records browser network activity and can contain information about requests and responses generated while visiting a website.

Conceptually:

Browser
   │
   ├── HTML
   ├── JavaScript
   ├── CSS
   ├── Images
   ├── API Requests
   └── Other Resources
          │
          ▼
       HAR File

Instead of manually downloading every resource, you can preserve the browser session's network activity and process it later.

This is particularly useful when applications dynamically load resources after navigation or user interaction.

🔎 Why JavaScript Reconnaissance Matters

JavaScript frequently contains valuable information about an application's architecture.

For authorized security testing, researchers may discover:

  • API endpoints
  • Route names
  • Client-side configuration
  • Feature flags
  • Authentication flows
  • Third-party integrations
  • JavaScript modules
  • Hidden application functionality
  • References to backend services

This doesn't mean that finding an endpoint automatically means finding a vulnerability.

Instead, JavaScript analysis helps answer:

"What functionality does this application expose?"

🧩 The Problem With Modern Web Applications

A simple website might have:

index.html
 ├── app.js
 └── style.css

A modern application could instead look like:

index.html
 │
 ├── runtime.js
 ├── main.js
 ├── vendor.js
 ├── chunk-001.js
 ├── chunk-002.js
 ├── chunk-003.js
 ├── lazy-module.js
 └── CDN resources

And some resources may only appear after:

Login
   ↓
Dashboard
   ↓
User Interaction
   ↓
API Request
   ↓
Lazy-loaded JavaScript

That's why capturing browser traffic can be much more effective than simply downloading the initial HTML.

🔥 unhar: HAR → Web Assets

The core idea behind unhar can be summarized as:

📦 HAR File
    ↓
🔎 Parse Requests
    ↓
📄 Extract HTML
    ↓
📜 Extract JavaScript
    ↓
🗺️ Find Source Maps
    ↓
⬇️ Fetch Available Maps
    ↓
✨ Beautify JavaScript
    ↓
🔬 Local Analysis

The project is therefore useful as a bridge between browser traffic collection and local application-security research. (TG.ME)

🛠️ Installation

The repository's documented workflow can be started with:

git clone https://github.com/Spix0r/unhar
cd unhar

The project can then be run with Python 3.

For example:

python3 unhar.py site.har --output folder

The documented options also include switches to disable source-map fetching or JavaScript beautification. (TG.ME)

📂 Custom Output Directory

A useful feature is the ability to specify where extracted resources should be stored.

python3 unhar.py site.har --output extracted

Conceptually:

extracted/
│
├── html/
├── js/
├── maps/
└── ...

The exact output organization depends on the tool's processing behavior and the contents of the HAR file.

Keeping extracted resources in a dedicated directory makes subsequent analysis much easier.

🗺️ Source Maps: The Really Interesting Part

One of the most useful features is source-map handling.

Modern JavaScript is often bundled and minified:

Original Code
     ↓
Bundler
     ↓
Minifier
     ↓
Production JavaScript

The resulting file might be difficult to read:

(()=>{const e=t=>{...};/*...*/})();

But a source map can provide mappings between generated code and the original source structure.

Conceptually:

app.min.js
     │
     ▼
app.min.js.map
     │
     ▼
Original Sources
     │
     ├── components/
     ├── services/
     ├── routes/
     └── utilities/

Source maps are primarily intended for debugging, but if accidentally exposed in production, they can reveal portions of an application's original source structure. Security guidance for modern build systems commonly warns against publicly deploying source maps when they expose source code. (rsbuild.rs)

🔬 Why Source Maps Matter to Security Researchers

Suppose an application exposes:

https://example.com/assets/app.abc123.js

The production bundle may be heavily minified.

A corresponding source map could potentially reveal information such as:

src/
├── components/
├── services/
├── api/
├── auth/
├── utils/
└── pages/

This can dramatically improve code comprehension during an authorized assessment.

It may help researchers understand:

  • Application architecture
  • Client-side routes
  • API integrations
  • Framework structure
  • Module names
  • Debugging information
  • Source file organization

Again, source exposure isn't automatically a vulnerability. The security impact depends on what information is actually disclosed and whether that information creates meaningful risk.

✨ JavaScript Beautification

Minified JavaScript is optimized for browsers, not humans.

Compare:

function authenticate(e){return fetch("/api/login",{method:"POST",body:JSON.stringify(e)})}

with:

function authenticate(credentials) {
    return fetch("/api/login", {
        method: "POST",
        body: JSON.stringify(credentials)
    });
}

The second version is much easier to analyze.

unhar's documented workflow includes JavaScript beautification/unminification as part of processing. (TG.ME)

📄 HTML Extraction

JavaScript isn't the only useful resource.

HTML can contain:

Forms
Script tags
Routes
Metadata
Inline JavaScript
Configuration
Resource references

unhar also extracts HTML resources and inline scripts, providing another source of application context. (TG.ME)

This is especially useful for applications where important JavaScript is embedded directly in HTML.

🧪 A Practical Authorized Workflow

Here's a useful workflow for a lab or in-scope bug bounty target.

Step 1 — Open the target

Use a browser to navigate through the application.

Step 2 — Capture traffic

Open Developer Tools and use the Network panel.

Step 3 — Preserve the session

Enable options such as Preserve log when appropriate.

Step 4 — Exercise application functionality

Visit relevant pages and interact with features.

For example:

Home
 ↓
Login
 ↓
Dashboard
 ↓
Profile
 ↓
Search
 ↓
Settings

Step 5 — Export the traffic as HAR

Save the captured traffic locally.

Step 6 — Process the HAR

python3 unhar.py site.har --output extracted

Step 7 — Analyze the extracted resources

Search through the resulting JavaScript and HTML.

🔍 Why Interaction Is Important

Simply loading the homepage may not capture everything.

Modern applications often use:

Lazy Loading
Code Splitting
Dynamic Imports
SPA Routing
Feature Modules
Authenticated Resources

For example:

Homepage
   │
   ├── app.js
   │
   ▼
Login
   │
   ├── auth.js
   │
   ▼
Dashboard
   │
   ├── dashboard.js
   ├── charts.js
   └── settings.js

The more relevant functionality you exercise during an authorized test, the more representative your HAR becomes.

🚨 Looking for Security-Relevant Information

After extraction, researchers can perform structured searches.

For example:

grep -RniE "api|graphql|oauth|token|admin|debug" extracted/

This should be treated as reconnaissance, not proof of a vulnerability.

For example:

/api/admin

doesn't necessarily mean:

"Admin access is available."

It may simply be a client-side route used by administrators.

Always validate findings against the authorized application.

🔐 Secrets and Client-Side Configuration

JavaScript analysis can also reveal accidentally exposed configuration.

Potential examples include:

API URLs
Public configuration
Feature flags
Third-party service identifiers
Environment information
Debug endpoints

Be careful when handling credentials or secrets.

If you discover a genuine secret during authorized research:

  1. Don't misuse it.
  2. Don't access unrelated systems.
  3. Preserve minimal evidence.
  4. Follow the target's disclosure policy.
  5. Report it responsibly.

🧠 Source Maps Don't Always Exist

It's important to understand that source maps aren't guaranteed.

You may have:

app.js

without:

app.js.map

Or the map may exist but not contain embedded source content.

Some source-map tools can reconstruct source files from map references when the original source URLs remain accessible, but results vary depending on how the application was built and deployed. (GitHub)

Therefore:

Source Map Available
        ↓
Potentially More Source Information

but:

No Source Map
        ↓
Not Automatically a Dead End

The bundled JavaScript itself can still be valuable.

⚙️ Disable Source-Map Fetching

If you don't want unhar to attempt source-map retrieval, the documented option is:

python3 unhar.py site.har --no-srcmap

This can be useful when you only want local extraction and beautification. (TG.ME)

✨ Disable Beautification

You can also skip beautification:

python3 unhar.py site.har --no-beautify

This may be useful when you want to preserve the JavaScript close to its original captured form. (TG.ME)

🧰 Where unhar Fits in a Recon Pipeline

A broader authorized workflow could look like:

🎯 Authorized Target
                       │
                       ▼
                 Browser Recon
                       │
                       ▼
                  Export HAR
                       │
                       ▼
                    unhar
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
       HTML            JS          Maps
         │             │             │
         └─────────────┼─────────────┘
                       ▼
                 Local Analysis
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
          Endpoints           Logic
             │                   │
             └─────────┬─────────┘
                       ▼
                  Validation
                       │
                       ▼
                     Report

This is where the tool becomes particularly useful for bug bounty reconnaissance.

🔎 JavaScript Reconnaissance Ideas

Once resources have been extracted, you can investigate application behavior such as:

API Discovery

Search for strings representing API routes.

Authentication

Identify client-side authentication flows and token-handling logic.

GraphQL

Look for GraphQL endpoints and client configuration.

Feature Flags

Identify functionality enabled or disabled based on configuration.

Third-Party Services

Identify integrations with analytics, payment providers, authentication platforms, and other services.

Source Structure

Use source maps, when legitimately exposed, to understand application organization.

🧩 HAR Files as Security Evidence

HAR files aren't only useful for extraction.

They can also provide valuable evidence during application testing.

A HAR can help preserve:

Request
Response
Headers
URL
Method
Timing
Resource

This can make it easier to reproduce application behavior later.

A professional workflow can therefore be:

HAR
 ↓
Extract
 ↓
Investigate
 ↓
Identify Finding
 ↓
Capture Minimal Evidence
 ↓
Report

🛡️ Defensive Perspective: Protect Your Source Maps

If you're a developer, this tool also demonstrates an important lesson.

Ask:

What does my production deployment expose?

Check whether your deployment publicly exposes:

*.map
Debug bundles
Development configuration
Source directories
Internal comments
Sensitive client configuration

Build systems can provide different source-map configurations, and production deployments should be designed deliberately rather than inheriting development defaults. (rsbuild.rs)

🚨 Common Mistakes During JavaScript Recon

Mistake #1 — Only Checking the Homepage

Important resources may load later.

Mistake #2 — Ignoring Authenticated Pages

Authorized authenticated testing can reveal completely different JavaScript bundles.

Mistake #3 — Assuming Minified Code Is Useless

Minified code can still contain valuable application information.

Mistake #4 — Treating Every Endpoint as Vulnerable

Discovery is not exploitation.

Mistake #5 — Ignoring Source Maps

A source map can significantly improve code comprehension when legitimately accessible.

Mistake #6 — Testing Outside Scope

Always verify that the domains and resources you are analyzing are authorized.

📋 JavaScript Recon Checklist

[ ] Define authorized scope
[ ] Open browser developer tools
[ ] Enable network logging
[ ] Preserve network traffic
[ ] Visit relevant application routes
[ ] Exercise important functionality
[ ] Export HAR
[ ] Process HAR with unhar
[ ] Extract HTML
[ ] Extract JavaScript
[ ] Check source maps
[ ] Beautify JavaScript
[ ] Review API references
[ ] Review authentication logic
[ ] Review client-side configuration
[ ] Validate security findings
[ ] Document evidence

🚀 Final Thoughts

Modern web applications are increasingly JavaScript-heavy.

That makes browser traffic an extremely valuable source of reconnaissance information.

unhar provides a straightforward workflow for turning that traffic into something much easier to analyze:

🌐 Browser
   ↓
📦 HAR
   ↓
🔎 unhar
   ↓
📄 HTML
📜 JavaScript
🗺️ Source Maps
✨ Beautified Code
   ↓
🔬 Security Research

The real value isn't simply extracting files.

It's creating a repeatable bridge between:

Browser Recon → HAR Capture → Asset Extraction → Source-Map Analysis → JavaScript Recon → Security Validation.

For bug bounty hunters, AppSec engineers, penetration testers, and developers auditing their own applications, this can make JavaScript-heavy applications considerably easier to understand.

And from the defensive side, it highlights an equally important lesson:

_🔐 _Anything intentionally or accidentally exposed to the browser should be considered part of your application's attack surface.

Capture. Extract. Understand. Validate. Report. 🔥