Table Of Contents
There’s a conversation that happens in most QA teams eventually. Someone asks about security testing. Someone else says “that’s a DevSecOps problem” or “we don’t have the tooling for it.” The conversation ends quickly and as before, nothing changes.
And then six months later, a security finding lands that was absolutely a quality issue. A validation gap or broken auth check. An unpatched dependency with a known CVE. The post-mortem talks about “security awareness” and everyone feels guilty for a week. Then we go about our normal routines, missing an opportunity for growth.
Here’s the thing: most security bugs that hit production were quality failures first. QA does not need to become DevSecOps. QA already has eyes on the parts of the system where these bugs live. The missing piece is usually just a handful of extra questions, asked at the right moments.
The Reframe
Security is not a separate discipline bolted onto quality. Security is quality viewed through a hostile lens. One that should always be explored, no matter how secure or irrelevant you think your application is.
You should already be testing input validation and auth flows. You should already be checking error handling and you already ask “what happens if I do this in the wrong order.” Every one of those activities overlaps with something OWASP calls out in the Top 10. You are already doing security work – you just aint calling it that.
The shift that makes this useful is pretty small really. When you sit down to design a test case, you ask three extra questions. When you review a PR, you ask three extra questions. That is the entire method – no tooling change, no new certifications. Absolutely no taking DevSecOps job.
The Minimum-Viable Threat Model
Three questions in 30 seconds. Before any testing starts.
Who can access this? – Authenticated users? Admin only? Anonymous? Anyone with a link?
What data does it touch? – PII? Payment info? Internal systems? Nothing sensitive?
What happens if the input is hostile? – What does the endpoint do if someone sends garbage, or the wrong type, or a thousand times the expected payload?
That’s the minimum-viable threat model. You are not pretending to be a pentester and you are most definitely not writing a formal threat register. You are asking three questions that anyone designing a feature should be able to answer, and if they can’t, that is your first line item under acceptance criteria.
I have seen more security bugs get caught in sprint refinement with those three questions than in any tool I have used. Tools catch the stuff that slipped through. The questions stop most of it ever getting written in the first place. With these questions, people think differently and developers change their mindset in how they approach a change or feature. Or at least they should.
OWASP Top 10 in Plain English
The OWASP Top 10 is an intimidating list if you read it the wrong way. Read it the right way and most of it maps to things a decent QA already looks for.
Broken access control is the big one. Can a regular user hit the admin endpoint directly (escalate privileges you could say)? Can user A see user B’s data by changing an ID in the URL? This is the largest bug class on the list and it is the one that looks most like a regular functional test.
Cryptographic failures cover anything sensitive being sent or stored in the clear. Passwords in logs, tokens in URLs, PII in browser local storage. A decent exploratory session catches most of this.
Injection is the famous category – SQL injection, command injection, LDAP injection, template injection. If the app ever takes user input and puts it somewhere an interpreter will execute it, this is on the list.
Insecure design is the awkward one. It’s a catch-all for “the feature itself has a flaw by design, not by implementation.” Harder to spot in testing. Easier to spot in refinement, which is exactly why the three questions matter.
Security misconfiguration covers default credentials, debug mode left on in production, verbose error messages, exposed admin panels. Vulnerable and outdated components is largely handled by a dependency scanner, which I will get to.
Identification and authentication failures – weak password policies, session fixation, token reuse after logout, “remember me” that never forgets – mostly get caught by going beyond the happy path on auth flows.
Software and data integrity failures, security logging and monitoring failures, and server-side request forgery round out the list. Worth knowing the categories exist. Worth asking “if this gets abused, will we even see it?” during refinement. Worth asking, any time a feature takes a URL as input, can the backend be tricked into making a request on behalf of the attacker.
That is the whole list. It’s not magic. Most of it is stuff a thoughtful tester asks anyway. The OWASP label just makes it easier to talk about with security people, and easier to raise in PR reviews without screaming the sky is falling.
Where to Plug in Without a Tool Budget
Three moments matter most, and none of them need a budget.
Refinement – The three questions. Who can access this, what data does it touch, what happens if the input is hostile. If the team cannot answer, that is the first finding before a single test case has been written.
PR review – Not every PR. But when you see a new endpoint, a new data field, or a change to auth or input handling, slow down. Read it like someone with hostile intent. Would I be able to bypass this? What happens if I skip a step? Does this log something useful if it gets abused?
Exploratory sessions – Tamper. Replay. Escalate. Change a request with DevTools open. Send the same request a second time. Try to perform actions as a user with lower privileges. None of this is what I would call sophisticated testing. But all of it catches things automated testing won’t.
None of this requires a tool budget. All of it requires the team to make space for it, which is a harder ask than it should be.
The Three Tools That Earn Their Keep
I’ll keep this short because tools are context-dependent, but three have held up across most teams I have worked with.
Static:
SonarQube running in IDEs and CI. Something that reads the static code and flags known-risky patterns. Doesn’t catch everything, flags plenty of false positives, but still catches enough real issues to justify its seat in the pipeline.
Dynamic:
A passive ZAP or Burp session during exploratory testing. Passive means it watches the traffic while you test normally, via a built-in proxy that sits between your browser and the app. No attack payloads per se, just a log of everything the browser sent and received, which is surprisingly useful on its own.
Dependency scanning:
Whatever your ecosystem uses – Dependabot, Snyk, npm audit, whatever fits. It catches the “vulnerable and outdated components” category without any thought on your part. Cheap and very much worth it.
If you have time for one tool, make it dependency scanning. Least amount of effort, with the highest catch rate.
Know When to Escalate
Not every finding is yours to fix. That’s fine.
If you find something that looks exploitable beyond your team’s scope, escalate. If you find data exposure that could affect customers, escalate. If you find something that makes you nervous and you can’t articulate exactly why, just escalate. DevSecOps or your manager or whoever owns the function exists for exactly this reason. If you can’t put your finger on it, they can walk through things with you, to hopefully nail it down.
If you don’t have a DevSecOps function, be honest about your ceiling. There is a level of security work QA cannot cover alone, and pretending otherwise is how teams end up with a false sense of safety. The shortlist in this article catches the obvious stuff, but it does not make a team secure. It makes a team less likely to ship the things that would have been caught by a thoughtful tester asking the right questions.
Remember, testing doesn’t assert there are no further issues. Testing confirms the risk on issues found and if it’s worth taking a deeper dive.
Blame Culture Eats Security
I have written about this before in a different context, but it matters here too.
A developer who gets roasted for a security bug (any bug for that matter) hides the next one. Not necessarily on purpose or with devious intent. They just become less likely to raise the uncertainty out loud, because the last time they did, they got ripped apart. Security findings need the same blameless response as any other bug. Coach, don’t shame.
In my experience, teams that handle security findings well treat them like any other defect. A bug got through. We learned things, we worked together, we fixed and mitigated on various fronts. No names are required. Everybody stays willing to raise the next “hmm, this doesn’t look right” without worrying about being shamed as the one who missed it.
That culture is worth more than any tool you will buy.
The Shortlist
If you only take one thing from this article, take the three questions. Print them or write them on a Post-it. Stick it to your monitor if you have to. Ask them before any testing starts, preferably within sprint refinement.
Who can access this. What data does it touch. What happens if the input is hostile.
That is the shortest path from “we don’t do security testing” to “we’re already doing security testing, we just weren’t calling it that.”
An extra bonus here if you have the time to experiment, go try OWASP Zap. Hook it in to your browser (via proxy), navigate around your application and trigger actions. The mere act of doing this will catch issues as the code executes (dynamically), and will give you a report on severity levels, an understanding as to what it all means and potential mitigation paths. The best bonus, it’s free!
The Take
Security testing for QA is not a separate discipline. It is the same work you are already doing, with three extra questions asked at the right moments. Yes we can create automated suites to test for it, but most of the OWASP Top 10 maps to bugs a thoughtful tester catches anyway. A static scanner, a dependency checker, and a passive proxy during exploratory sessions is enough tooling for most teams.
Know when to escalate. Know where QA’s ceiling is. Treat security findings with the same blameless response you would give any other bug, because the team that hides security findings is the team that ships the incident.
No doubt you were already doing security testing. Maybe just not how you expected. But now you can extend the conversation, a little better prepared.
A Note on Context
Every business and every project is different. What works in one place won’t work in another, and that’s the point.
Nothing here is meant to be a step-by-step prescription. It’s guidance, drawn from my own experiences, and deliberately kept general to avoid pointing fingers anywhere.
Take what’s useful, ignore what isn’t, and adapt it to your own context. Or as Joe Colantonio always says: “Test everything and keep the good.”
