Input Boundary and Type-Confusion Testing

Purpose

Scanners send known payload strings; this skill instead reasons about what each parameter MEANT to be and what happens when it arrives as something else. Type, shape, encoding, and multiplicity violations find the bugs pattern-matching cannot: parser confusion, mass assignment, silent coercion, and validation layers that disagree with processing layers. This skill generates HYPOTHESES; when a class signal appears, the specialist skill handles exploitation depth.

Entry Conditions

• Meaningful parameters identified in state-changing or privileged requests (ids, quantities, prices, roles, emails, flags, tenant ids, file paths, search/sort/filter params)
• A captured legitimate baseline request per target endpoint

Step 1: Expected-Domain Reasoning

For each parameter write down its expected domain. quantity expects positive integer, role expects enum, user_id expects string uuid, sort expects column name. The expected domain is the INVARIANT; every test violates one aspect of it. Do not waste rounds on display-only parameters - prioritize parameters that reach authorization decisions, money, state transitions, or queries.

Value Boundaries (for numeric-ish parameters)

0, -1, MAX_INT (2147483647), MAX_INT+1 (2147483648), -MAX_INT-1
float where int expected (1.5, 0.001, 1e3, 1e309)
string where number expected ("10", " 10", "10\n", "0x10", "1,000", "10.0")
null, empty string, absent field
true / false (JSON booleans where int/string expected)

Integer overflow/underflow at parse, store, and compute time are three different bugs - if 2147483648 is accepted, observe what got stored (2000000000? wrapped negative? rejected at a later layer?).

Type and Shape Confusion