Blogs use a more complex Docker + Burp Suite setup because not all application traffic is generated by a browser. In many Dockerized applications, requests can be made internally by services, background workers, APIs, or even other containers, which bypass the browser proxy entirely. A simple “browser → Burp Suite” setup only captures client-side traffic, but it misses these internal or server-to-server requests. By routing Docker container traffic through Burp Suite and controlling networking at the container level (or via Docker’s network/proxy configuration), security testers can intercept and analyze all HTTP/S traffic flowing in and out of the container environment. This is why advanced blogs often demonstrate full Docker + Burp integration instead of a basic browser proxy setup.

Table of Contents

1. Introduction & Windows Architecture Overview
2. Prerequisites & Tooling
3. Understanding the Windows Docker Networking Stack
4. METHOD 1: Per-Container Proxy via Environment Variables (Simplest)
5. METHOD 2: Docker Desktop Built-in Proxy Configuration
6. METHOD 3: Docker Daemon-Level Proxy (System-wide Interception)
7. METHOD 4: WSL2 Deep-Dive — Intercepting Docker-on-WSL Traffic Through Windows Burp
8. Installing Burp’s CA Certificate in Windows Containers (Nano Server / Windows Server Core)
9. Intercepting Docker Registry Pull/Push Traffic on Windows
10. Windows Firewall Configuration
11. Troubleshooting Matrix — Windows-Specific Issues
12. Complete PoC Walkthrough — Step-by-Step Lab
13. Appendix: PowerShell Automation Scripts

1. Introduction & Windows Architecture Overview

Unlike Linux where Docker runs natively on the host kernel, Docker Desktop on Windows operates inside a lightweight Hyper-V VM (or WSL2 backend). This creates a network boundary between Burp Suite (running as a native Windows application) and Docker containers (running inside that VM). Understanding this topology is critical before attempting traffic interception.

Architecture diagram (conceptual):

┌─────────────────────────────────────────────────────────────┐
│                   WINDOWS HOST                               │
│                                                              │
│  ┌──────────────────┐          ┌──────────────────────┐     │
│  │  Burp Suite       │          │  Browser / curl /    │     │
│  │  (127.0.0.1:8080) │          │  native apps         │     │
│  └────────┬─────────┘          └──────────────────────┘     │
│           │                                                 │
│  ┌────────▼─────────────────────────────────────────┐       │
│  │         host.docker.internal / vEthernet           │       │
│  │         (WSL / Hyper-V Virtual Switch)             │       │
│  └───────────────────────┬──────────────────────────┘       │
│                          │                                   │
├──────────────────────────┼───────────────────────────────────┤
│            ┌─────────────▼──────────────┐                    │
│            │   DOCKER VM / WSL2 VM      │                    │
│            │                            │                    │
│            │  ┌──────────────────────┐  │                    │
│            │  │   Containers         │  │                    │
│            │  │   (Linux/Windows)    │  │                    │
│            │  └──────────────────────┘  │                    │
│            └────────────────────────────┘                    │
└─────────────────────────────────────────────────────────────┘

Key Windows-specific facts:

• host.docker.internal resolves from inside any container to the Windows host IP — this is the magic gateway for Burp.
• There is no docker0 bridge on Windows — don't look for 172.17.0.1.
• Docker Desktop for Windows uses either WSL2 backend (default, recommended) or Hyper-V backend.
• Windows Firewall blocks inbound connections by default — you must add a rule for Burp.

2. Prerequisites & Tooling

Verify your Docker backend:

# Open PowerShell as Administrator
docker version
# Look for "OS/Arch: windows/amd64" for the client
# For the server, check if it says "linux/amd64" (WSL2) or "windows/amd64" (Hyper-V)

Check WSL2 mode:

wsl -l -v
# Make sure your Docker-desktop distribution shows "Running" and version "2"

3. Understanding the Windows Docker Networking Stack

This is the most misunderstood aspect. Here’s what you need to know:

The host.docker.internal DNS Record

Docker Desktop automatically adds a DNS entry in every container that resolves to the Windows host’s IP address:

# From inside any Linux container on Docker Desktop Windows
ping host.docker.internal
# PINGS 192.168.x.x (the Windows host's vEthernet IP)

On Windows containers (not Linux containers — these are rare), host.docker.internal resolves to 10.0.75.1 by default.

The vEthernet (WSL) Adapter

When using WSL2 backend, Docker Desktop creates a virtual switch. Find its IP:

