Security Testing Interview Questions for QA

Overview

Security questions have quietly migrated out of dedicated penetration-testing interviews and into ordinary QA and SDET loops. Hiring managers have learned that a tester who spots a broken access-control bug during a normal regression pass is worth far more than one who files only functional defects. You do not need to be a certified ethical hacker to clear these rounds, but you do need a working mental model of how applications get attacked and where they usually break.

This guide collects the security testing questions QA engineers actually face, from the OWASP Top 10 down to concrete scenarios like probing a login form or an unprotected API endpoint. Each question comes with a sample answer written the way a strong candidate would say it, focused on judgment rather than buzzwords. The examples lean on real vulnerability classes so you can talk credibly even when your day job is mostly functional testing.

Use it as a rehearsal script. Read the question, answer out loud before you read the model response, then compare. If your answer skipped the reason it matters or the way you would actually test it, that gap is exactly what an interviewer will probe.

Why QA Engineers Get Security Questions Now

Interviewers open the security thread to find out whether you think like an attacker or only like a user. A functional tester verifies that the happy path works. A security-aware tester asks what happens when the input is hostile, the request is replayed, or the user ID in the URL is swapped for someone else's. That mindset is cheap to teach and expensive to miss, which is why even mid-level QA roles now include a security question or two.

The honest framing to bring into the room: you are QA, not a red team. Say clearly what you own (input validation, authorization checks, secure defaults, dependency hygiene, verifying fixes) and where you escalate (deep exploitation, cryptographic review, infrastructure pentests). Interviewers respect a candidate who knows the boundary of their competence far more than one who claims to hack everything.

• Frame security testing as risk reduction, not box-ticking against a checklist.
• Know the difference between SAST (static, code), DAST (dynamic, running app), and SCA (dependencies).
• Be ready to name a security bug you personally caught or would have caught.

Foundational Questions: OWASP, CIA, and Vocabulary

'Walk me through the OWASP Top 10 and why it exists.' A strong answer explains that the OWASP Top 10 is a community-ranked list of the most critical web application risks, refreshed every few years, meant as an awareness baseline rather than a complete standard. You do not need to recite all ten, but you should confidently name the heavy hitters: Broken Access Control (currently number one), Injection, Cryptographic Failures, Security Misconfiguration, and Vulnerable and Outdated Components. Tie each to something you would actually test.

'What is the CIA triad?' Confidentiality, Integrity, and Availability. Confidentiality keeps data visible only to those authorized, integrity prevents unauthorized modification, and availability keeps the service reachable. Good candidates map defects to the triad: an IDOR bug is a confidentiality failure, a tampered price field is an integrity failure, and an unthrottled endpoint that can be flooded is an availability failure. That vocabulary shows you can classify severity, not just find bugs.

Injection and Input-Handling Questions

'How would you test a search field for SQL injection?' Start by injecting a single quote and watching for a 500 error or a database message, which signals unsanitized input reaching the query. Then try a classic tautology like ' OR '1'='1 to see if the result set widens, and a UNION-based probe to test whether you can read other columns. The real answer, though, is the fix: parameterized queries or prepared statements, which make the payload data instead of executable SQL. Note that you would also verify the ORM is not being bypassed by raw string concatenation.

'Explain stored versus reflected XSS and how you would catch each.' Reflected XSS bounces a script back from a single request, such as a payload in a URL parameter that renders unescaped. Stored XSS persists, like a comment or profile field that runs for every future viewer. To test, submit a benign marker such as <script>alert(1)</script> or an image onerror payload, then check whether it executes or is safely encoded. The durable defense is context-aware output encoding plus a Content Security Policy, and you should say so.

• Always pair a payload with the expected safe behavior, not just the exploit.
• Command injection, LDAP injection, and template injection follow the same data-versus-code principle.
• Test both the client-side validation and the server, because client checks are trivially bypassed.

Authentication and Session Questions

'What would you check on a login and password-reset flow?' Cover credential handling first: passwords hashed with a slow algorithm like bcrypt or Argon2 (never plaintext or MD5), no credentials in URLs or logs, and generic error messages so the form does not reveal which accounts exist. Then session behavior: a new session ID issued on login to prevent fixation, secure and HttpOnly cookie flags, sensible expiry, and real invalidation on logout. For password reset, confirm tokens are single-use, time-limited, and unguessable.

'How do you test for brute-force and credential-stuffing protection?' Look for rate limiting, account lockout or exponential backoff, a challenge on repeated failures, and monitoring or alerting on spikes. A sharp candidate names the tension: aggressive lockout invites denial of service against real users, so the mature control is usually throttling plus anomaly detection rather than hard locks. Mention multi-factor authentication as the control that makes stuffing largely moot.

Authorization and Access-Control Questions

'What is an IDOR and how do you test for it?' An Insecure Direct Object Reference (a subset of Broken Access Control) is when an app trusts a user-supplied identifier without checking ownership. The test is concrete: log in as user A, capture a request like GET /api/orders/1001, then change the ID to 1002 or swap in user B's identifier and see whether the server returns data that should be denied. The fix is server-side authorization on every object access, never security through obscurity of the ID.

