Security Testing for QA Engineers: Complete 2026 Guide (OWASP, Burp Suite, ZAP)

In 2026, every product is a security product. The average data breach now costs $4.88 million (IBM Cost of a Data Breach Report) and regulatory penalties under GDPR, HIPAA, PCI-DSS and the EU AI Act can exceed $100 million. QA engineers are the last line of defense before code ships — functional tests verify the app works; security tests verify the app doesn't help attackers break it.

This guide covers everything a modern QA engineer needs: the OWASP Top 10 and OWASP API Security Top 10, hands-on testing for SQL injection, XSS, BOLA and broken authentication, practical workflows with Burp Suite and OWASP ZAP, plus how to wire security scans into CI/CD. Pair it with our Manual Testing Complete Guide and the API Testing Tutorial for end-to-end coverage.

What you'll master: the OWASP Top 10 and OWASP API Security Top 10, how to test for SQL injection, XSS, BOLA, broken auth and SSRF, hands-on Burp Suite and OWASP ZAP workflows, and how to integrate SAST/SCA/DAST into your CI/CD pipeline.

QA engineers are the last gate before code reaches users. In 2026 the threat model has shifted:

• DevSecOps is the norm — security testing is integrated into every sprint, not bolted on at release.
• AI-generated code has security risks — LLM-generated code often introduces subtle vulnerabilities that QA must catch (see our GitHub Copilot for QA guide for prompt patterns that prevent this).
• API security is the new perimeter — APIs are the #1 attack vector in 2026 per the OWASP API Security Top 10.
• Supply chain attacks are rising — QA must verify third-party dependencies on every build.
• Regulatory pressure is mounting — every industry now has new security compliance requirements.

If you're a QA engineer in 2026 and you don't know how to test for the OWASP Top 10, you're a liability to your team. Security testing is also one of the fastest paths to a senior salary band — see our QA Engineer Salary Guide for the security premium.

Shift-left security

Security testing starts at the requirements phase, not the test phase. In backlog grooming, ask:

• What data does this feature handle? PII? Payment? Health?
• Who can access this? Admin? User? Anonymous?
• What happens if an attacker sends malicious input here?
• Does this feature log anything sensitive?
• Does this feature meet our compliance requirements?

The threat-modeling habit

Before testing any feature, do a 5-minute threat-modeling pass:

1. What are we building? (login, payment, profile update)
2. What data does it touch? (PII, credentials, money)
3. Who can interact with it? (admin, user, anonymous)
4. What's the worst-case abuse? (account takeover, data exfiltration)
5. What mitigations exist? (auth, validation, rate limiting)

Security vs functional testing

The two are complementary — a feature can pass every functional test and still be insecure.

The OWASP Top 10 is the de facto standard for web application security risks. The 2021 edition remains current; OWASP Top 10:2025 is in draft.

A01:2021 — Broken Access Control

Risk: Users access resources they shouldn't.

Test cases:

• Try to access another user's data by changing the ID (/users/123 → /users/124).
• Hit an admin endpoint as a regular user.
• Perform an admin action (delete user, change role) without the admin role.
• Bypass authorization by tampering with JWT tokens or cookies.

Test: "User cannot view another user's profile"

1. Log in as user A (id=123)
2. GET /users/123/profile → 200 OK
3. GET /users/124/profile → expect 403 Forbidden

A02:2021 — Cryptographic Failures

• Verify HTTPS is enforced (no HTTP fallback).
• Verify Strict-Transport-Security (HSTS) header is present.
• Verify cookies have Secure, HttpOnly, SameSite flags.
• Verify passwords are hashed (not stored in plain text).
• Verify sensitive data is not logged.

A03:2021 — Injection

