Injection & XSS Study Portal

Interview talking points

• Frame all of A03 as one idea — "untrusted data crossing into a code/instruction channel" — and show you can map it across SQL, HTML/XSS, shell, LDAP, NoSQL, and templates rather than treating them as unrelated bugs.
• Lead with the primary defense for each: parameterized queries for SQLi, contextual output encoding (plus auto-escaping frameworks) for XSS, array-arg process execution for command injection.
• Distinguish input validation from output encoding: validation (allow-lists) is about accepting good shapes; encoding is a rendering-time concern matched to the output context. You need both, and one doesn't substitute for the other.
• Explain the three XSS variants by where the trust boundary is crossed (persisted, reflected in response, client-side source→sink) and tie DOM XSS to source/sink analysis.
• Be precise that ORMs and prepared statements are not magic: identifiers (columns, sort order) can't be parameterized, and raw-query escape hatches reintroduce injection.
• Position CSP, least-privilege DB accounts, and WAFs as defense-in-depth — useful layers, but never the primary fix; a WAF can be bypassed and shouldn't be your answer to "how do you fix SQLi".
• Mention SSTI and NoSQL operator injection to show range beyond the textbook examples, and use {{7*7}} and { "$ne": null } as memorable, concrete probes.
• Close with secure-by-default tooling: parameterized query libraries, auto-escaping template engines, DOMPurify for unavoidable HTML, linters/SAST that flag raw-SQL and innerHTML sinks, and the principle of making the safe path the easy path.