Question 1

As a manual QA, which security checks do you run?

Accepted Answer

First frame the role: "I don't do penetration testing — that's separate expertise. But I have standard security checks I run on every feature." Then give the list in priority order: (1) authorisation — changing an ID in the URL (IDOR), opening admin pages with a regular account, calling a UI-hidden action directly from Postman; (2) authentication and session — brute-force lockout, Back after logout, expired tokens, old sessions surviving a password change; (3) input validation — XSS and SQL probes, a disguised executable in file upload; (4) data exposure — card numbers or national IDs in response bodies, tokens in URLs. Close with the ethics: test environments only, test accounts only. That structure makes the answer memorable.

Question 2

What is IDOR and how do you check for it?

Accepted Answer

Give a simple definition: the server doesn't check whether the requester owns the object, so changing the ID reaches someone else's data. Then your concrete method: prepare two test accounts (A and B), log in as A, note my object's ID, then swap it for B's ID in the URL or API request. The expected result is 403 or 404; data being shown is a Critical bug. Important additions: I check at the API level, not just the UI (the mobile app may use the same endpoint), and I try PDF/export links too — permission checks are often forgotten there. Close with responsibility: after confirming with two IDs I stop, I don't enumerate IDs systematically, and I report through a restricted channel.

Question 3

How do you report a security bug differently from an ordinary bug?

Accepted Answer

There are four differences. Channel — I restrict ticket visibility (QA lead, dev lead, security) and never discuss it in general chat or a demo. Level of detail — I give reproduction steps but don't deepen the exploitation or attach extracted data; personal fields in screenshots are redacted. Impact description — I go beyond the technical and write the business and legal impact (e.g. exposing personal data in insurance can become a reportable incident). Escalation speed — I don't wait for normal triage, I inform the lead directly. Add one sentence: "I also state that I did not verify it on production — that decision belongs to the security team." That sentence shows both professionalism and awareness of boundaries.

Question 4

You entered in a field and nothing happened. What do you conclude?

Accepted Answer

Be careful — concluding "there's no XSS" is premature, and that's exactly what the interviewer is testing. The right answer: I have to follow where that input is displayed. If the value was stored, it may be rendered later somewhere else: a list screen, the admin panel, a PDF export, a notification email, a report. That's how stored XSS works — the entry point looks safe, the output point isn't. So my checks are: (1) was the value saved or rejected by validation; (2) if rejected, is the message clear; (3) if accepted, I visit EVERY screen that displays it; (4) in DevTools Elements I check whether it renders as escaped text or as HTML. This answer shows depth, and very few candidates go this far.

Problem class	What to try	What to report if you see it
Broken access control / IDOR	Swap the ID in the URL or API request for someone else's: /policy/10231 → /policy/10232	Another customer's policy/document opens or can be edited
Role-based authorisation	Open an admin URL with a regular account; call a UI-hidden action directly via the API	The action is only hidden in the UI while the backend doesn't check permissions
Authentication	Repeated wrong-password attempts; Back button after logout; a request with an old/expired token	No lockout, pages still open after logout, expired tokens accepted
Injection (SQL / XSS)	Enter test payloads in text fields and watch the result	A 500 error, a database error message on screen, a script executing
Sensitive data exposure	Inspect response bodies in DevTools Network; check URL parameters; open PDF/export files	Full card numbers, national IDs or password hashes in a response; a token or personal data in a URL
Session management	Wait for session timeout; log in from two devices; change the password and check the old session	Sessions never expire; the old session still works after a password change

Security testing basics for QA

📚 Sources and documentation