ipconfig
# Look for:
#   Ethernet adapter vEthernet (WSL (Hyper-V firewall)):
#      IPv4 Address. . . . . . . . . . . : 192.168.XX.XX

This IP is what containers see as the gateway to the host. Burp must bind to ALL interfaces (0.0.0.0) so it’s reachable from this virtual adapter.

No docker0 Bridge

On Windows, there is no docker0 bridge device. The Linux bridge networking model doesn't apply. Containers on Docker Desktop Windows are routed through the Hyper-V virtual switch / WSL2 network NAT.

4. METHOD 1: Per-Container Proxy via Environment Variables (Simplest)

This is the quickest way to intercept traffic from a single container. No Docker config changes needed.

Step 1: Configure Burp to Listen on All Interfaces

1. Open Burp Suite → Proxy tab → Options sub-tab
2. Under Proxy Listeners, if the default listener is bound to 127.0.0.1:8080, click Edit
3. Change Bind to address from Loopback only to All interfaces
4. Click OK

Why: Containers cannot reach 127.0.0.1 on the Windows host. They connect through the virtual network adapter, so Burp must listen on 0.0.0.0.

Step 2: Run a Container with Proxy Environment Variables

# Using host.docker.internal (magic DNS name — works on Docker Desktop Windows)
docker run --rm -it `
  -e http_proxy="http://host.docker.internal:8080" `
  -e https_proxy="http://host.docker.internal:8080" `
  -e HTTP_PROXY="http://host.docker.internal:8080" `
  -e HTTPS_PROXY="http://host.docker.internal:8080" `
  -e no_proxy="localhost,127.0.0.1,.local" `
  ubuntu:22.04 bash

Step 3: Install Burp’s CA Certificate Inside the Container

First, export Burp’s CA certificate:

1. In Burp, go to Proxy → Options → Import / Export CA Certificate
2. Click Export → Certificate in DER format → Save as burp.der

Now, from inside the container:

# Inside the container
apt-get update && apt-get install -y ca-certificates curl
# Download the cert from the Windows host
# Option A: Host it on a local web server temporarily
# Option B: Copy via docker cp (from another terminal)

Better approach — mount the cert at runtime:

# On Windows host, convert DER to PEM first
openssl x509 -inform DER -in burp.der -out burp.pem -outform PEM
# Run with cert mounted
docker run --rm -it `
  -v C:\Users\%USERNAME%\Desktop\burp.pem:/usr/local/share/ca-certificates/burp.crt `
  -e http_proxy="http://host.docker.internal:8080" `
  -e https_proxy="http://host.docker.internal:8080" `
  ubuntu:22.04 bash -c "apt-get update && apt-get install -y ca-certificates && update-ca-certificates && curl -v https://github.com"

Step 4: Verify Interception

Set Burp’s Proxy → Intercept to Intercept is on, then from the container:

curl -v https://api.github.com/zen

The request pauses in Burp. Click Forward to release it)Skip

PoC: Docker Compose on Windows

# docker-compose.yml
version: '3.8'
services:
  intercepted-app:
    image: node:18-alpine
    environment:
      - http_proxy=http://host.docker.internal:8080
      - https_proxy=http://host.docker.internal:8080
      - HTTP_PROXY=http://host.docker.internal:8080
      - HTTPS_PROXY=http://host.docker.internal:8080
      - no_proxy=localhost,127.0.0.1
    volumes:
      - ./app:/app:ro
    working_dir: /app
    command: node app.js

# Run
docker-compose up
# The Node.js app's outbound HTTP/HTTPS calls appear in Burp

5. METHOD 2: Docker Desktop Built-in Proxy Configuration

Docker Desktop for Windows has a native proxy settings UI. This automatically propagates proxy env vars to all containers started through Docker Desktop.

Step 1: Configure Docker Desktop Proxy

1. Open Docker Desktop → click the gear icon (Settings)
2. Navigate to Resources → Proxies
3. Toggle Manual proxy configuration to ON
4. Enter:

• HTTP proxy: http://host.docker.internal:8080
• HTTPS proxy: http://host.docker.internal:8080
• No proxy: localhost,127.0.0.1,.local,.internal

5. Click Apply & Restart

Step 2: Every Container Now Uses the Proxy

No -e flags needed anymore:

docker run --rm alpine:latest wget -qO- https://google.com
# ^^^ This goes through Burp automatically

Step 3: Install CA Certificate

You still need to install Burp’s CA in each image you test. The easiest way on Windows:

Create a base image with Burp’s CA pre-installed:

