Guides

AppSec OWASP Interview Questions (50) — SQLi, XSS, API

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

This AppSec OWASP interview pack gives 50 defence-first Q&As on SQLi, XSS, access control and API security — conceptual answers for builders and testers, not exploit or PoC recipes.

Untrusted input → encode/parameterise/authorise → log denials
Scanner ≠ AppSec programme
No permission → no testing story

How to use this interview pack

1. Read the quick answer and educational warning once.
2. Cover ten questions a day aloud in English; record yourself privately if helpful.
3. For each answer, add one OWN lab example (Sahyadri-style fiction is fine if labelled).
4. When a question sounds offensive, start with authorisation / defence.
5. Cross-link deeper guides: OWASP Top 10, SQLi prevention, XSS prevention, API security.
6. Do not memorise payloads — memorise controls and tests.

Fifty interview questions and answers

Speak ethics first when a question sounds offensive. Prefer defence, detection and process. These answers are conceptual — not exploit, PoC, cracking or Metasploit recipes.

Q1. What is application security (AppSec)?

AppSec is the practice of finding and fixing weaknesses in software design, code, configs and APIs so attackers cannot abuse them. In interviews I frame it as secure SDLC: requirements, threat thinking, secure coding, testing, logging and fix ownership — not as a tool dump.

Q2. What is the OWASP Top 10 and how do you use it in an interview?

OWASP Top 10 is a community risk list for web apps. I use it as a defence checklist and conversation agenda: broken access control, injection, misconfig, crypto failures, integrity and logging gaps. I do not recite attack recipes; I explain impact and controls.

Q3. Explain SQL injection at a high level and how you prevent it.

SQL injection happens when untrusted input changes the meaning of a database query. Prevention is parameterised queries / prepared statements, least-privilege DB accounts, input validation as defence-in-depth, and WAF only as a layer — not a substitute for safe code.

Q4. What is the difference between SQLi and command injection?

SQLi targets the database query language. Command injection targets OS shell interpretation when apps concatenate user input into system commands. Both are injection classes; fixes are avoid interpreters with untrusted strings, use safe APIs, and validate strictly.

Q5. How do you explain XSS to a hiring manager?

Cross-Site Scripting lets an attacker cause a victim's browser to run unwanted script in the site's origin, often to steal sessions or change the page. Defence: context-aware output encoding, Content-Security-Policy, HttpOnly cookies, and treating all user content as untrusted.

Q6. Stored vs reflected vs DOM XSS — interview version?

Stored XSS persists in the app (comment DB). Reflected XSS bounces in a response from a crafted request. DOM XSS happens when client-side script unsafely writes attacker-controlled data into the DOM. Fixes still centre on encoding, safe sinks and CSP.

Q7. What is CSRF and how do you mitigate it?

Cross-Site Request Forgery tricks a logged-in browser into sending an unwanted state-changing request. Mitigations: anti-CSRF tokens synchronized with sessions, SameSite cookies, re-auth for sensitive actions, and avoiding GET for state changes.

Q8. What is broken access control? Give an interview example.

Broken access control is when the server fails to enforce who may do what. Classic theme: changing an object id (IDOR) to see another user's order. Fix: authorise on every request using the session identity and object ownership on the server — never trust hidden fields alone.

Q9. What is IDOR?

Insecure Direct Object Reference is a common broken-access pattern: predictable ids without ownership checks. Interview answer: server must verify the caller may access that resource; add tests that swap ids and expect deny.

Q10. How does authentication differ from authorisation?

Authentication proves identity (login, MFA). Authorisation decides permissions after identity is known. Mixing them up causes bugs: 'user is logged in' is not the same as 'user may delete all invoices'.

Q11. What AppSec controls belong in an API (OWASP API mindset)?

Object-level and function-level authorisation, strong authn with short-lived tokens, rate limiting, schema validation, minimal data in responses, inventory of endpoints, and security logging for 401/403 and bulk export.

Q12. Why are API keys in mobile apps a weak secret?

Anything shipped to a client can be extracted. Treat client-side keys as public identifiers; put real secrets on the server and use short-lived user tokens with refresh controls.

Q13. What is mass assignment / excessive data exposure?

Mass assignment binds unexpected request fields into objects (role=admin). Excessive data exposure returns too many fields and relies on the UI to hide them. Fix: explicit allow-lists / DTOs and server-side filtering.

Q14. How do you talk about security headers in interviews?

I name purpose, not magic: CSP reduces XSS impact, HSTS forces HTTPS, X-Content-Type-Options reduces MIME sniffing, Referrer-Policy limits leakage, Frame protections reduce clickjacking. Headers complement secure code; they do not replace it.

Q15. What is clickjacking conceptually?

Tricking a user into clicking something in a framed page they did not intend. Defence includes CSP frame-ancestors / X-Frame-Options and careful UX for sensitive actions.

Q16. How should secrets be handled in AppSec answers?

No secrets in git, images or front-end bundles. Use a vault or cloud secret store, rotate on leak, enable secret scanning in CI, and revoke first when something slips.

Q17. What is SAST vs DAST vs SCA?

SAST reviews source/bytecode for patterns. DAST probes a running app from outside. SCA checks third-party dependencies for known CVEs. Mature teams combine them with owners and SLAs — not scan theatre.

Q18. How do you prioritise AppSec findings?

By exploitability and business impact: authz flaws on money/PII routes beat cosmetic issues. Use severity with context, fix criticals with owners, and verify with retest.

Q19. What is a secure SDLC talking point?

Security activities across the lifecycle: threat modelling early, secure coding standards, dependency hygiene, PR checks, staging tests, production monitoring and incident-ready logging.

Q20. Explain input validation vs output encoding.

