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:
| Tab | Contents |
|---|---|
| HTTP findings | Passive 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 intelligence | Certificate/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:
| Kind | What matches |
|---|---|
known-token | Provider key formats with fixed prefixes (below) |
jwt | Compact JWS tokens (eyJ…eyJ…) |
private-key | -----BEGIN … PRIVATE KEY----- PEM blocks |
high-entropy | Long 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-entropyrows 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:
| Kind | Detection | Masked form |
|---|---|---|
credit-card | 13–19 digit runs that pass the Luhn checksum | •••• 1234 (last 4) |
ssn | \d{3}-\d{2}-\d{4} | •••-••-1234 |
email | Standard address pattern | j…@e…com |
phone | 7–15 digit phone-shaped runs | •••12 (last 2) |
ip-address | Reportable IPv4 addresses | 10.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.
Cookie entropy and fixation signals
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
SecureorHttpOnlyflag is inconsistent acrossSet-Cookieresponses; SameSitevaries 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-Cookiedefined it — flagged as a session-fixation risk (badgefixation 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): ageneratedAttimestamp, acountsobject, and the six sorted arrays. - CSV (
traffic-jam-iocs.csv): atype,valueheader with rows typeddomain,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).AuthorizationbecomesBearer <redacted>; cookies becomename=<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, pluscode,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 getsBearer/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.