A security review lists three findings: reflected XSS in a status page, CSRF on an admin POST, and SQLi in a search endpoint. Which pairing correctly matches each threat to its primary mitigation?
Select an answer to reveal the explanation.
Short Explanation
Right tool, right job: encode what you print (XSS), token what you change (CSRF), bind what you query (SQLi). Swapping those fixes leaves each hole open.
Full Explanation
OWASP application mitigations map one-to-one with threat mechanisms. Reflected XSS is fixed primarily with context-appropriate output encoding (and safe frameworks). CSRF on an admin POST is fixed with an anti-CSRF token (or equivalent SameSite strategy). SQLi in a search endpoint is fixed with parameterized queries. The correct pairing for the security review is therefore XSS → output encoding; CSRF → anti-CSRF token; SQLi → parameterized queries.
Pairing XSS → CSRF token; CSRF → bound SQL parameters; SQLi → HTML output encoding swaps every control to the wrong threat and would leave all three findings effectively open. XSS → SameSite cookie only; CSRF → HTML encoding; SQLi → firewall allow-list of ports similarly mismatches mechanisms and over-narrows XSS to cookies alone. XSS → parameterized queries; CSRF → output encoding; SQLi → anti-CSRF token is another full rotation of wrong pairings that confuses data-store and browser issues.
Exam caveat: layered defenses exist (CSP for XSS, SameSite for CSRF, WAF for SQLi) but the primary DEVCOR pairing remains encoding / CSRF token / parameters. Do not memorize firewall ports as the SQLi answer.
Operational check: in review notes, label each finding with its primary control and verify staging tests cover an encoding probe, a CSRF-token rejection, and a parameterized SQLi probe as separate evidence.