Passive Security Findings

Automatic checks: HSTS/CSP, cookie flags, CORS, plaintext credentials, version disclosure.

Traffic Jam lints every captured request/response pair against a fixed set of passive HTTP security rules. The checks run entirely on traffic you already captured — no active probes are sent from this view, and credential values stay masked. This page covers the finding types, the severity model, how results are aggregated, and the WebSocket/QUIC capture warnings.

Open the findings view

Findings live in the API workspace, under the Security tab, in the HTTP findings sub-tab.

Open the API workspace for one or more imported captures.
Select the Security tab.
The signal board at the top summarizes High severity, exposed secrets, PII signals, risky cookies, and TLS issues.
Select the HTTP findings sub-tab (the first of four: HTTP findings, Secrets & PII, Identity flows, TLS intelligence).

Each row shows the finding title, the host, the detail text, and an occurrence count. Click a row to jump to a sample request in the inspector. The list renders at most 250 rows.

Finding types

Rules fall into six groups. Header-presence rules fire only on HTTPS responses; the rest apply to any scheme.

Rule ID	Severity	Trigger
`missing-hsts`	medium	HTTPS response has no `Strict-Transport-Security` header
`missing-csp`	low	HTML (`text/html`) response has no `Content-Security-Policy`
`missing-nosniff`	info	HTML/JSON/JS/CSS response has no `X-Content-Type-Options: nosniff`
`cookie-missing-secure`	medium	`Set-Cookie` over HTTPS lacks the `Secure` attribute
`cookie-missing-httponly`	low	`Set-Cookie` lacks `HttpOnly` (readable from JavaScript)
`cookie-missing-samesite`	low	`Set-Cookie` has no `SameSite` attribute
`cookie-samesite-none-insecure`	medium	`SameSite=None` without `Secure`
`cacheable-authenticated-response`	medium	2xx JSON/HTML response to an authenticated request without `Cache-Control: no-store`/`private`
`token-in-url`	high	A query parameter name looks like a credential
`redirect-secret-leak`	high	A `Location` redirect target carries a sensitive query parameter
`plaintext-credentials`	high	A plain-HTTP request carries an `Authorization`/`Cookie` header or a sensitive query parameter
`cors-wildcard`	info	`Access-Control-Allow-Origin: *`
`cors-wildcard-with-credentials`	high	`Access-Control-Allow-Origin: *` with `Allow-Credentials: true`
`cors-reflected-origin`	low	Request `Origin` reflected in `Access-Control-Allow-Origin`
`cors-reflected-origin-with-credentials`	high	Reflected origin with credentials enabled
`server-version-disclosure`	info	`Server` header contains a digit
`x-powered-by-disclosure`	info	`X-Powered-By` header present

An authenticated request is one carrying an Authorization or Cookie request header. The cacheable-response rule ignores responses that already set no-store or private.

Severity model

Every finding carries one of four severities, ranked for sorting:

Severity	Rank	Badge
`high`	3	danger
`medium`	2	warning
`low`	1	outline
`info`	0	metadata

The findings list is sorted by severity (highest first), then by occurrence count, then by title. The signal board’s High severity tile counts only high findings.

How findings are aggregated

Findings are grouped per ruleId + host + a group key (the cookie name, the query parameter name, or the disclosed Server/X-Powered-By value where relevant). Repeated matches on the same host increment the occurrence counter instead of creating duplicate rows. Each finding keeps up to 5 sample request IDs; the first one is the jump target when you click a row.

The lint summary also reports how many exchanges were analyzed, how many had a response, and how many distinct hosts were seen.

[!NOTE] Because grouping is per host, the same missing header on two hosts appears as two separate findings.

What counts as a credential in a URL

The token-in-url, redirect-secret-leak, and plaintext-credentials rules rely on the shared sensitive-name matcher. A query parameter name is treated as credential-bearing when it matches a secret-like pattern (api-key, auth/authorization, credentials, jwt, secret, session, sign/signature, token) or is exactly code, key, or sig.

[!WARNING] These rules flag potential exposure only. Confirm any credential handling against the system’s intended design before reporting it, and test only systems you are authorized to assess.

WebSocket and QUIC/HTTP3 capture warnings

These are capture-time warnings, not lint findings. They surface in the workspace status bar and the capture library as a warnings tooltip on the affected session.

WebSocket upgrades. The parser marks an exchange as a WebSocket upgrade when the request or response carries Upgrade: websocket and the response is 101 Switching Protocols or has a Connection: upgrade token. The session gains a warning such as Detected 2 WebSocket upgrade handshake(s); upgrade metadata is available, but WebSocket message frames are not decoded yet. Upgraded exchanges get a WebSocket upgrade badge in the catalog (/docs/en/api-re/catalog/) and a WebSocket badge in global search (/docs/en/analysis/search/). Message-frame decoding is not supported.
QUIC/HTTP3. UDP flows on port 443 or 8443 are counted as QUIC candidates. The session warning reads Detected N QUIC/HTTP3 flow(s) (M UDP packets on port 443/8443); QUIC traffic cannot be decrypted with TLS keylogs, disable QUIC/HTTP3 in the client to capture it. QUIC decryption is not supported, so re-capture with QUIC disabled in the client. See /docs/en/capture/importing/ for how warnings are attached to imported sessions.

[!TIP] Warnings are per session. If a capture mixes HTTP/1, HTTP/2, WebSocket, and QUIC, only the WebSocket and QUIC portions produce warnings; the HTTP exchanges still feed the findings above.