OWASP Top 10 for QA Engineers — Security Testing Guide

Why Every QA Engineer Needs to Know OWASP

Security is no longer the exclusive domain of penetration testers and security engineers. In modern Agile and DevSecOps teams, QA engineers are the last line of defence before code ships to production. Understanding the OWASP Top 10 — the authoritative list of the most critical web application security risks — transforms a functional tester into a security-aware quality engineer.

The OWASP Top 10 (2021 edition) is maintained by the Open Web Application Security Project, a non-profit foundation dedicated to improving software security. It is updated every three to four years based on real-world vulnerability data from hundreds of contributing organizations. If your application ships with any of these ten vulnerabilities, the impact ranges from data leakage to full system compromise.

This guide covers each of the ten categories through a QA lens: what the vulnerability is, a real-world example of how it has been exploited, and the concrete test cases you should be running on every sprint. By the end of this article you will have a security testing checklist you can bring into any project immediately.

Attack Surface Architecture

Before diving into individual vulnerabilities, it helps to visualize the layers an attacker targets and where QA testing fits into that picture.

A01 — Broken Access Control

What it is: The application does not properly enforce restrictions on what authenticated users are allowed to do or access, allowing them to act outside their intended permissions.

Real-world example

In 2019, a major US financial institution exposed customer tax documents because the API endpoint /api/documents?userId=12345 performed no server-side ownership check — any authenticated user who changed the userId parameter could retrieve another customer's documents. This is a classic IDOR (Insecure Direct Object Reference) under A01.

What QA should test

• After logging in as User A, capture a request that references a resource owned by User A (e.g., /api/orders/8001). Log in as User B and replay that exact request — the response must be 403 Forbidden, not 200 OK with User A's data.
• Attempt to access admin-only endpoints (/admin/users, /admin/settings) while authenticated as a regular user — expect 403.
• Test horizontal privilege escalation: can a standard user perform actions reserved for premium users by manipulating the request?
• Test vertical privilege escalation: can a standard user perform actions reserved for admins by modifying role or permission parameters in the request body?
• Verify that unauthenticated requests to protected endpoints return 401, not a redirect that could leak data in the response body.
• Test CORS policy: send cross-origin requests from an unauthorized domain and verify the server rejects them.

A02 — Cryptographic Failures

What it is: Sensitive data is transmitted or stored without adequate encryption, or weak/deprecated cryptographic algorithms are used, exposing data to attackers who can intercept or retrieve it.

Real-world example

LinkedIn's 2012 breach exposed 6.5 million password hashes — all using unsalted SHA-1, which is trivially crackable with rainbow tables. By 2016, the full 117 million records were posted publicly. The entire breach was enabled by cryptographic failure at the storage layer.

What QA should test

• Verify all traffic is served over HTTPS. Use curl -I http://example.com and confirm a 301/302 redirect to HTTPS — never a 200 on plain HTTP.
• Check that the TLS version is at least 1.2. Use nmap --script ssl-enum-ciphers -p 443 example.com to verify no SSLv3 or TLS 1.0/1.1 is supported.
• Inspect API responses for sensitive fields (SSN, credit card numbers, passwords, tokens) — they must never appear in plaintext responses or logs.
• Verify cookies containing session tokens have the Secure and HttpOnly flags set.
• Check that password reset tokens in emails are long, random, and single-use.
• Confirm that database backup files and environment config files containing secrets are not accessible via the web root (/backup.sql, /.env must return 404, not 200).

A03 — Injection

What it is: User-supplied data is sent to an interpreter (SQL, OS shell, LDAP, XML parser) without sanitization, allowing attackers to execute unintended commands or access unauthorized data.

Real-world example

The 2008 Heartland Payment Systems breach — at the time the largest credit card data breach in history — was initiated via SQL injection in a web form. Attackers injected SQL into an authentication field, bypassed login, and installed malware on internal servers, ultimately capturing 130 million card numbers.

What QA should test

