Security & privacy

PCAPNG Analyzer processes and stores packet captures on the server you control. Capture data and analysis results are not uploaded to us.

What stays on your server

Uploads, decoded packet data, aggregate reports, annotations and exports are handled by your own instance. By default, persistent application data lives under PCAP_DATA_DIR—/data in the container image—including:

• The SQLite analysis database
• Stored capture files in the uploads directory
• Application logs
• Local authentication and configuration data

You control the host, Docker volume, backups, retention and access to that storage. PCAPNG Analyzer does not copy this data to a hosted analysis service.

Sensitive content inside captures

Captures often hold credentials and private data. The analysis is designed not to spread them further:

• LDAP passwords are never stored. A simple bind over plain LDAP is recorded as having sent a password in clear; the password itself is not kept.
• Files carried over HTTP are never opened in the browser. They are listed with their SHA-256 hashes and offered only as downloads, so a malicious page or script in a capture can't run in your session. Decompression is capped at 64 MB per file and 256 MB per capture, so a “zip bomb” in captured traffic can't exhaust the server's memory.
• Incident reports are self-contained. A report loads nothing from the network: no fonts, scripts or images from elsewhere, enforced by a content security policy inside the file.
• Shareable copies are sanitized. The shareable copy of a capture strips payloads and replaces IP and MAC addresses consistently, so you can send it to a vendor without sending your traffic. It works on Ethernet captures only: a capture whose addresses can't be located reliably, such as one taken with tcpdump -i any, is refused rather than half-sanitized.
• API tokens are stored as hashes. A token is shown once, when it's created; only its hash is kept, and it can be revoked at any time.

Captures themselves are stored as uploaded, and following a stream shows what was sent, credentials included. Treat access to the instance like access to the traffic.

Network activity at a glance

The license-status check

A Free instance can run without a license key. When licensing is not configured, the background license-validation task does not run.

If you enter a Pro key, the application contacts the configured Keygen licensing service:

• When the key is first entered
• During periodic revalidation—every 24 hours by default
• When an administrator selects Recheck now

The request contains the license key and a product/version identifier. It does not contain the capture filename, capture contents, decoded packets, report data or user annotations. As with any outbound HTTPS connection, the remote service receives ordinary connection metadata such as the connecting server's IP address.

If the licensing service is temporarily unreachable, a valid Pro instance keeps its entitlements during the configured offline grace period—14 days by default. Operators with restricted egress can route the request through an HTTPS proxy.

The update check

So you hear about new versions, the application asks GitHub once a day for the latest published release:

• One unauthenticated GET https://api.github.com/repos/stumat1/pcapng-analyzer-desktop/releases/latest, identified only as PCAPNG-Analyzer
• No license key, version number, capture data or information about your installation is sent; the application compares the answer with its own version
• A newer version shows a notice to administrators with a link to its release notes. Nothing is downloaded or installed for you

It runs on Free and Pro alike. GitHub, like any website, receives the connecting IP address. Turn it off under Settings → Updates, or for good with UPDATE_CHECK=0 in the container's environment, for example on an air-gapped network.

Authentication

Single-instance mode

A new deployment requires an administrator-supplied bootstrap password of at least 12 characters and forces a change at first sign-in. Passwords are hashed with Argon2. Sessions use cryptographically random identifiers stored in HttpOnly, SameSite cookies. Changing or administratively resetting the password revokes existing sessions.

Multi-user proxy mode

Pro can delegate authentication to a trusted reverse proxy. In this mode, the proxy supplies the authenticated username and the app scopes user-owned uploads and results accordingly. The application port must remain unreachable to untrusted clients so they cannot forge identity headers. An additional shared proxy secret is available as defence in depth.

HTTPS and network exposure

The application serves HTTP inside the deployment and does not terminate TLS itself. Use a trusted reverse proxy such as Caddy or nginx for HTTPS, expose only ports 80 and 443, and keep the application port on an internal Docker network. The self-hosting guide provides a Caddy configuration that follows this layout.

The exception is a single-user install on your own computer. With the port bound to 127.0.0.1, as in the local setup, traffic never leaves the machine, so there is no network path to protect and no proxy is needed. Never publish the application port to other machines over plain HTTP: anyone who can reach it then sees login passwords and session cookies in transit.

Storage, backups and encryption

Self-hosting gives you control of storage, but it also makes storage protection your responsibility. Use host or volume encryption if you require encryption at rest. Restrict access to the Docker host and backup destination, and protect backups as carefully as the live capture volume.

Packet captures may contain internal addresses, hostnames, credentials or application payloads. Only give instance and backup access to people who are authorised to inspect that traffic.

Operational safeguards

The application supports upload-rate limits, login-rate limits, file-size and batch limits, disk-usage limits, packet-count limits, parse timeouts and a global analysis-worker ceiling. Requests that re-read a large stored capture (following a stream, listing HTTP files, making a shareable copy) queue for a limited number of slots. These controls reduce accidental or malicious resource exhaustion, but they do not replace host monitoring, firewalling, patching and capacity planning.

Security questions

To report a security concern or ask about a deployment, email [email protected]. Do not include packet captures, credentials or sensitive payloads in an initial email.