Validation checks data is acceptable before use. Output encoding makes data safe for a specific context (HTML, JS, URL, SQL via parameters). Both matter; encoding at the sink is critical for XSS.

Q21. What is SSRF at a conceptual level?

Server-Side Request Forgery is when an app fetches a URL attacker influences, reaching internal services. Defence: allow-lists, block link-local/metadata ranges, network egress controls — I stay conceptual, no exploit steps.

Q22. What is path traversal conceptually?

Using ../ style input to read files outside the intended directory. Defence: canonicalise paths, reject suspicious sequences, serve from fixed roots, and never concatenate raw user paths.

Q23. How do cookies stay safer?

Secure + HttpOnly + appropriate SameSite, short sessions, regenerate session ids on login, and store minimal data server-side.

Q24. What logging should AppSec demand?

Authn success/fail, authz denials, admin actions, and unusual export volume — without logging secrets or full card numbers. Logs feed SOC detection.

Q25. How do you explain CAPTCHA / bot friction ethically?

Rate limits and bot challenges protect login and signup from abuse. They are controls, not proof of security alone.

Q26. What is privilege escalation in web AppSec terms?

Gaining rights beyond what the account should have — vertical (user→admin) or horizontal (user A→user B data). Root cause is usually missing server-side checks.

Q27. How would you test access control safely in a lab?

On apps I own: create two users, attempt to access the other user's objects, and assert HTTP 403. Automate those checks in CI. No production probing without written authorisation.

Q28. What is CORS and a common misconfig theme?

Cross-Origin Resource Sharing controls which browsers may read responses cross-site. Over-permissive Access-Control-Allow-Origin with credentials is a frequent misconfig. Default deny; allow specific trusted origins.

Q29. How do you discuss file upload risks without recipes?

Risks: malware storage, unexpected execution, path tricks. Controls: type allow-lists, store outside web root, virus scan where policy requires, random names, size limits, and authz on download.

Q30. What is business logic abuse?

Exploiting intended workflows in unintended ways — coupon stacking, race conditions on balances — without classic injection. Needs product-aware testing and limits, not only scanners.

Q31. Name three AppSec metrics interviewers like.

Time-to-fix for critical vulns, percent of apps with authz automated tests, and secret-scan fail rate on main. Metrics should drive behaviour, not vanity scores.

Q32. How does supply chain relate to AppSec?

Dependencies and build pipelines can introduce risk. Pin versions, scan SCA, verify integrity where possible, protect CI credentials, and review high-impact package updates.

Q33. What is the difference between a vulnerability and an exploit?

A vulnerability is a weakness. An exploit is a way to abuse it. Interview focus for builders: remove weaknesses and detect abuse — I do not provide exploit craft.

Q34. How do you answer 'Have you used Burp Suite?'

I describe it as an authorised web testing proxy for labs and engagements with RoE. I talk about mapping requests and validating fixes, never about attacking systems without permission.

Q35. What is parameterised query proof in an interview?

I explain that the SQL structure is fixed and values bind separately so quotes cannot break out into syntax. I contrast with string concatenation. Code sample spoken, not a weaponised payload list.

Q36. How do MFA and AppSec connect?

Credential stuffing and phishing still succeed with passwords alone. MFA on login and step-up MFA for sensitive actions reduce account takeover even when passwords leak.

Q37. What is secure session management?

Cryptographically strong session ids, HTTPS only, idle and absolute timeouts, logout that invalidates server-side, and protection against fixation.

Q38. Explain least privilege for application service accounts.

The app DB user should not be root; it gets only needed tables and statements. Cloud roles for the app are similarly minimal. Breach blast radius shrinks.

Q39. What is content security policy in one minute?

CSP tells the browser which sources may load scripts and other content, reducing XSS impact when a bug still slips. Start in report mode, then enforce carefully.

Q40. How do you handle third-party scripts ethically?

Inventory tags, prefer first-party where possible, Subresource Integrity for known CDNs, and legal/privacy review — supply chain applies to front-end too.

Q41. What is an AppSec 'definition of done'?

Feature is not done until authz tests pass, secrets scan is clean, high SCA issues have owners, and logging covers sensitive actions.

Q42. How would you explain OWASP ASVS briefly?

Application Security Verification Standard — detailed requirements by level for verifying app security. Useful for building checklists beyond Top 10 headlines.

Q43. What is rate limiting for AppSec?

Caps how often sensitive endpoints can be called — login, OTP, password reset, search export — to slow abuse and credential stuffing.

Q44. How do you talk about GraphQL security themes?

Authz on every field/resolver, query depth/cost limits, and avoiding overly introspective production schemas. Same access-control principles as REST.

Q45. What red flags show weak AppSec culture?

No owners for findings, prod secrets in chat, 'WAF will save us', disabled security tests to ship faster, and no retest after fixes.

Q46. How do you prepare a portfolio AppSec story?

OWN lab app: show a safe demo of a broken check, then the fix (prepared statements / authz), then a failing automated test that would catch regressions. Label it clearly as a lab.

Q47. What is the relationship between threat modelling and AppSec interviews?

I describe assets, entry points, trust boundaries and mitigations (STRIDE-style). Interviewers like structured thinking more than tool name-dropping.

Q48. How should juniors answer 'Find SQLi on this live site'?

I refuse unauthorised testing. I explain prevention concepts and offer to demonstrate on my lab DVWA-style target only. Ethics is part of the grade.

Q49. What documentation do AppSec engineers maintain?

Threat models, security requirements, finding tickets with severity and owners, architecture decision records for authn, and runbooks for secret rotation.

Q50. Closing AppSec interview line?

I build with access control and safe data handling first, measure with tests and logs, and I only probe systems I own or am contracted to test — then I help the team fix and retest.