Web application security interview questions

Questions and answers

6 questions with model answers

Rewrite each answer in your own words before the loop — interviewers can tell a memorized paragraph from one you can defend under a follow-up.

1. Question 1

   Explain cross-site scripting and how you would actually prevent it.

   XSS happens when attacker-controlled input reaches a browser rendering context and is interpreted as code rather than data — reflected from the request, stored in a database and served to other users, or introduced entirely client-side through a DOM sink like innerHTML. Prevention is contextual output encoding: the correct escaping differs for HTML body, attribute, JavaScript, URL, and CSS contexts, which is why hand-rolled sanitizers keep failing. In practice I would lean on a framework's automatic escaping, avoid dangerous sinks, sanitize rich HTML with a vetted library like DOMPurify when it is genuinely needed, and add a Content Security Policy as defense in depth rather than as the primary control. HttpOnly cookies do not prevent XSS, but they do stop the simplest session-theft payload, which is a distinction interviewers listen for.

2. Question 2

   How do you prevent SQL injection in a codebase that already has a lot of dynamic SQL?

   The durable fix is parameterized queries or prepared statements so user input is never concatenated into the statement text — an ORM usually gives this for free, but raw query escape hatches inside an ORM are exactly where injection survives. Where a query genuinely needs a dynamic identifier, such as a sort column, that value has to be validated against an allowlist rather than escaped, because identifiers cannot be parameterized. I would work through the codebase by finding the sinks first — the functions that execute SQL — and then tracing which of them receive request-derived data, rather than reading files top to bottom. Alongside the code fix I would reduce blast radius: the application's database account should not own DDL rights, and error messages should not return database text to the user.

3. Question 3

   What is CSRF, and do SameSite cookies solve it?

   CSRF abuses the fact that browsers attach cookies automatically: an attacker's page triggers a state-changing request to your site, and the user's session makes it authenticated. SameSite=Lax, now the default in major browsers, stops the common cross-site POST case, which has genuinely reduced the impact of CSRF — but it is not a complete answer, because same-site subdomains, GET-based state changes, and clients that ignore the attribute still exist. The reliable control is a per-session anti-CSRF token validated server-side, or a double-submit pattern, plus never performing state changes on GET. Token-based APIs using an Authorization header instead of cookies are not exposed the same way, which is worth saying because it shows you understand the mechanism rather than the checklist item.

4. Question 4

   How would you defend a feature that fetches a URL supplied by the user?

   This is SSRF, and the reason it is severe is that the request comes from inside the network boundary, so it reaches internal services and the cloud instance metadata endpoint at 169.254.169.254. Blocklists fail here — DNS names resolving to internal addresses, redirects to internal targets, IPv6 and decimal encodings, and DNS rebinding all defeat naive filtering. The defensible design is an allowlist of permitted hosts or schemes, resolving the hostname and validating the resolved IP against private ranges before connecting, disabling redirect following or re-validating each hop, and routing the fetch through an egress proxy with no access to internal ranges. On AWS specifically, enforcing IMDSv2 removes the highest-value SSRF target, and I would still monitor for metadata-endpoint access from the application tier.

5. Question 5

   How do you find broken access control in an application?

   Broken access control is consistently the highest-impact web bug class because it is invisible to scanners that do not understand who is allowed to do what. I test it by enumerating the object identifiers and privileged actions, then replaying requests with a lower-privileged session — and with no session — to see whether the server actually re-checks authorization rather than relying on the UI hiding the button. The two patterns to look for are IDOR, where a direct object reference is trusted from the request, and missing function-level checks, where an administrative endpoint is only protected by obscurity. The structural fix is to centralize authorization so every request checks ownership on the server against the authenticated principal, rather than scattering conditionals through controllers.

6. Question 6

   You have five findings and one sprint of developer time. How do you prioritize?

   I rank by real-world risk rather than raw severity score: is the endpoint reachable by an unauthenticated internet user, what data or capability does the bug reach, how hard is exploitation in this specific deployment, and is there a compensating control already in place. A critical-rated bug in an internal admin tool behind SSO can genuinely rank below a medium-rated one on a public signup flow that leaks personal data. I also weigh the fix cost, because two cheap structural fixes that eliminate a whole class beat one expensive point fix. Then I say the tradeoff out loud to the owner — what we are accepting, for how long, and what detection or mitigation covers the gap in the meantime — so the decision is recorded rather than implied.