Payloads to try: SQL (' OR '1'='1, '; DROP TABLE users; --), NoSQL ({"$gt": ""}), LDAP (*)(&), OS command (; ls -la), template (${7*7}, {{7*7}}). See section 6 for hands-on examples.

A04:2021 — Insecure Design

• Rate limiting on sensitive endpoints (login, password reset).
• Business logic can't be abused (applying a discount N times).
• Critical operations require re-authentication.

A05:2021 — Security Misconfiguration

• No default credentials (admin/admin).
• Production doesn't expose stack traces on error.
• Security headers present (CSP, X-Frame-Options).
• Cloud storage (S3 buckets) is not publicly accessible.

A06:2021 — Vulnerable and Outdated Components

• Run npm audit / pip-audit on every build.
• All dependencies are within their support window.

A07:2021 — Identification and Authentication Failures

• Password complexity enforced.
• Account lockout after N failed attempts.
• Session tokens are sufficiently random.
• Password reset doesn't leak information.
• MFA cannot be bypassed.
• JWT tokens are properly validated.

A08:2021 — Software and Data Integrity Failures

• Auto-update mechanisms verify signatures.
• CI/CD verifies supply chain (SLSA framework).
• Deserialization rejects untrusted data.

A09:2021 — Security Logging and Monitoring Failures

• Failed logins and privilege-escalation attempts are logged.
• Logs are tamper-resistant; alerts fire on suspicious patterns.

A10:2021 — Server-Side Request Forgery (SSRF)

• Try to make the server fetch http://localhost/admin.
• Try the AWS metadata endpoint http://169.254.169.254/.
• Try file:// URLs.

The OWASP API Security Top 10 (2023) focuses on REST, GraphQL and gRPC. Test it on every API in your portfolio — pair this section with our API Testing Interview Questions and API Testing Tutorial.

API1:2023 — Broken Object Level Authorization (BOLA)

The #1 API vulnerability in 2026. Test on every endpoint that takes an ID:

• GET /users/1 as user 2 → expect 403
• PUT /orders/123 (another user's order) → expect 403
• DELETE /posts/456 (another user's post) → expect 403

API2:2023 — Broken Authentication

• JWT with no signature → 401
• Expired JWT → 401
• JWT with modified claims → 401
• API key in URL instead of header → 401
• Basic auth with default credentials → 401

API3:2023 — Broken Object Property Level Authorization

• POST /users with {"role": "admin"} as a regular user → 403
• GET /users/me should not include password/password_hash
• PATCH /users/123 with {"balance": 1000000} → 403

API4:2023 — Unrestricted Resource Consumption

• 10,000 requests in 1 second → 429 Too Many Requests
• 100 MB payload → 413 Payload Too Large
• Deeply nested JSON (10,000 levels) → 400 Bad Request

API5:2023 — Broken Function Level Authorization

• Regular user → POST /admin/users → 403
• Regular user → DELETE /admin/settings → 403

API6:2023 — Unrestricted Access to Sensitive Business Flows

• Apply the same coupon code 1,000 times → rate limited
• Create 1,000 accounts in 1 hour → CAPTCHA or rate limited
• Scrape all public data via the API → rate limited

API7:2023 — Server Side Request Forgery

• POST /upload with URL http://localhost:8080/admin → validation
• POST /webhook with http://169.254.169.254/ → validation

API8:2023 — Security Misconfiguration

• CORS does not allow * for authenticated endpoints.
• Error responses don't include stack traces.
• Unnecessary HTTP methods (TRACE) are disabled.

API9:2023 — Improper Inventory Management

• /v1/ (old API version) should be deprecated and disabled.
• Fuzz for undocumented endpoints.
• Staging/dev environments should not be exposed.

API10:2023 — Unsafe Consumption of APIs

• Validate third-party API responses.
• Enforce SSL/TLS verification.
• Store third-party API keys securely.

Authentication test matrix

Authorization tests (the most critical)

A hands-on authorization test (Postman)

// Get token as admin
const adminToken = pm.sendRequest({
  url: 'https://api.example.com/auth/login',
  method: 'POST',
  body: { mode: 'raw', raw: JSON.stringify({ email: 'admin@example.com', password: 'adminpass' }) }
}).json().token;

// Get token as regular user
const userToken = pm.sendRequest({
  url: 'https://api.example.com/auth/login',
  method: 'POST',
  body: { mode: 'raw', raw: JSON.stringify({ email: 'user@example.com', password: 'userpass' }) }
}).json().token;

// Regular user hits admin endpoint → expect 403
const response = pm.sendRequest({
  url: 'https://api.example.com/admin/users',
  method: 'GET',
  header: { 'Authorization': 'Bearer ' + userToken }
});

pm.test("Regular user cannot access admin endpoint", () => {
  pm.expect(response.code).to.equal(403);
});

SQL injection test cases

# Try SQL injection in login
curl -X POST https://api.example.com/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@example.com'\'' OR '\''1'\''='\''1","password":"x"}'

# Expected: 400 Bad Request (not 200, not 500)

XSS (Cross-Site Scripting) payloads

How to test: submit the payload in a comment, profile name or search box, then view the rendered HTML source — the script must be escaped or stripped, never executed.

CSRF (Cross-Site Request Forgery)

• Form submissions require a CSRF token.
• Cookies use SameSite=Lax or Strict.
• Referer header is validated for state-changing requests.

SSRF payloads

• http://localhost:8080/admin — internal access
• http://169.254.169.254/latest/meta-data/ — AWS metadata
• file:///etc/passwd — local file
• http://internal-service.company.local — internal DNS

Burp Suite is the de facto standard for manual security testing. The Community Edition is free. Download from portswigger.net/burp.

Configure your browser

1. Install FoxyProxy or use Burp's built-in browser.
2. Set proxy to 127.0.0.1:8080.
3. Install Burp's CA certificate in your browser (for HTTPS interception).

Intercept and modify requests

1. Open Burp → Proxy → Intercept.
2. Browse the application normally — Burp captures every request.
3. Click any request to view and modify it.
4. Forward modified requests to see how the server responds.

Use the Repeater

1. Right-click any request → Send to Repeater.
2. Modify the request (add SQL injection payload, change user ID, etc.).
3. Click Send to test the modified request.

Sample workflow: testing BOLA

1. Log in as user A in your browser (proxied through Burp).
2. Navigate to /users/me/profile — Burp captures GET /users/me/profile.
3. Modify the URL to GET /users/123/profile.
4. Send to Repeater. If 200 → BOLA vulnerability. If 403 → secure.

Sample workflow: testing SQL injection

1. Log in as any user.
2. Search for a product: GET /api/products?q=laptop.
3. Modify q=laptop to q=laptop' OR '1'='1 and send via Repeater.
4. If all products are returned → SQL injection vulnerability.

OWASP ZAP is the open-source alternative to Burp Suite — free, with a full active scanner. Download from zaproxy.org.

Quick scan

1. Open ZAP → Quick Start → Automated Scan.
2. Enter the URL to scan and click Attack.
3. View the Alerts tab for findings.

What the active scanner covers

• SQL injection
• XSS (reflected, stored, DOM)
• Path traversal
• SSRF
• Broken authentication
• Security misconfiguration

Use ZAP as a CI/CD security gate

# Docker baseline scan
docker run -v $(pwd):/zap/wrk:rw \
  owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.example.com \
  -r zap-report.html

Or with the official GitHub Action:

- name: ZAP Baseline Scan
  uses: zaproxy/action-baseline@v0.7.0
  with:
    target: 'https://staging.example.com'
    rules_file_name: '.zap/rules.tsv'
    cmd_options: '-I'

The scan fails the build when it finds high-risk vulnerabilities.

SAST — Static Application Security Testing

Analyzes source code without running the app.

SCA — Software Composition Analysis

Scans third-party dependencies for known CVEs.

DAST — Dynamic Application Security Testing

Tests the running application.

GitHub Actions example

name: Security Scan
on: [push, pull_request]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run npm audit
        run: npm audit --audit-level=high

      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/owasp-top-ten

      - name: Run OWASP ZAP Baseline
        uses: zaproxy/action-baseline@v0.7.0
        with:
          target: 'https://staging.example.com'

For broader CI/CD patterns, see our Selenium WebDriver Guide and Playwright Complete Guide.

A great security bug report accelerates the fix and prevents the next breach. Use this template:

TITLE: [Severity] [Asset] [Vulnerability type] — [Impact]
Example: "[HIGH] /api/users/:id — Broken Object Level Authorization
allows access to other users' profiles"

SEVERITY: Critical / High / Medium / Low / Informational
CVSS SCORE: 7.5
OWASP CATEGORY: A01:2021 — Broken Access Control
CWE: CWE-639 (Authorization Bypass Through User-Controlled Key)

ASSET:
- URL: /api/users/:id
- Parameter: id
- Affected versions: 1.0.0 – 1.4.2

DESCRIPTION:
The /api/users/:id endpoint does not verify that the authenticated
user owns the requested resource. An authenticated user can access
any other user's profile by changing the :id parameter.

REPRODUCTION STEPS:
1. Log in as user A (id=123, token=<token_A>)
2. Send GET /api/users/124 with token_A
3. Observe: 200 OK with user B's profile data
4. Expected: 403 Forbidden

IMPACT:
An attacker who creates an account can enumerate and exfiltrate
all users' personal data (name, email, phone, address).

REMEDIATION:
Add an ownership check: the authenticated user ID must match the
requested user ID, or the user must have admin privileges.

REFERENCES:
- https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
- https://cwe.mitre.org/data/definitions/639.html

EVIDENCE:
[Attach screenshots, HTTP request/response logs, Burp screenshots]

Severity rating (CVSS-based)

For bug-report craft beyond security, read our Manual Testing Interview Questions.

Do

• Test every endpoint that takes an ID for BOLA (the #1 API vulnerability).
• Use OWASP ZAP or Burp Suite for hands-on security testing.
• Run SAST on every PR.
• Run SCA on every PR (npm audit, pip-audit).
• Run DAST weekly against staging.
• Add security tests to your regression suite.
• Threat-model every feature before implementation.
• Test authentication and authorization on every endpoint.
• Verify input validation for every input field.
• Stay current with OWASP Top 10 updates.

Don't

• Don't rely solely on automated scanners — they miss business-logic vulnerabilities.
• Don't test only the happy path.
• Don't skip security testing in dev environments — attackers don't care.
• Don't ignore "informational" findings — they often chain into real exploits.
• Don't put security testing in a separate sprint — it should be continuous.
• Don't share security findings publicly until the fix is shipped.

About the author: The SoftwareTestPilot Editorial Team is a group of QA practitioners with 40+ years of combined experience. We've shipped security-tested apps at banks, healthcare providers and SaaS platforms — and we've caught vulnerabilities that would have cost millions in remediation.

Practice security testing

Sharpen your hands-on skills on HackTheBox, TryHackMe, OWASP WebGoat or DVWA. For real-world experience, start with HackerOne or Bugcrowd bug bounty programs.

Continue your journey

• API Testing Tutorial — the API-specific security risks in depth
• Manual Testing Complete Guide — security-aware test design
• Playwright Complete Guide — automate UI security checks
• Selenium WebDriver Guide — security in CI/CD
• SDET Career Roadmap — security as a senior specialization
• QA Engineer Salary Guide — security specialists earn premium rates

Rehearse security and API rounds live in the AI Mock Interview, run your CV through the free Resume ATS Review, and join 11K+ testers in the QA Network for daily security questions and referrals.