waf issues posting shows results in a 403 #21

Open
opened 2026-09-27 09:17:57 +00:00 by ken_fallon · 0 comments
Owner

HTTP/2 403
waf-block: request
x-request-reference: dc45a0d8-1044-4d3e-9b6a-3ace8b96bfa2
content-length: 3618
content-type: text/html; charset=utf-8
alt-svc: h3=":443"; ma=86400

Suggested fixes

  1. Validate the exact bytes you're sending, not just the JSON before encoding — pipe the literal request body through python3 -m json.tool or jq empty and see if it errors.
  2. Check for a stray BOM or leading/trailing whitespace/data after the JSON — some clients add invisible characters that break strict parsers even though the JSON itself is fine.
  3. Confirm Content-Length matches the actual byte count you're sending — a mismatch (e.g. from manual header-setting, or multi-byte UTF-8 characters counted wrong) can cause the body to be truncated or padded before it even reaches the parser.
  4. Invalid UTF-8 or unescaped control characters in string values are a common culprit if any of the JSON is built by hand or from user input.
HTTP/2 403 waf-block: request x-request-reference: dc45a0d8-1044-4d3e-9b6a-3ace8b96bfa2 content-length: 3618 content-type: text/html; charset=utf-8 alt-svc: h3=":443"; ma=86400 <!DOCTYPE html> <!-- Served by HAProxy via `lf-file` on Coraza WAF deny. IMPORTANT: HAProxy's lf-file expansion treats `` as the start of a log-format expression. Literal percent signs (CSS 100, gradient stops, url-encoded data, etc.) MUST be doubled as `%` or HAProxy will silently swallow them. Expressions like `dc45a0d8-1044-4d3e-9b6a-3ace8b96bfa2` / `[hub.hackerpublicradio.org](http://hub.hackerpublicradio.org/)` stay single-`` — those are the substitutions we want. --> Suggested fixes 1. Validate the exact bytes you're sending, not just the JSON before encoding — pipe the literal request body through python3 -m json.tool or jq empty and see if it errors. 2. Check for a stray BOM or leading/trailing whitespace/data after the JSON — some clients add invisible characters that break strict parsers even though the JSON itself is fine. 3. Confirm Content-Length matches the actual byte count you're sending — a mismatch (e.g. from manual header-setting, or multi-byte UTF-8 characters counted wrong) can cause the body to be truncated or padded before it even reaches the parser. 4. Invalid UTF-8 or unescaped control characters in string values are a common culprit if any of the JSON is built by hand or from user input.
Sign in to join this conversation.