# Dockerfile.burp-base
FROM alpine:latest
COPY burp.pem /usr/local/share/ca-certificates/burp.crt
RUN apk add --no-cache ca-certificates && update-ca-certificates

docker build -t burp-base -f Dockerfile.burp-base .

Then use burp-base as your base for any container you want to intercept.

Step 4: Verify the Proxy is Active

# Check Docker Desktop proxy settings from CLI
docker info | Select-String -Pattern "Proxy"

6. METHOD 3: Docker Daemon-Level Proxy (System-wide Interception)

This targets the Docker daemon itself — intercepting docker pull, docker push, and all container traffic at the engine level.

Step 1: Configure Docker Daemon Proxy on Windows

On Windows, Docker daemon config lives at %ProgramData%\Docker\config\daemon.json:

{
  "proxy": {
    "http-proxy": "http://host.docker.internal:8080",
    "https-proxy": "http://host.docker.internal:8080",
    "no-proxy": "localhost,127.0.0.1,.local,.internal"
  }
}

If the file doesn’t exist, create it.

Step 2: Restart Docker Desktop

# Restart via tray icon or:
Restart-Service docker

Step 3: Verify Daemon Proxy

docker info
# Look for:
# HTTP Proxy: http://host.docker.internal:8080
# HTTPS Proxy: http://host.docker.internal:8080
# No Proxy: localhost,127.0.0.1,.local,.internal

Step 4: Intercept Docker Pull Traffic

Now when you run docker pull:

docker pull alpine:latest

In Burp’s HTTP history, you’ll see requests to:

• https://auth.docker.io/token?... (authentication token)
• https://registry-1.docker.io/v2/library/alpine/manifests/latest (manifest)
• https://registry-1.docker.io/v2/library/alpine/blobs/sha256:... (layer blobs)

7. METHOD 4: WSL2 Deep-Dive — Intercepting Docker-on-WSL Traffic Through Windows Burp

If you run Docker inside a WSL2 distribution (e.g., Kali Linux in WSL2 with Docker installed natively), the networking is more complex. Here’s the complete setup.

Architecture

┌──────────────────────────────────────────────────────┐
│                  WINDOWS HOST                         │
│  ┌──────────────────────────────────────────────┐    │
│  │  Burp Suite (0.0.0.0:8081)                    │    │
│  └──────────▲───────────────────────────────────┘    │
│             │                                        │
│  ┌──────────┴───────────────────────────────────┐    │
│  │  vEthernet (WSL) 192.168.X.X                  │    │
│  └──────────────────┬───────────────────────────┘    │
├─────────────────────┼────────────────────────────────┤
│  ┌──────────────────▼───────────────────────────┐    │
│  │  WSL2 VM                                     │    │
│  │  ┌───────────────────────────────────────┐    │    │
│  │  │  Kali/WSL eth0 172.X.X.X               │    │    │
│  │  │  ┌─────────────────────────────────┐   │    │    │
│  │  │  │  mitmproxy port 8080            │   │    │    │
│  │  │  │  (port-forwarded from WSL→Win)  │   │    │    │
│  │  │  └──────────▲──────────────────────┘   │    │    │
│  │  │             │                          │    │    │
│  │  │  ┌──────────┴──────────────────────┐   │    │    │
│  │  │  │  Docker containers in WSL       │   │    │    │
│  │  │  └─────────────────────────────────┘   │    │    │
│  │  └───────────────────────────────────────┘    │    │
│  └──────────────────────────────────────────────┘    │
└──────────────────────────────────────────────────────┘

Step 1: Install mitmproxy in WSL

# Inside your WSL distribution (Kali/Ubuntu)
sudo apt update && sudo apt install -y mitmproxy python3-pip

Step 2: Set Up Port Forwarding from WSL2 to Windows

Save this as C:\Scripts\wsl2-portforward.ps1:

