Why Security Testing Matters for QA
Security breaches cost companies an average of $4.45 million per incident (IBM Cost of a Data Breach Report, 2023). Beyond financial impact, breaches destroy customer trust, trigger regulatory penalties, and can end careers.
As a QA engineer, security testing is your responsibility. You do not need to be a certified ethical hacker, but you must understand security principles well enough to catch common vulnerabilities before they reach production. Many of the most damaging breaches in history were caused by simple, preventable issues — missing input validation, default passwords, exposed API keys — that a security-aware QA engineer would have caught.
The CIA Triad
The CIA triad is the foundation of information security. Every security requirement maps to one of these three properties.
Confidentiality
Data should only be accessible to authorized users.
What to test:
- Can users access data belonging to other users? (IDOR — Insecure Direct Object Reference)
- Is sensitive data (passwords, tokens, PII) encrypted at rest and in transit?
- Are API responses leaking more data than necessary?
- Does the application expose sensitive information in error messages, logs, or URLs?
- Are there authorization checks on every API endpoint?
Integrity
Data should not be tampered with — accidentally or maliciously.
What to test:
- Can users modify data they should not have write access to?
- Is input validated on the server side (not just client side)?
- Are database records protected from SQL injection?
- Can API requests be tampered with in transit (man-in-the-middle)?
- Are checksums or signatures used for critical data?
Availability
Systems should be accessible when users need them.
What to test:
- Can the system be crashed by a single malformed request (DoS)?
- Are there rate limits to prevent abuse?
- Does the system handle resource exhaustion gracefully?
- Are there backup and recovery mechanisms?
- Can a single component failure take down the entire system?
Types of Security Testing
| Type | What It Does | Who Does It | When |
|---|---|---|---|
| Vulnerability Scanning | Automated scan for known vulnerabilities | QA team or DevOps | Every sprint/release |
| Penetration Testing | Manual attempt to exploit vulnerabilities | Security specialists | Quarterly or before major releases |
| Security Audit | Review of security controls and policies | Internal or external auditors | Annually or for compliance |
| Code Review | Manual inspection of source code for security flaws | Developers + security team | During development |
| SAST | Static Application Security Testing (automated code analysis) | CI/CD pipeline | Every commit |
| DAST | Dynamic Application Security Testing (runtime scanning) | CI/CD or QA | Every deployment |
| Threat Modeling | Systematic identification of potential threats | Architecture + security team | Design phase |
Vulnerability Scanning vs Penetration Testing
| Aspect | Vulnerability Scanning | Penetration Testing |
|---|---|---|
| Automation | Fully automated | Mostly manual |
| Depth | Broad but shallow | Narrow but deep |
| Frequency | Continuous (CI/CD) | Periodic (quarterly) |
| Skill needed | Low (run tools) | High (ethical hacking) |
| Output | List of potential vulnerabilities | Proof of exploitation |
| False positives | Common | Rare (validated manually) |
| Cost | Low | High |
Security Testing Mindset
The shift from functional to security thinking:
| Functional Mindset | Security Mindset |
|---|---|
| “Does the login form work?” | “Can I bypass the login form?” |
| “Can users submit the form?” | “Can I submit malicious data through the form?” |
| “Does the API return correct data?” | “Can I access other users’ data through the API?” |
| “Does file upload work?” | “Can I upload a malicious file that executes on the server?” |
| “Does search return results?” | “Can I inject SQL through the search field?” |
| “Does the session expire?” | “Can I hijack someone else’s session?” |
Common Vulnerability Categories
Authentication flaws:
- Default credentials left active
- No account lockout after failed attempts
- Weak password requirements
- Missing multi-factor authentication
- Insecure password reset flows
Authorization flaws:
- Horizontal privilege escalation (accessing another user’s data)
- Vertical privilege escalation (accessing admin features as a regular user)
- Missing function-level access control
- IDOR (manipulating IDs in URLs or API calls)
Input validation flaws:
- SQL injection
- Cross-site scripting (XSS)
- Command injection
- Path traversal
- XML external entity (XXE) attacks
Data exposure:
- Sensitive data in URLs or query parameters
- API responses containing unnecessary fields
- Error messages revealing system internals
- Lack of encryption for sensitive data
- Hardcoded credentials in source code
Security Testing as a QA Engineer
You do not need to be a penetration tester to add security value. Here are security checks every QA engineer should perform:
- Test authorization: Try accessing resources without authentication. Try accessing other users’ data by changing IDs in URLs.
- Test input validation: Enter special characters (
' " < > ; --), very long strings, and unexpected data types in every input field. - Check error messages: Ensure errors do not reveal stack traces, database names, file paths, or other system details.
- Verify HTTPS: Ensure all pages and API calls use HTTPS. Check for mixed content warnings.
- Test session management: Verify sessions expire, tokens are not predictable, and logout actually invalidates the session.
- Check headers: Look for security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security).
Exercise: Security Risk Assessment
Given a web application design, identify potential security risks across all three CIA triad dimensions.
Application: Online Banking Portal
Features: User login with email/password, account balance view, money transfers between accounts, transaction history, PDF statement download, profile settings with personal information.
Task
For each feature, identify:
- At least one confidentiality risk
- At least one integrity risk
- At least one availability risk
- The severity (Critical/High/Medium/Low)
- A recommended mitigation
Hint: Think Like an Attacker
For each feature, ask: “What if someone tries to…” - access without permission, modify data, send malicious input, overwhelm the system, intercept communications.
Solution: Security Risk Assessment
| Feature | CIA | Risk | Severity | Mitigation |
|---|---|---|---|---|
| Login | C | Brute force password guessing | Critical | Account lockout after 5 failed attempts + CAPTCHA |
| Login | I | Credential stuffing with leaked passwords | Critical | MFA, breached password checking (HaveIBeenPwned API) |
| Login | A | DoS attack on login endpoint | High | Rate limiting (10 req/min per IP) |
| Balance view | C | IDOR — changing account ID to view other accounts | Critical | Server-side authorization checking user-to-account ownership |
| Balance view | I | Cache poisoning showing wrong balance | Medium | Cache invalidation on balance change, integrity checks |
| Transfers | C | Transaction details visible in server logs | High | Redact sensitive fields in logs |
| Transfers | I | Race condition allowing double transfers | Critical | Database-level locking, idempotency keys |
| Transfers | A | Large batch transfer causing timeout | Medium | Queue-based processing, transaction limits |
| Transaction history | C | SQL injection in date filter revealing all users’ transactions | Critical | Parameterized queries, input validation |
| PDF download | C | Path traversal in PDF filename parameter | High | Whitelist allowed filenames, serve from isolated storage |
| PDF download | I | Injecting malicious content into generated PDF | Medium | Sanitize all user input in PDF templates |
| Profile | C | PII exposed in API response without need | Medium | Return only requested fields, mask SSN/DOB |
| Profile | I | XSS via name field displayed to support agents | High | Output encoding, Content-Security-Policy header |
Top 3 priorities: (1) IDOR on balance view, (2) Race condition on transfers, (3) SQL injection on transaction history.
Pro Tips
- Shift Left on Security: Integrate security testing into every sprint, not just before releases. Use SAST tools in CI/CD to catch vulnerabilities in code automatically.
- Learn to Use Burp Suite: Even basic Burp Suite skills (intercepting requests, modifying parameters, replaying requests) dramatically improve your security testing ability. The Community Edition is free.
- Keep an Eye on CVE Databases: Subscribe to CVE alerts for your technology stack. When a new vulnerability is published for a library you use, test whether your application is affected.
- Security Champions Program: Advocate for a security champion in each team — a developer or tester who takes extra security training and reviews security-sensitive changes.
- Never Test Security in Production: Security testing can cause damage (deleting data, locking accounts). Always use a dedicated test environment that mirrors production.