• SQL injection: in every text input that queries a database, submit ' OR '1'='1 and '; DROP TABLE users; --. The application must return a generic error, never SQL error details or unexpected data.
• NoSQL injection: for MongoDB-backed endpoints, submit {"$gt": ""} as a field value in JSON bodies. A vulnerable app will treat this as a query operator and return all records.
• Command injection: in fields that pass values to shell commands (file uploads, report generation), submit ; ls -la / or && cat /etc/passwd. Expect rejection, not command output.
• LDAP injection: in login forms backed by LDAP, submit *)(uid=*))(|(uid=* — a vulnerable app will authenticate without a real password.
• Cross-site scripting (stored and reflected): submit <script>alert(1)</script> into every input field that is later displayed to users. The script must be escaped in the output, never executed.
• Verify that the application uses parameterized queries or prepared statements (this can be confirmed via code review in conjunction with testing).

A04 — Insecure Design

What it is: Security weaknesses arising from flawed application design and architecture — not implementation bugs — such as missing threat modelling, incorrect trust boundaries, or business logic flaws that cannot be patched after deployment.

Real-world example

A ride-sharing application allowed users to book rides on behalf of other accounts by knowing only the target user's phone number — no secondary verification required. This was not a code bug; it was a design decision that did not account for account takeover via social engineering. Fixing it required redesigning the booking flow entirely.

What QA should test

• Test business logic flows for shortcuts: can a user skip step 2 of a multi-step checkout and go directly to step 4? The application must validate each state server-side.
• Test rate limiting on sensitive actions: password reset requests, OTP generation, account creation. Without limits, these become brute-force vectors.
• Verify that the "forgot password" flow does not reveal whether an email address is registered (prevents user enumeration).
• Test coupon and discount logic for manipulation: applying the same coupon code twice, negative quantities, zero-price orders.
• Confirm that API workflows enforce correct state transitions — a finalized order cannot be modified, a shipped item cannot be cancelled without authorization.

A05 — Security Misconfiguration

What it is: Default configurations, unnecessary features, open cloud storage, verbose error messages, or missing security hardening leave the application or its infrastructure unnecessarily exposed.

Real-world example

In 2017, Uber suffered a breach when attackers found AWS credentials accidentally pushed to a public GitHub repository. The credentials gave access to an S3 bucket containing 57 million user and driver records. The misconfiguration was not in the application code but in the deployment and secret management practices.

What QA should test

• Access common default paths: /admin, /phpinfo.php, /.git/, /swagger-ui.html — these must return 404 or 403 in production.
• Trigger an intentional error (e.g., invalid JSON body, malformed URL) and verify that error responses do not expose stack traces, framework versions, or internal file paths.
• Check HTTP response headers: Server and X-Powered-By headers must not reveal technology versions.
• Test that CORS is not set to Access-Control-Allow-Origin: * on authenticated endpoints.
• Verify that debug/development endpoints (/debug, /actuator/env) are disabled in staging and production.
• Confirm S3 buckets, blob containers, or storage accounts referenced by the application are not publicly listable.

A06 — Vulnerable and Outdated Components

What it is: The application uses libraries, frameworks, or other software components with known vulnerabilities, either because they have not been updated or because the team is unaware of which versions are in use.

Real-world example

The 2017 Equifax breach, which exposed 147 million people's personal and financial data, was traced directly to a known vulnerability in Apache Struts (CVE-2017-5638) that had a published patch available for two months before exploitation. The application had not been updated.

What QA should test

• Run pip audit (Python) or npm audit (Node.js) against the project and fail the build if any high-severity CVEs are present. Make this part of CI.
• Check that the project has a dependency scanning tool in the pipeline (Snyk, Dependabot, OWASP Dependency-Check).
• Verify that JavaScript libraries loaded from CDNs use Subresource Integrity (SRI) hashes: <script src="..." integrity="sha256-..." crossorigin="anonymous">.
• Audit Docker base images with docker scout cves IMAGE or Trivy for OS-level vulnerabilities.

A07 — Identification and Authentication Failures

What it is: Weaknesses in authentication mechanisms that allow attackers to compromise passwords, session tokens, or user identity — including weak credential policies, insecure session management, and missing multi-factor authentication.

Real-world example

The 2020 Twitter hack, in which high-profile accounts including Obama's, Biden's, and Musk's were compromised to run a Bitcoin scam, exploited weak internal admin tooling with no MFA. Attackers gained access via social engineering of Twitter employees who had access to an internal admin portal with single-factor authentication.

What QA should test

• Brute force protection: submit 10+ incorrect password attempts and verify the account is locked or CAPTCHAed. Test that the lockout cannot be bypassed by changing the case of the username or adding whitespace.
• Session fixation: log in and capture the session token. Log out. Log back in. Verify the session token has changed — the old token must be invalidated.
• Session timeout: leave an authenticated session idle for the configured timeout period (e.g., 30 minutes). Attempt an action — it must fail with a session expired response.
• Token entropy: if JWT tokens are used, decode the header and payload (base64) and verify the algorithm is not none and the token contains no sensitive unencrypted data.
• Verify that "Remember Me" tokens stored in cookies are long, random, and rotated after use.
• Confirm that all password reset, email verification, and MFA flows use time-limited, single-use tokens.

A08 — Software and Data Integrity Failures

What it is: Code and infrastructure that does not protect against integrity violations — for example, using untrusted plugins or libraries, insecure CI/CD pipelines, or auto-update mechanisms that do not verify the integrity of downloaded packages.

Real-world example

The SolarWinds attack (2020) compromised the software build pipeline of SolarWinds' Orion product. Attackers inserted malicious code into the legitimate software update that was then cryptographically signed and distributed to 18,000 customers, including US government agencies. The attack was a supply chain integrity failure at the CI/CD level.

What QA should test

• Verify that software packages downloaded during CI/CD use pinned, verified checksums rather than "latest" tags.
• Check that the CI/CD pipeline has no steps that download and execute scripts from external URLs without hash verification (e.g., curl https://external-site.com/install.sh | bash).
• Test that deserialization endpoints reject unexpected object types. Send a serialized object of an unexpected class and verify rejection, not silent acceptance.
• Verify that file upload endpoints validate file type by MIME type and magic bytes, not just the file extension provided by the client.

A09 — Security Logging and Monitoring Failures

What it is: Insufficient logging, monitoring, and alerting means that breaches go undetected, attackers can cover their tracks, and incident response is impaired because there is no audit trail.

Real-world example

The 2013 Target breach, in which 40 million credit card records were stolen, went undetected for three weeks despite the company's security vendor sending alerts. The alerts were ignored due to alert fatigue caused by poor signal-to-noise ratio in their monitoring — a monitoring failure compounding a logging failure.

What QA should test

• Perform a failed login attempt and confirm the event appears in application logs with timestamp, username (or hash), source IP, and outcome — but never the attempted password.
• Attempt an access control violation (access another user's resource) and verify that the 403 event is logged with sufficient context for forensic investigation.
• Confirm that logs do not contain sensitive data: credit card numbers, passwords, session tokens, or PII must be masked or excluded.
• Verify that log entries cannot be injected with newlines or CRLF sequences to forge log records (log injection attack).
• Confirm that a monitoring alert or SIEM rule exists for repeated 401/403 responses from the same IP — the telltale signature of a credential stuffing or enumeration attack.

A10 — Server-Side Request Forgery (SSRF)

What it is: The server fetches a remote resource based on user-supplied input without validating the target URL, allowing attackers to make the server send requests to internal services, cloud metadata endpoints, or other unintended destinations.

Real-world example

The 2019 Capital One breach, which exposed over 100 million customer records, was carried out via SSRF against the AWS EC2 metadata endpoint (http://169.254.169.254/). The attacker used a misconfigured WAF to make the server query the metadata endpoint, retrieve IAM credentials, and use those credentials to access S3 buckets containing customer data.

What QA should test

• In any feature that accepts a URL (webhook URLs, image URLs, PDF generators, link preview features), submit http://169.254.169.254/latest/meta-data/ (AWS metadata). The server must not return EC2 metadata.
• Submit http://localhost/admin or http://127.0.0.1:8080/internal-api and verify the server rejects it, not proxies it.
• Test with http://0.0.0.0/, http://[::1]/ (IPv6 loopback), and common internal RFC-1918 ranges (http://192.168.1.1).
• If the application has a URL-fetching allowlist, verify that DNS rebinding cannot bypass it (the initial DNS lookup resolves to an allowed host, then rebinds to an internal IP).
• Confirm that the server's outbound request logic uses a network-level deny list for private IP ranges, not just application-level filtering.

Security Testing Approaches: SAST vs DAST vs Pen Testing vs Bug Bounty

OWASP vulnerabilities can be caught at different stages using different methodologies. Understanding which approach is appropriate for which phase of the SDLC is a critical skill for security-aware QA engineers.

QA Security Testing Checklist

Use this checklist as a minimum baseline on every sprint that ships new features or modifies auth/data flows:

Security testing is a craft that improves with practice. Start by running through this checklist on one feature per sprint. Over time, it becomes muscle memory and your instinct for suspicious code paths sharpens significantly. The ten categories above cover the vast majority of real-world vulnerabilities — master them and you will be a far more valuable quality engineer than one who only tests the happy path.