Security Testing
Security checks a tester owns — the OWASP Top 10, authentication versus authorization testing, injection and XSS, session management, fuzzing, privacy of personal data, and where a QA check ends and a penetration test begins.
9 questions
JuniorTheoryVery commonHow do authentication and authorization testing differ?
How do authentication and authorization testing differ?
Authentication tests who you are — login, MFA, token issuance, lockout, password reset. Authorization tests what you may do — roles, ownership, per-object access. The bug a tester actually catches is authorization: change an id in a request and read another user's record (IDOR), or reach an admin endpoint as an ordinary user.
Common mistakes
- ✗Swapping the definitions — authentication is who, authorization is what
- ✗Trusting the UI hides an action, when the endpoint still authorizes it
- ✗Overlooking IDOR — that changing an id can expose another user's data
Follow-up questions
- →How would you test for IDOR with two ordinary accounts?
- →Why must authorization always be checked at the API, not the UI?
JuniorTheoryVery commonWhat is the OWASP Top 10, and how does a tester use it?
What is the OWASP Top 10, and how does a tester use it?
The OWASP Top 10 is a community-maintained, ranked list of the most critical web application security risks — broken access control, injection, cryptographic failures, and more. It is an awareness baseline, not a certification: a tester uses it as shared vocabulary and a checklist of what to probe on every release.
Common mistakes
- ✗Treating the list as a certification you pass rather than an awareness baseline
- ✗Thinking it is a tool that runs, instead of a catalogue of risks to probe
- ✗Assuming ticking all ten means no more security testing is needed
Follow-up questions
- →Name three categories from the current OWASP Top 10.
- →Why is broken access control ranked so highly in recent editions?
MiddleDesignCommonA search box on a login-protected admin page feeds its value straight into a SQL query. You have a normal test account and an intercepting proxy, but no source-code access and no security scanner. Describe how you would probe this field for SQL injection, what evidence would confirm the flaw, and — since a tester reports rather than fixes — what you would tell the developers is the correct fix.
A search box on a login-protected admin page feeds its value straight into a SQL query. You have a normal test account and an intercepting proxy, but no source-code access and no security scanner. Describe how you would probe this field for SQL injection, what evidence would confirm the flaw, and — since a tester reports rather than fixes — what you would tell the developers is the correct fix.
Probe through the proxy by injecting SQL metacharacters: a lone quote to trigger a database error, then ' OR 1=1--, then a time-based payload such as a sleep. Evidence is a leaked SQL error, an altered result set, or a measurable delay proving the input reaches the query. The fix you report is parameterised queries — not UI escaping and not a WAF.
Common mistakes
- ✗Reporting input sanitising or a WAF as the fix instead of parameterised queries
- ✗Thinking a QA fixes injection, when they probe and report it
- ✗Expecting a visible page change, missing error-based and time-based signals
Follow-up questions
- →How does a time-based payload confirm injection when nothing is echoed?
- →Why do parameterised queries stop injection where escaping fails?
MiddleDesignCommonYou are testing session handling for a banking web app. A user can log in on several devices, change their password, and log out. Describe the session-security checks you would run — covering idle and absolute timeouts, what logout must actually do on the server, session fixation, and cookie flags — and what a failure of each would let an attacker do.
You are testing session handling for a banking web app. A user can log in on several devices, change their password, and log out. Describe the session-security checks you would run — covering idle and absolute timeouts, what logout must actually do on the server, session fixation, and cookie flags — and what a failure of each would let an attacker do.
Confirm idle and absolute timeouts expire the session. Verify logout invalidates it server-side, not merely deletes the cookie, so a captured token dies. Check the session id rotates on login and on privilege change to block fixation, and that cookies carry HttpOnly, Secure, and SameSite. Finally confirm the concurrent-session policy behaves exactly as specified.
Common mistakes
- ✗Thinking logout is done client-side, not invalidated server-side
- ✗Missing session fixation — the id must rotate on login and privilege change
- ✗Omitting or misreading the HttpOnly, Secure, and SameSite cookie flags
Follow-up questions
- →How would you prove logout killed the session on the server, not just the cookie?
- →What is session fixation, and which action must rotate the id?
MiddleDesignCommonA web app renders a user's display name in the page header, echoes their last search term back on the results page, and builds part of the DOM from a URL fragment on the client. As a tester with two accounts and a proxy, describe how you would test all three spots for cross-site scripting, name which XSS type each represents, and state what fix you would ask the developers for.
A web app renders a user's display name in the page header, echoes their last search term back on the results page, and builds part of the DOM from a URL fragment on the client. As a tester with two accounts and a proxy, describe how you would test all three spots for cross-site scripting, name which XSS type each represents, and state what fix you would ask the developers for.
Inject a harmless marker like a <script> tag or an onerror image and see whether it executes rather than showing as text. The header is stored XSS, the echoed search is reflected, and the URL-fragment DOM build is DOM-based. The fix you request is context-aware output encoding — HTML body, attribute, JS, and URL each differ — with CSP as defence in depth.
Common mistakes
- ✗Prescribing an input blacklist instead of context-aware output encoding
- ✗Treating all XSS as one type, missing stored, reflected, and DOM-based
- ✗Believing HTTPS or a WAF prevents XSS from executing in the browser
Follow-up questions
- →Why does the encoding differ between an HTML body and a JS context?
- →What does a Content-Security-Policy add once encoding is in place?
MiddleTheoryOccasionalWhere does a QA security check end and a penetration test begin?
Where does a QA security check end and a penetration test begin?
A QA security check is scripted, per-release verification that known controls hold — access rules, input handling, session, the OWASP baseline — run with a normal account and reported as a suspected flaw. A pentest is an authorized adversarial engagement: specialists chain and exploit unknown weaknesses to prove real impact, scoped and run periodically.
Common mistakes
- ✗Thinking a tester performs the full exploit-and-pivot pentest each release
- ✗Believing a pentest is just an automated scanner run once a year
- ✗Confusing reporting a suspected flaw with proving impact by exploiting it
Follow-up questions
- →What access or sign-off does a pentester have that a tester on a release does not?
- →Which OWASP-baseline checks stay a tester's job rather than a pentester's?
MiddleDesignOccasionalYour team is preparing for a data-privacy audit. Application and access logs are shipped to a central store that support, on-call engineers, and an external log vendor can all read. A reviewer asks you to prove that personal data — names, emails, phone numbers, full card numbers, auth tokens — never lands in those logs in readable form. You have a test environment, the ability to drive real user flows, and read access to the log store. Describe how you would test that PII is masked or redacted, which flows and log levels you would exercise, and what you would report as a defect versus a pass.
Your team is preparing for a data-privacy audit. Application and access logs are shipped to a central store that support, on-call engineers, and an external log vendor can all read. A reviewer asks you to prove that personal data — names, emails, phone numbers, full card numbers, auth tokens — never lands in those logs in readable form. You have a test environment, the ability to drive real user flows, and read access to the log store. Describe how you would test that PII is masked or redacted, which flows and log levels you would exercise, and what you would report as a defect versus a pass.
Drive the flows that carry PII — signup, login, payment, profile edit, error paths — then grep the log store for the exact values you entered. Masking passes only when the field is redacted everywhere: every level including debug and stack traces, bodies, URLs, and the external sink. A readable value anywhere is a defect, and so is partial masking that still identifies the person.
Common mistakes
- ✗Checking only INFO level and the happy path, skipping debug and stack traces
- ✗Treating encryption at rest as a substitute for redacting the values
- ✗Accepting partial masking that still identifies the person
Follow-up questions
- →How would you catch PII that only appears in an error stack trace?
- →Why is the external log vendor's copy in scope for this check?
MiddleTheoryRareWhat is fuzz testing, and what kind of bug does it find?
What is fuzz testing, and what kind of bug does it find?
Fuzzing throws malformed, random, and boundary input at an interface and watches for crashes, 500s, stack traces, and hangs. Its oracle is not is the output correct but does it crash or leak, so it finds cases your test suite never imagined. Coverage-guided fuzzers mutate inputs toward new code paths to drive the program into deeper states.
Common mistakes
- ✗Thinking the oracle is output correctness, not crash-or-leak
- ✗Confusing fuzzing with load testing or static analysis
- ✗Assuming random input is useless without a known expected result
Follow-up questions
- →What signals do you watch for while a fuzzer runs?
- →How does a coverage-guided fuzzer differ from purely random input?
SeniorDesignRareA user exercises their GDPR right to erasure. The company must delete their personal data across the primary database, read replicas, search indexes, caches, the analytics warehouse, backups, and any data shared with third-party processors. As the QA lead, you are asked to design the verification that the deletion actually happened and is complete. Describe how you would prove the data is gone everywhere it was copied, how you handle backups and derived data, what evidence closes the request, and where a lingering copy would still count as a failure.
A user exercises their GDPR right to erasure. The company must delete their personal data across the primary database, read replicas, search indexes, caches, the analytics warehouse, backups, and any data shared with third-party processors. As the QA lead, you are asked to design the verification that the deletion actually happened and is complete. Describe how you would prove the data is gone everywhere it was copied, how you handle backups and derived data, what evidence closes the request, and where a lingering copy would still count as a failure.
Enumerate every store the data was copied into — DB, replicas, indexes, caches, warehouse, logs, backups, processors — then query each to confirm the subject's rows and derived records are gone or anonymised. Backups you cannot purge need a documented retention-plus-suppression policy. The request closes only with evidence from every sink; one readable copy is a failure.
Common mistakes
- ✗Deleting only from the primary database and trusting replicas to follow
- ✗Accepting a soft-delete flag as satisfying the right to erasure
- ✗Closing on the engineering ticket without evidence from every store
Follow-up questions
- →How do you handle a subject's data in an immutable backup you cannot selectively edit?
- →Why do anonymised analytics rows still risk failing an erasure request?