# wsl2-portforward.ps1
# Run as Administrator
$wslIp = bash.exe -c "ip addr show eth0 | grep -oP 'inet \K[\d.]+'"
$ports = @(8080)  # mitmproxy port inside WSL
# Remove old firewall rules
Remove-NetFireWallRule -DisplayName 'WSL2 Burp Proxy' -ErrorAction SilentlyContinue
# Add new firewall rule
New-NetFireWallRule -DisplayName 'WSL2 Burp Proxy' `
  -Direction Inbound -LocalPort $ports -Action Allow -Protocol TCP
# Remove old portproxy rules
foreach ($port in $ports) {
    netsh interface portproxy delete v4tov4 listenport=$port listenaddress=0.0.0.0 | Out-Null
    netsh interface portproxy add v4tov4 `
      listenport=$port `
      listenaddress=0.0.0.0 `
      connectport=$port `
      connectaddress=$wslIp
}
Write-Host "[+] WSL2 IP: $wslIp"
Write-Host "[+] Ports forwarded: $($ports -join ',')"
Write-Host "[+] Firewall rule added"

Run it:

# PowerShell as Administrator
Set-ExecutionPolicy Bypass -Scope Process
.\wsl2-portforward.ps1

Step 3: Start mitmproxy in WSL

# In WSL terminal
mitmproxy --listen-port 8080 --set block_global=false

Step 4: Configure Burp with an Upstream Proxy

1. In Burp Suite, go to User Options → Connections
2. Under Upstream Proxy Servers, click Add
3. Set:

• Destination host: * (wildcard — all traffic)
• Proxy host: 127.0.0.1
• Proxy port: 8080 (this is the forwarded mitmproxy port)

4. Click OK

Step 5: Configure Burp’s Proxy Listener

1. Proxy → Options → Proxy Listeners
2. Add a listener on 0.0.0.0:8081
3. This is the port you’ll point your Windows browser to

Step 6: Install CA Certificates

• In WSL: mitmproxy’s CA is at ~/.mitmproxy/mitmproxy-ca-cert.pem
• Install mitmproxy CA on Windows as a trusted root
• Install Burp’s CA on Windows as a trusted root (see below`

Chain summary:

Browser → Burp (127.0.0.1:8081) → mitmproxy (127.0.0.1:8080 forwarded from WSL) → Docker containers inside WSL

8. Installing Burp’s CA Certificate in Windows Containers (Nano Server / Windows Server Core)

Windows containers (not Linux containers) run a full Windows kernel. Installing a CA in them is different.

For Windows Server Core Containers

# Dockerfile.windows-intercept
FROM mcr.microsoft.com/windows/servercore:ltsc2022
# Copy Burp certificate (PEM format)
COPY burp.pem C:\burp-ca.crt
# Install into Windows certificate store
RUN certutil -addstore -f Root C:\burp-ca.crt
# Set proxy environment variables
ENV http_proxy=http://host.docker.internal:8080
ENV https_proxy=http://host.docker.internal:8080

docker build -t intercepted-windows -f Dockerfile.windows-intercept .
docker run --rm intercepted-windows powershell Invoke-WebRequest -Uri https://example.com

For Nano Server Containers

FROM mcr.microsoft.com/windows/nanoserver:ltsc2022
COPY burp.pem C:\burp-ca.crt
RUN certoc.exe -addstore Root C:\burp-ca.crt

Note: Windows containers are limited to the same OS build as the host. Use mcr.microsoft.com/windows images matching your Windows build number.

9. Intercepting Docker Registry Pull/Push Traffic on Windows

When you configure the Docker daemon proxy (Method 3), docker pull and docker push traffic flows through Burp.

What You’ll See in Burp’s HTTP History

PoC: Intercept and Modify a Docker Pull

# In Burp: Intercept is ON
# In PowerShell:
docker pull alpine:latest
# Burp catches the manifest request - you can see:
# GET /v2/library/alpine/manifests/latest HTTP/1.1
# Host: registry-1.docker.io
# Accept: application/vnd.docker.distribution.manifest.v2+json
# Authorization: Bearer <token>
# Forward it - the blob requests will also appear

10. Windows Firewall Configuration

Windows Defender Firewall blocks inbound connections to Burp by default. You must create an allow rule.

Automated (PowerShell)

