Developers added maximum-length checks on every form field for a permitting portal and declared XSS, CSRF, and SQLi handled. Why is that incomplete for OWASP threat mitigation?
Select an answer to reveal the explanation.
Short Explanation
Checking the package size is useful, but it is not the lock, the seal, or the ledger rules. Length allow-lists help; they do not substitute for encoding, CSRF tokens, or bound SQL.
Full Explanation
Maximum-length checks reduce oversized junk and some overflow oddities, but they do not neutralize XSS, CSRF, or SQLi by themselves. A permitting portal that only adds length validation and declares those OWASP threats handled is incomplete: XSS still needs output encoding, CSRF still needs tokens or SameSite request discipline, and SQLi still needs parameterized queries. Length limits are complementary input validation for civic forms, not replacements for those primary controls.
Claiming length checks replace TLS so HTTPS can be disabled fails confidentiality requirements entirely. Saying allow-lists alone force the database to reject parameterized queries reverses reality—bound parameters work together with allow-lists. Asserting maximum length is sufficient for CSRF but must be removed for XSS defenses invents a false tradeoff; CSRF is not solved by length, and XSS defenses remain necessary regardless of field size.
Exam caveat: allow-lists and length limits are still good hygiene on municipal intake forms; the exam targets the mistake of treating them as sole mitigations. Validate on input and encode on output.
Operational check: keep length checks, then demonstrate a short XSS payload still needs encoding, a short CSRF POST still needs a token, and a short SQLi fragment still needs parameter binds.