WAF

Block matching request

1. Request. Maya sends the same 17-byte harmless body through the configured WAF path. Her valid app permission is unchanged. The synthetic ASCII string has exactly 17 bytes. R190 is a chosen size condition: more than 16 bytes, not a claim of malicious content. Maya holds a valid session and has upload permission. F190 remains the original. The two isolated runs differ only in R190’s action; no app operation or response exists yet.
2. Match. R190 matches the body-size condition. Its configured action is block. The covered proxy receives and measures the supported body rather than trusting a claimed length. It stores one match record. Block stops forwarding; count records the match and continues to the exercise’s default allow. Other rules could still block in a real rule set. At this boundary the application has not handled the request and the caller has no response.
3. Act. The proxy creates a 403 response without calling UploadDesk. No U190 is stored. The block run has zero app-upload calls and no U190. In the count run the forwarded request reaches UploadDesk, which validates the session and its own upload grant before storing the 17-byte copy. The response is ready but has not yet arrived at the caller in this authored boundary. Original F190 remains in both. This chapter combines forwarding, app evaluation and response preparation; no traveler or real network timing is depicted.
4. Return. The caller receives the proxy’s 403. Separate checks still permit a 16-byte upload and refuse another owner’s record. The completed caller response is now 403 or 201. Count’s U190 is independently read back with the original 17 bytes; block’s store has no U190. Separate fresh tests send a 16-byte permitted upload (201) and request Nora’s F191 with Maya’s same valid session (403 at the app). The latter is the app’s resource rule, not a WAF content decision. F190 stays unchanged. This selected rule/path proves no code repair, complete attack coverage or closure of direct-origin routes.

Count, then default allow

1. Request. Maya sends the same 17-byte harmless body through the configured WAF path. Her valid app permission is unchanged. The synthetic ASCII string has exactly 17 bytes. R190 is a chosen size condition: more than 16 bytes, not a claim of malicious content. Maya holds a valid session and has upload permission. F190 remains the original. The two isolated runs differ only in R190’s action; no app operation or response exists yet.
2. Match. R190 matches and counts the request. Counting is non-terminating; the remaining policy allows it to proceed. The covered proxy receives and measures the supported body rather than trusting a claimed length. It stores one match record. Block stops forwarding; count records the match and continues to the exercise’s default allow. Other rules could still block in a real rule set. At this boundary the application has not handled the request and the caller has no response.
3. Act. UploadDesk independently permits Maya’s upload, stores U190 and creates a 201 response. A WAF match did not grant app permission. The block run has zero app-upload calls and no U190. In the count run the forwarded request reaches UploadDesk, which validates the session and its own upload grant before storing the 17-byte copy. The response is ready but has not yet arrived at the caller in this authored boundary. Original F190 remains in both. This chapter combines forwarding, app evaluation and response preparation; no traveler or real network timing is depicted.
4. Return. The caller receives the app’s 201 and reads U190 back. Separate checks still permit a 16-byte upload and refuse another owner’s record. The completed caller response is now 403 or 201. Count’s U190 is independently read back with the original 17 bytes; block’s store has no U190. Separate fresh tests send a 16-byte permitted upload (201) and request Nora’s F191 with Maya’s same valid session (403 at the app). The latter is the app’s resource rule, not a WAF content decision. F190 stays unchanged. This selected rule/path proves no code repair, complete attack coverage or closure of direct-origin routes.

This is a local HTTP proxy/rule exercise, not an actual WAF or attack detector. The tiny size rule is for teaching, not a production recommendation. Decrypted supported bodies, identity and protected channels are assumed. Count does not decide access; the remaining policy does. Rule ordering, large-body handling, direct origins, other patterns, false positives and code repair are untested.

Flow references: OWASP: WAF HTTP rules and deployment scope · AWS WAF: blocking versus non-terminating count actions