'Contrast vertical and horizontal privilege escalation.' Horizontal escalation is accessing a peer's data at the same permission level, the IDOR case above. Vertical escalation is a normal user reaching admin functionality, for example by calling an admin API directly or flipping a role field in a request. To test, map the role matrix, then attempt every restricted action from a lower-privileged session, including forced browsing to admin URLs and tampering with hidden form fields or token claims.

API and Modern App Security Questions

'What is special about testing a JWT-based API?' Check that the token is validated server-side on every request, that the signature algorithm is enforced (reject alg none, and reject an RS256 token re-signed as HS256 using the public key), and that expiry and audience claims are honored. Confirm sensitive data is not simply base64-encoded in the payload, since anyone can decode a JWT. Also test what happens after logout, because a stateless token often stays valid until expiry unless there is a revocation list.

'Name a few API-specific risks beyond the web Top 10.' Point to the OWASP API Security Top 10: Broken Object Level Authorization (BOLA, the API cousin of IDOR), Broken Function Level Authorization, excessive data exposure where the API returns more fields than the UI shows, mass assignment where client JSON binds straight onto a model so a user can set an admin flag, and lack of rate limiting. Mention CORS misconfiguration and verbose error messages as easy wins during testing.

• Inspect API responses in the network tab for fields the UI hides but the endpoint leaks.
• Send extra JSON properties to probe mass assignment.
• Replay a request with an expired or tampered token to confirm server-side checks.

Tooling Questions: ZAP, Burp, and Scanners

'Which security tools have you used and for what?' Be specific and honest. OWASP ZAP and Burp Suite are the workhorses for intercepting, replaying, and fuzzing HTTP traffic. ZAP is free and scriptable into CI, while Burp is the industry-standard manual proxy. For dependency risk, name an SCA scanner like OWASP Dependency-Check, Snyk, or npm audit. For static analysis, mention SAST tools such as Semgrep or SonarQube. The interviewer wants to know you can operate a proxy, not that you memorized a vendor list.

'How would you add security scanning to a CI pipeline?' Describe layering. Run SCA and SAST on every pull request because they are fast and deterministic, then schedule a DAST scan (a ZAP baseline scan against a deployed staging build) nightly because it is slower and noisier. Fail the build on high-severity, newly introduced issues, and triage the rest into a backlog. Stress that automated scanners find the known and shallow bugs, so they do not replace human review of business-logic authorization.

Scenario-Based Questions

'You have thirty minutes to security-test a new checkout page. What do you do?' Prioritize by impact. First, authorization: can I pay against another user's cart or view someone else's order? Second, input handling on the fields that hit the backend, meaning injection and XSS in the address and coupon fields. Third, price integrity: intercept the request and tamper with the amount or quantity to see whether the server recomputes totals or trusts the client. Finish with transport checks (HTTPS, secure cookies) and a quick look at what the payment response leaks.

'A developer says a bug is only exploitable by a logged-in user, so it is low risk. Your response?' Push back with reasoning, not attitude. An authenticated attacker is a completely normal threat model: any registered user, a compromised account, or an insider. If the bug lets one customer read another customer's data or escalate privileges, the authentication requirement barely lowers severity. Quantify the blast radius and let the risk, not the assumption, set the priority.

Shift-Left and Process Questions

'What is threat modeling and how does QA contribute?' Threat modeling is thinking through what can go wrong before code is written: identify assets, entry points, and likely attackers, often with a lightweight framework like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege). QA contributes the tester's instinct for abuse cases and then turns each identified threat into a concrete negative test, so the model produces coverage rather than a document nobody reads.

'How do you handle secrets and sensitive data in test environments?' Never hardcode credentials in test code or fixtures, keep them in a secrets manager or CI-injected environment variables, and scrub tokens and PII from logs, screenshots, and failure artifacts. Use synthetic or masked data rather than production dumps. If you find a secret committed to the repository, treat it as compromised: it must be rotated, not just deleted from the latest commit, because Git history keeps it.

Behavioral and Judgment Questions

'Tell me about a security issue you found or missed.' Interviewers want a real story with a lesson. Describe the bug, how you found it or how it escaped, the impact, and what you changed afterward: a new negative test, a checklist item, a pipeline gate. If you have no war story, use a recent near-miss from practice or a lab. Ownership and follow-through read as more senior than a dramatic exploit.

'How do you report a security bug responsibly?' Keep the details in the tracker's restricted view or a private channel, not a public ticket, because a written repro is a weapon until it is fixed. Include severity with justification, a minimal reproduction, and the affected scope, and coordinate a disclosure timeline with the owning team. Professionalism in how you handle the finding matters as much as finding it.

Frequently Asked Questions

Related QAJobFit Guides

• API Security Testing Interview Questions for QA Engineers
• Cloud Security QA Interview Questions for QA Engineers
• Mobile Security Testing Interview Questions for QA Engineers
• Security Testing Resume Interview Questions for QA Engineers
• Accessibility Testing Interview Questions for QA Engineers
• AI Assisted Testing Interview Questions for QA Engineers