L5Core5 min read

Security: the OWASP Top 10

The baseline vocabulary. Injection, broken access control, misconfiguration — enough to recognise a class of problem in a pull request and to write a test that proves it. You are not becoming a pentester; you are becoming hard to slip past.

Security bugs rarely show up in a normal functional test pass, yet they cause some of the most expensive incidents a team will ever face. The OWASP Top 10 is the industry's reference list of the most critical web application security risks, and QA engineers are often the first line of defense that can catch them before release.

This guide walks through each category, what it means in practice, and how a QA engineer (not a dedicated pentester) can build lightweight checks into everyday testing, alongside solid API testing and schema validation practices.

Why QA should care about OWASP, not just devs

Security testing is often treated as a specialist activity handled entirely by a separate pentest team, but that leaves a large gap. Pentests happen once or twice a year, while QA touches every build. Catching an injection flaw or a broken access control bug during regression testing is far cheaper than finding it in a formal audit six months later.

The goal is not to replace a pentest. It is to add a security-aware layer to your existing functional and regression suites so obvious, high-impact issues get caught early and consistently.

The OWASP Top 10 2021, from a QA lens

Here is the current list and the practical question a QA engineer should ask for each one.

A01 Broken Access Control: Can a low-privilege user reach an admin URL, API endpoint, or another user's data by changing an ID or role?
A02 Cryptographic Failures: Is sensitive data (passwords, tokens, PII) sent or stored in plain text instead of encrypted?
A03 Injection: Does user input get concatenated into SQL, shell commands, or templates without sanitization?
A04 Insecure Design: Are there missing rate limits, weak password reset flows, or business logic that trusts the client too much?
A05 Security Misconfiguration: Are default credentials, verbose error pages, or open directory listings still exposed?
A06 Vulnerable and Outdated Components: Is the app running libraries with known CVEs?
A07 Identification and Authentication Failures: Can sessions be reused after logout, or is there no lockout after repeated failed logins?
A08 Software and Data Integrity Failures: Are updates or CI pipelines pulling unsigned packages from untrusted sources?
A09 Security Logging and Monitoring Failures: Do failed logins and access-control violations actually get logged and alerted on?
A10 Server-Side Request Forgery (SSRF): Can a URL input field be used to make the server call internal services?

A worked example: testing broken access control on a real feature

Say your team ships an "invoice details" page at /invoices/{id}. A functional tester confirms the page renders correctly for the logged-in user's own invoice. A security-aware QA pass goes one step further.

Log in as User A, note the invoice ID from the URL, then log in as User B in a separate session or incognito window. Try to load User A's invoice ID directly using User B's session.

If the page returns the data instead of a 403 or 404, that is a broken access control bug. It is known as an Insecure Direct Object Reference, and it belongs in the bug tracker with a "security" label and high severity, not just a regular defect.

This same pattern, swap the ID and see what happens, applies to API endpoints, exported files, and admin actions. It takes minutes to check and catches one of the most common real-world vulnerabilities.

Tools that fit into a QA workflow

You do not need to become a penetration tester to add security coverage. A few tools bridge the gap between manual functional testing and full security audits.

security-testing-toolkit.txt

OWASP ZAP (free, open source)
  - Automated spidering and passive scanning of your app
  - Active scan mode flags injection and misconfiguration risks
  - Runs headless in CI for regression-style security checks

Burp Suite Community/Pro
  - Intercepting proxy for manual request tampering
  - Repeater tool to replay and modify requests (great for access control tests)

npm audit / pip-audit / OWASP Dependency-Check
  - Flags known CVEs in your dependency tree (A06)

git-secrets or truffleHog
  - Scans commits for accidentally committed credentials

Running OWASP ZAP's baseline scan against a staging environment as part of your CI/CD pipeline for test suites gives you a repeatable, low-effort security gate on every build, without slowing down releases.

Where QA testing and pentesting differ

A pentest is scoped, time-boxed, and performed by specialists who actively try to exploit a system. They chain vulnerabilities together to demonstrate real business impact. QA security testing is different. It is continuous, embedded in the regular test cycle, and focused on catching common, well-understood mistakes before they ship.

Think of it as two layers. QA closes the obvious gaps every sprint, and the pentest team validates the harder, more creative attack paths a few times a year. Neither layer replaces the other. Skipping the QA layer means the pentest team spends its limited time on issues that a five-minute manual check could have already caught.

Building this into your test plan

Start small. Pick two or three checks per feature area, such as ID-swapping for access control and a basic ZAP baseline scan in CI. Treat any hit as a real defect with a security label. Over a few sprints, expand coverage to authentication flows, file uploads, and any endpoint that accepts URLs as input (a common SSRF vector).

Logging matters here too. When your QA suite finds a security issue, verify that the application actually logged the failed attempt or blocked action. If there is no log entry, that is itself an A09 finding worth raising, since a security team can only respond to incidents they can see.

FAQ

Questions people ask

Do QA engineers need to learn to write exploits to test for OWASP Top 10 risks?

No. Most high-value checks are simple, like trying another user's ID in a URL or submitting a single quote character into a form field. Deep exploit writing is a pentester's job, not a QA baseline.

How often should we run an OWASP ZAP scan?

A lightweight baseline scan on every CI build against staging is a good starting point. Save deeper active scans for a scheduled weekly or pre-release run since they generate more traffic and false positives.

Is OWASP Top 10 coverage enough to call an app "secure"?

No. It covers the most common and impactful risk categories, but a full security posture also needs a professional pentest, secure design review, and ongoing dependency monitoring.

Security testing does not need to be a separate discipline bolted onto the end of a release cycle. By folding a handful of OWASP Top 10 checks into the testing you already do, alongside solid flaky test prevention so security tests stay trustworthy, your team catches the highest-impact issues long before they reach production.