Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/facunemi/evidence-sanitizer/llms.txt

Use this file to discover all available pages before exploring further.

Evidence Sanitizer scans application/x-www-form-urlencoded request bodies for sensitive field values. Scanning is gated by an explicit Content-Type header line — the form scanner does not activate on any body text unless it first finds a matching Content-Type: application/x-www-form-urlencoded line followed by a blank separator line. This design prevents false positives on query string text, prose notes, or other evidence that happens to contain key=value patterns.

Rule ID and Marker

Rule IDMarker
form.value<REDACTED:form.value>

Sensitive Form Field Names

The following field names trigger form.value redaction (matched case-insensitively): access_token, accesstoken, auth_token, authtoken, id_token, idtoken, jwt, refresh_token, refreshtoken, session, session_id, sessionid, sid, token, api-key, api_key, apikey, x_api_key, xapikey, client_secret, clientsecret, shared_secret, sharedsecret, private_key, privatekey, password, passwd, pwd, client_assertion, clientassertion, saml_response, samlresponse, sig, signature, x-amz-credential, x-amz-security-token, x-amz-signature, x-goog-credential, x-goog-signature, x_amz_signature, xamzsignature, x_goog_signature, xgoogsignature, csrf, csrf_token, xsrf, xsrf_token

Before/After Example

Content-Type: application/x-www-form-urlencoded

access_token=synthetic-token&client_secret=synthetic-secret&grant_type=authorization_code
Content-Type: application/x-www-form-urlencoded

access_token=<REDACTED:form.value>&client_secret=<REDACTED:form.value>&grant_type=authorization_code
grant_type is not in the sensitive field list and is left unchanged.

Activation Gate

The form scanner activates only when all three conditions are met in sequence within the evidence text:
  1. A physical line matching Content-Type: application/x-www-form-urlencoded (case-insensitive header name; optional parameters after the media type are allowed, e.g., ; charset=utf-8)
  2. A blank separator line (zero-length physical line) somewhere after the Content-Type line — not necessarily immediately after
  3. A non-empty physical line immediately after the blank separator — this is the body line
Only the immediate first physical line after the blank separator is scanned. Multi-line or wrapped form bodies are not supported. If the body spans multiple lines, only the first line is examined.

Field Parsing

The form body line is scanned for name=value segments separated by &. Field names are normalized to ASCII lowercase before lookup against the sensitive field list.
field1=value1&field2=value2&field3=value3
Semicolons are not supported as field separators. Only & is recognized as a separator. A body line using ; as a separator may not be parsed correctly.
No percent-decoding or plus-sign (+) decoding is performed on field names or values. The raw bytes as written in the evidence are matched.

Deferred (Non-Redacted) Field Names

The following common OAuth and form field names are intentionally not in the sensitive list and are left unchanged: grant_type, scope, code, username, redirect_uri, response_type, state, nonce These names carry semantic information useful for understanding the evidence and do not typically contain secrets in standard OAuth flows.

Overlap Protection

The form scanner is evaluated before the query and JSON scanners, but after Authorization, Proxy-Authorization, Cookie, and Sensitive Header findings. If a candidate form value span overlaps any existing finding, the form finding is skipped. Folded Proxy-Authorization header spans are also registered as protected regions and prevent form findings from firing inside them.

Idempotence

If a matched field value is already exactly <REDACTED:form.value>, no finding is produced.

Multiple Form Blocks

If the evidence text contains more than one Content-Type: application/x-www-form-urlencoded header, each triggers independent scanning. However, each body start position is only scanned once — if two Content-Type headers would resolve to the same body line, it is scanned only once.

Out of Scope

  • No Content-Type line → no form scanning. Raw key=value strings without a supported Content-Type line are not scanned by the form rule.
  • Multipart form data (multipart/form-data) is not supported.
  • Chunked or multi-line bodies are not supported; only the first physical body line is scanned.
  • Percent-encoded field names are not decoded; %61ccess_token does not match access_token.

Build docs developers (and LLMs) love