Input Validation Coverage Calculator

coverage = 0.35 × allow-list coverage + 0.25 × schema coverage + 0.15 × bounds coverage + 0.15 × canonicalisation coverage + 0.10 × fuzz coverage, each expressed as a percentage of parameters in scope. Allow-list validation carries the most weight because it is the only control that rejects the unexpected rather than trying to enumerate the dangerous, and canonicalisation is weighted alongside it because a check performed before decoding can be bypassed. Client-side-only validation is scaled to 40% since it is a usability feature, not a control.

Coverage is the number that predicts your next injection finding: the parameters nobody validated are the parameters the next test will break, and this turns that into a count you can plan against.

This calculator takes 8 inputs: Input parameters in scope, Parameters with allow-list validation, Parameters with type or schema validation, Parameters with length or range bounds, Parameters canonicalised before validation, Parameters covered by fuzz or property tests, Validation enforced server-side, not only in the client, Injection findings per 100 unvalidated parameters. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

No, and the gap is where bugs live. A schema proves a field is a string of at most 64 characters; an allow-list proves it matches the format that field is actually allowed to take. JSON Schema plus a per-field pattern gets you both, and the pattern is the part that stops injection.