# PowerShell as Administrator
New-NetFirewallRule -DisplayName "Burp Suite Proxy" `
  -Direction Inbound `
  -LocalPort 8080,8081 `
  -Action Allow `
  -Protocol TCP `
  -Profile Any

Manual (GUI)

1. Open Windows Defender Firewall with Advanced Security
2. Click Inbound Rules → New Rule
3. Rule Type: Port
4. Protocol: TCP, Specific local ports: 8080,8081
5. Action: Allow the connection
6. Profile: Tick all three (Domain, Private, Public)
7. Name: Burp Suite Proxy
8. Click Finish

11. Troubleshooting Matrix — Windows-Specific Issues

Diagnostic Commands

# Test Burp is reachable from the host
curl -x http://127.0.0.1:8080 http://httpbin.org/get
# Test Burp is reachable from a container
docker run --rm alpine:latest wget -qO- http://host.docker.internal:8080
# Check Docker proxy settings
docker info | Select-String -Pattern "Proxy|proxy"
# Verify portproxy rules (WSL2 method)
netsh interface portproxy show all
# Check Docker Desktop proxy UI is active
# Settings → Resources → Proxies should show your values
# Reset Docker proxy to default
# Remove or empty the "proxy" key in %ProgramData%\Docker\config\daemon.json
# Reset Docker Desktop proxy UI to "No proxy"

12. Complete PoC Walkthrough — Step-by-Step Lab

Here’s a full end-to-end lab you can run on a clean Windows machine with Docker Desktop.

Lab Goal

Intercept all outbound HTTPS traffic from an ubuntu:22.04 container making API calls.

Step 1: Export Burp CA

1. Open Burp Suite → Proxy → Options → Import/Export CA Certificate
2. Click Export → Certificate in DER format
3. Save to C:\burp-lab\burp.der

Step 2: Convert to PEM

# Using OpenSSL for Windows
openssl x509 -inform DER -in C:\burp-lab\burp.der -out C:\burp-lab\burp.pem -outform PEM

Step 3: Configure Burp Listener

Burp → Proxy → Options → Proxy Listeners:

• Default listener: Edit → change to All interfaces
• Add secondary listener: 0.0.0.0:8081 (for WSL scenarios)

Step 4: Configure Windows Firewall

New-NetFireWallRule -DisplayName "Burp Lab" -Direction Inbound -LocalPort 8080 -Action Allow -Protocol TCP

Step 5: Create a PoC Container with a Custom Dockerfile

# C:\burp-lab\Dockerfile
FROM ubuntu:22.04
# Install Burp CA
COPY burp.pem /usr/local/share/ca-certificates/burp.crt
RUN apt-get update && \
    apt-get install -y ca-certificates curl dnsutils && \
    update-ca-certificates && \
    rm -rf /var/lib/apt/lists/*
# Proxy env vars
ENV http_proxy=http://host.docker.internal:8080
ENV https_proxy=http://host.docker.internal:8080
ENV HTTP_PROXY=http://host.docker.internal:8080
ENV HTTPS_PROXY=http://host.docker.internal:8080
ENV no_proxy=localhost,127.0.0.1
# Test script
COPY test.sh /test.sh
RUN chmod +x /test.sh
CMD ["/test.sh"]

# C:\burp-lab\test.sh
#!/bin/bash
echo "=== Testing HTTP ==="
curl -v http://httpbin.org/get 2>&1 | head -20
echo "=== Testing HTTPS ==="
curl -v https://api.github.com/zen 2>&1
echo "=== Testing API call ==="
curl -s https://jsonplaceholder.typicode.com/posts/1 | head -100

Step 6: Build and Run

cd C:\burp-lab
docker build -t burp-lab .
docker run --rm burp-lab

Step 7: Observe in Burp

1. Set Burp’s Intercept to ON
2. Watch each request pause in the Proxy → Intercept tab
3. Click Forward to release each one
4. After completion, review all traffic in Proxy → HTTP history

Step 8: Modify a Request in Flight (The “Killer Feature”)

1. With Intercept ON, run the container again
2. When the jsonplaceholder.typicode.com request appears:

• Modify the URL from /posts/1 to /posts/2
• Or modify the Accept header
• Or change GET to POST and inject a body

3. Click Forward to send the modified request

4. The container receives the modified response

13. Appendix: PowerShell Automation Scripts

Script 1: One-Click Burp + Docker Intercept Setup

Save as C:\Scripts\setup-burp-docker.ps1:

# setup-burp-docker.ps1
# Run as Administrator
param(
    [int]$BurpPort = 8080,
    [string]$BurpCertPath = "$env:USERPROFILE\Desktop\burp.der"
)
Write-Host "[*] Setting up Burp + Docker interception on Windows" -ForegroundColor Cyan
# 1. Firewall rule
Write-Host "[*] Adding Windows Firewall rule for port $BurpPort..."
Remove-NetFireWallRule -DisplayName "Burp Suite Docker Proxy" -ErrorAction SilentlyContinue
New-NetFireWallRule -DisplayName "Burp Suite Docker Proxy" `
  -Direction Inbound -LocalPort $BurpPort -Action Allow -Protocol TCP
