Secret & PII Detection

Known-prefix and entropy secret scanning, PII and card detection with Luhn.

Traffic Jam passively scans every imported capture for leaked credential material and personal data, and separately masks that same material in analysis views and exports. All detection runs locally in the browser against parsed sessions; nothing is uploaded and no active probes are sent from the detection view. Open the API lab → Security tab to see results.

The security signal board

The Security tab opens on a signal board with five counters derived from the active captures: High severity findings, Exposed secrets, PII signals, Risky cookies, and TLS issues. The JSON IOCs and CSV buttons in the board header download indicator bundles (see IOC export).

Below the board, four tabs group the evidence:

TabContents
HTTP findingsPassive header/cookie/CORS/cache findings (see /docs/en/security/)
Secrets & PII“Credential material” and “PII exposure” lists
Identity flows“Cookie posture” and “Credential lifecycles”
TLS intelligenceCertificate/TLS audit and client clusters

Every secret and PII row shows a masked value, the endpoint, and the location (for example request header authorization or response body). Clicking a row opens the originating request in the inspector. Lists render up to 250 rows.

Known-prefix and structural secret detection

The scanner checks request and response headers, the URL query, the URL path, and request/response bodies against four finding kinds:

KindWhat matches
known-tokenProvider key formats with fixed prefixes (below)
jwtCompact JWS tokens (eyJ…eyJ…)
private-key-----BEGIN … PRIVATE KEY----- PEM blocks
high-entropyLong high-entropy strings (below)

Recognized known-prefix formats: AWS access key IDs (AKIA/ASIA/ABIA/ACCA + 16), GitHub tokens (gh[pousr]_) and fine-grained PATs (github_pat_), GitLab PATs (glpat-), Stripe secret/restricted keys (sk_/rk_ with live/test), Slack tokens (xox[baprs]-), Google API keys (AIza…) and OAuth tokens (ya29.), Square tokens (sq0atp-/sq0csp-), Twilio keys (SK + 32 hex), npm tokens (npm_ + 36), Shopify tokens (shpat_), SendGrid keys (SG.…), and OpenAI keys (sk-).

Findings are deduplicated by label, masked value, location, and endpoint; repeat hits increment an occurrence count and keep up to five sample request IDs. Results sort by severity (private-key > known-token > jwt > high-entropy), then by occurrence count.

Entropy-based detection

Strings of 20–512 characters from the charset [A-Za-z0-9_\-+/=.] are scored with Shannon entropy. A candidate is reported as a high-entropy token only when it:

  • is not a UUID, date, semver, MIME type, or URL scheme (common false positives);
  • is not a repeated-character or repeated-group string;
  • contains at least one letter and at least two character classes (lower, upper, digit);
  • reaches an entropy threshold of 4.2 bits/char (or 3.3 for all-hex strings of 32+ chars).

[!NOTE] Entropy detection is heuristic and tuned to suppress natural-language and identifier noise. Treat high-entropy rows as candidates to triage, not confirmed secrets.

PII and payment card detection

The PII scanner reads request and response bodies only (not headers) and reports five kinds:

KindDetectionMasked form
credit-card13–19 digit runs that pass the Luhn checksum•••• 1234 (last 4)
ssn\d{3}-\d{2}-\d{4}•••-••-1234
emailStandard address patternj…@e…com
phone7–15 digit phone-shaped runs•••12 (last 2)
ip-addressReportable IPv4 addresses10.20.×.×

Card candidates are only reported when Luhn-valid. IPv4 reporting skips 0.x, loopback (127.x), multicast/broadcast (≥224, 255.255.255.255), and the RFC 5737 documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24). Findings cap at 500 per kind and keep up to five sample request IDs.

The Identity flows → Cookie posture list profiles each cookie name per host across the capture timeline: set/sent counts, distinct value count, average Shannon entropy (bits/char), max value length, and Secure/HttpOnly/SameSite consistency (always/sometimes/never). The profiler raises notes when:

  • the Secure or HttpOnly flag is inconsistent across Set-Cookie responses;
  • SameSite varies between responses;
  • more than 8 distinct values appear (looks like a per-request token, not a stable session ID);
  • a set cookie’s average value entropy is below 2.5 (“session identifiers may be predictable”);
  • a value was sent by the client before any Set-Cookie defined it — flagged as a session-fixation risk (badge fixation risk).

IOC export

The board’s JSON IOCs and CSV buttons collect indicators from all loaded sessions into a bundle of domains, ips, ja3, ja4, certSha256, and urls (URLs capped at 2000). Sources include request authorities, client/server IPs, TLS ClientHello JA3/JA4 fingerprints and SNI, and certificate SANs and SHA-256 fingerprints.

  • JSON (traffic-jam-iocs.json): a generatedAt timestamp, a counts object, and the six sorted arrays.
  • CSV (traffic-jam-iocs.csv): a type,value header with rows typed domain, ip, ja3, ja4, cert-sha256, url; values containing commas or quotes are quoted.

How sensitive values are masked

Independent of detection, analysis views and generated exports redact credential material by default:

  • Headers. authorization, proxy-authorization, cookie, set-cookie, x-api-key, x-auth-token, x-access-token, x-session-token, x-csrf-token, x-xsrf-token, plus any header whose name contains a sensitive token (e.g. token, secret, signature, password). Authorization becomes Bearer <redacted>; cookies become name=<redacted> pairs; others become <redacted>. Correlation/trace headers (traceparent, x-request-id, x-device-id, …) are never masked.
  • URLs. User-info credentials, credential path segments (segments after context words such as token, oauth, reset, or matching known key formats/JWTs), sensitive query names (token, api_key, plus code, key, sig), and fragment values are replaced with <redacted>. Whole-URL headers (location, referer, …) are redacted in place.
  • Bodies. JSON fields with sensitive names become "<redacted>" (keys containing credential patterns become "<redacted-key>"); form-urlencoded, multipart (by part name), and HTML/XML markup values are redacted; free text gets Bearer/JWT/known-key pattern replacement. Opaque bodies that cannot be inspected safely are replaced with <redacted: opaque body> in shareable exports.

Generated curl, Python, Postman, and OpenAPI examples apply the same redaction; see /docs/en/analysis/exports/ and /docs/en/api-re/catalog/ for the export safety manifest that counts redactions and omitted opaque bodies.

Revealing captured values

Masking is display-level and reversible only by an explicit opt-in. Open Settings → Security and enable Reveal sensitive values in the UI. The toggle is off by default, automatically disables after 15 minutes, and affects display only — replays and exports require their own separate opt-in before captured credentials are used. With reveal on, the request inspector copies the full request URL instead of the redacted one (see /docs/en/analysis/inspector/).

[!WARNING] Revealed values appear on screen and in the clipboard. Only enable reveal on a trusted workstation when reviewing captures you are authorized to handle.

Traffic Jam documentation. Built with Hugo.