Learning Objectives
By the end of this lesson you will be able to:
- Identify which features in an application are most likely to have coercion bugs
- Apply a systematic coercion testing checklist
- Write a precise bug report for a coercion defect
Where Coercion Bugs Hide
Not every feature is equally vulnerable. Focus your search on:
High Risk: Forms That Do Math
Any form where the user enters numbers and the application calculates a result. The input is always a string. The code must explicitly convert. If it doesn't, coercion fires.
- Shopping cart totals
- Loan/interest calculators
- Currency converters
- Age calculators
- Discount engines
High Risk: API Response Processing
When the application consumes a third-party or microservice API, the response may serialize numbers as strings. Code that directly uses these values in arithmetic is vulnerable.
Medium Risk: Dynamic Language Backends
PHP, JavaScript (Node.js), Ruby, Python 2. Statically typed backends (Java, C#, Go) can't have coercion bugs in the same way — the compiler prevents it.
The Coercion Bug Hunt Checklist
For each high-risk feature:
- Identify all numeric inputs
- Submit them as explicitly string-typed values (via API, if possible)
- Mix types: one field as number, another as string
- Look for concatenation: is the result suspiciously large?
- Test the edge case: what if the value is
"0"?"0.0"?""(empty string)?
Test Input Patterns That Reveal Coercion
| Input Pattern | Why It Tests Coercion |
|---|---|
"100" (quoted numeric string) |
Tests whether code uses + or correctly parses |
"100abc" |
Some coercions parse the leading number, ignoring letters |
" 100" (leading space) |
Tests whether string is trimmed before coercion |
true or false |
Boolean coercion: true + 5 = 6 in JavaScript |
[] (empty array) |
JavaScript: [] + 5 = "5" |
Reading the Output
When you suspect a coercion bug:
- Expected:
$100 - $25 = $75 - Coercion symptom:
$100 + $25 = $10025(concatenation)
The result is always "numerically nonsensical" — too large, impossible, or a string where a number was expected.
Writing the Bug Report
Title: Discount calculation concatenates instead of subtracting when inputs
arrive as strings
Environment: POST /api/calculate with JSON body
Steps to reproduce:
1. Send: {"price": "100", "discount": "25"}
2. Observe response
Expected: {"final_price": 75}
Actual: {"final_price": "10025"}
Root cause: JavaScript `+` operator concatenates strings instead of adding.
price - discount = 75 (correct), but price + discount = "10025" (wrong).
Fix: use parseInt() or parseFloat() before arithmetic.
Severity: High (financial calculation)
Pro Tip: Always specify both the string input format AND the expected numeric output in your coercion bug report. This immediately confirms to the developer which code path is affected.
Key Takeaways
- Forms that do math, API response processing, and dynamic language backends are highest risk
- Coercion bugs show up as concatenated results, not arithmetic results
- Test by submitting string-typed numeric values and observing the output pattern
- Bug reports should include the exact string input and the wrong concatenated output