# 2. Convert DER to PEM if needed
$pemPath = $BurpCertPath -replace '\.der$', '.pem'
if (Test-Path $BurpCertPath) {
    Write-Host "[*] Converting DER to PEM..."
    openssl x509 -inform DER -in $BurpCertPath -out $pemPath -outform PEM
    Write-Host "[+] PEM saved to: $pemPath"
}
# 3. Docker Desktop proxy config (via daemon.json)
$daemonPath = "$env:ProgramData\Docker\config\daemon.json"
$config = @{
    proxy = @{
        "http-proxy" = "http://host.docker.internal:$BurpPort"
        "https-proxy" = "http://host.docker.internal:$BurpPort"
        "no-proxy" = "localhost,127.0.0.1,.local,.internal"
    }
}
if (Test-Path $daemonPath) {
    $existing = Get-Content $daemonPath -Raw | ConvertFrom-Json
    $existing | Add-Member -Force -NotePropertyMembers @{proxy = $config.proxy}
    $existing | ConvertTo-Json -Depth 10 | Set-Content $daemonPath
} else {
    $config | ConvertTo-Json | Set-Content $daemonPath
}
Write-Host "[+] daemon.json updated at: $daemonPath"
# 4. Create test Dockerfile
$testDir = "$env:TEMP\burp-docker-test"
New-Item -ItemType Directory -Force -Path $testDir | Out-Null
@"
FROM ubuntu:22.04
COPY burp.pem /usr/local/share/ca-certificates/burp.crt
RUN apt-get update && apt-get install -y ca-certificates curl && update-ca-certificates
ENV http_proxy=http://host.docker.internal:$BurpPort
ENV https_proxy=http://host.docker.internal:$BurpPort
ENV HTTP_PROXY=http://host.docker.internal:$BurpPort
ENV HTTPS_PROXY=http://host.docker.internal:$BurpPort
ENV no_proxy=localhost,127.0.0.1
CMD curl -v https://api.github.com/zen
"@ | Out-File -FilePath "$testDir\Dockerfile" -Encoding ascii
if (Test-Path $pemPath) {
    Copy-Item $pemPath "$testDir\burp.pem"
}
Write-Host @"
[+] Setup complete!
Next steps:
1. Ensure Burp is listening on ALL interfaces (0.0.0.0:$BurpPort)
2. Restart Docker Desktop to pick up proxy changes
3. Build the test container:
   cd $testDir
   docker build -t burp-test .
   docker run --rm burp-test
4. Watch traffic appear in Burp's HTTP history
Verification:
- Firewall rule: netsh advfirewall firewall show rule name='Burp Suite Docker Proxy'
- Docker proxy: docker info | Select-String Proxy
"@ -ForegroundColor Green

Script 2: WSL2 Port Forward on Boot (Scheduled Task)

# Create a Scheduled Task that runs on logon
$action = New-ScheduledTaskAction -Execute "PowerShell.exe" `
  -Argument "-WindowStyle Hidden -ExecutionPolicy Bypass -File C:\Scripts\wsl2-portforward.ps1"
$trigger = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
$principal = New-ScheduledTaskPrincipal -UserId $env:USERNAME -RunLevel Highest
Register-ScheduledTask -TaskName "WSL2-Burp-PortForward" `
  -Action $action `
  -Trigger $trigger `
  -Settings $settings `
  -Principal $principal `
  -Description "Forwards WSL2 port 8080 to Windows host for Burp Suite interception"

Quick Reference Card

❓ If I open a Docker web app in browser, is browser proxy enough to capture traffic?

Yes ✅
Browser → Burp Suite → Docker app
This is enough for basic testing.

❓ Then why do blogs use complex Docker + Burp setup?

Because not all traffic comes from the browser. Some requests are made directly by the container.

❓ When is browser proxy enough?

When you manually use the website in a browser (manual testing like login, forms, XSS, etc.).

❓ When do you need Docker proxy setup?

When the container itself sends requests, such as:

backend API calls

microservices communication

CLI tools inside container

external HTTP requests (curl, requests, etc.)

❓ Simple difference?

Browser proxy = captures what you click in browser

Docker proxy = captures what container sends automatically

GitHub: SecurityTalent | Medium: Security Talent | Twitter: Securi3yTalent

#BugBounty #WebSecurity #EthicalHacking #Hinglish #InfoSec #securityTalent #CyberSecurity #BurpSuite #Docker #WindowsSecurity #PenetrationTesting #MITM #ProxyInterception #DockerDesktop #WSL2 #Infosec #WebApplicationSecurity #AppSec #RedTeam #EthicalHacking #APIsecurity #PowerShell