Alternate QA Hub
Back to Blog

Security Testing Fundamentals: What Every QA Engineer Should Know

AlternateQA Team•
Security is not just the job of a dedicated pentester. QA engineers are in a unique position to catch security vulnerabilities during regular testing. Learn the essential security testing concepts, techniques, and tools to integrate into your QA workflow.

Why QA Engineers Are Security's First Line of Defense

The traditional model of security testing involves hiring a penetration testing firm to run an annual assessment. By then, vulnerabilities have often been sitting in production for months. A more effective model treats security as a continuous quality concern, integrated into the development lifecycle.

QA engineers test applications every day. With a security mindset, those daily test sessions become an opportunity to catch vulnerabilities before they ship. You don't need to be a certified ethical hacker to make a significant security impact — understanding the OWASP Top 10 and applying security thinking to your existing testing activities is enough to raise the security bar dramatically.

The OWASP Top 10: Your Security Testing Syllabus

The Open Web Application Security Project (OWASP) publishes the "Top 10" — a consensus document listing the 10 most critical security risks for web applications. It's the most widely referenced security framework in the industry and the perfect starting point for QA engineers.

1. Broken Access Control

Can users access resources or perform actions they shouldn't? This is the #1 most common vulnerability.

Testing approach:

  • Log in as User A, navigate to a resource (e.g., /api/invoices/123). Log out, log in as User B, and try to access the same URL. Can User B see User A's invoice?
  • Try to access admin endpoints as a regular user.
  • Test vertical privilege escalation: Can a regular user perform admin actions by modifying their role in a request?
Test: GET /api/users/456/profile
As User with ID 123 (not 456)
Expected: 403 Forbidden
If Actual: 200 OK → Broken Access Control vulnerability!

2. Cryptographic Failures (Data Exposure)

Is sensitive data adequately protected?

Testing approach:

  • Check if all pages that handle sensitive data (login, payment, personal data) are served over HTTPS. HTTP is unacceptable for these pages.
  • Check browser storage (DevTools → Application → Storage): Are sensitive values like tokens, passwords, or PII stored in localStorage (unencrypted) when they shouldn't be?
  • Check API responses: Are responses returning more data than the UI displays? Are there undocumented fields like password_hash or internal IDs in the response?

3. Injection (SQL, Command, LDAP)

Can malicious data alter the application's queries or commands?

SQL Injection testing: Try these payloads in every input field, search box, and URL parameter:

  • ' OR '1'='1
  • '; DROP TABLE users; --
  • 1 AND 1=2

If the application returns different results, throws a database error, or behaves unexpectedly, it may be vulnerable to SQL injection.

Note: SQL injection on modern applications using parameterized queries/ORMs is rare, but legacy code and custom query-building remain vulnerable.

4. Insecure Design

Fundamental flaws in the application's design that cannot be patched — they require redesign.

Examples to look for:

  • Is there a rate limit on login attempts? (No rate limit → brute-force attack is trivial)
  • Does the password reset flow send a temporary link, or does it reset the password to something predictable?
  • Can users enumerate valid accounts by comparing "User not found" vs. "Incorrect password" error messages?

5. Security Misconfiguration

Default settings, verbose error messages, and unnecessary features left enabled.

Testing approach:

  • Trigger a server error (e.g., send an invalid JSON payload to an API). Does the error message reveal stack traces, framework versions, or database schema information? This is information disclosure.
  • Check HTTP response headers: Are security headers present?

Required HTTP Security Headers:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin

Use securityheaders.com to check any URL's headers for free.

6. Cross-Site Scripting (XSS)

Can an attacker inject malicious JavaScript that runs in another user's browser?

Testing approach: Try these payloads in any input that gets displayed back to users (comments, usernames, search terms, profile fields):

  • <script>alert('XSS')</script>
  • <img src="x" onerror="alert('XSS')">
  • javascript:alert('XSS')

If an alert box appears, or the script executes, the application is vulnerable to XSS.

7. CSRF (Cross-Site Request Forgery)

Can an attacker trick a logged-in user into performing an unwanted action?

Testing approach: Check whether state-changing API requests (POST, PUT, DELETE) include a CSRF token. If not, an attacker could craft a malicious webpage that submits a form to your application on behalf of a logged-in user.

Practical Security Testing Techniques

Authorization Testing Checklist

For every feature, systematically ask:

  • [ ] Can an anonymous user (not logged in) access this? They shouldn't be able to.
  • [ ] Can a low-privilege user access a resource that requires higher privilege?
  • [ ] Can User A access User B's private data by modifying an ID in the URL or request body?
  • [ ] Are all administrative endpoints protected against non-admin users?

Insecure Direct Object Reference (IDOR) Testing

IDOR is a specific type of broken access control. Look for sequential or predictable IDs in URLs and API requests:

  • GET /api/orders/1001, GET /api/orders/1002, GET /api/orders/1003
  • Change the ID to another user's order ID. Does it return their data?

Session Management Testing

  • Log out and verify the session token is invalidated on the server (the old token should no longer work).
  • Verify session tokens are rotated after login (session fixation prevention).
  • Check the session token length and randomness (short or sequential tokens are predictable).
  • Test session timeout: Does the session expire after inactivity?

Automated Security Testing Tools

SAST (Static Application Security Testing)

Analyzes code without running it:

  • Semgrep: Open-source SAST with rules for common vulnerabilities in many languages.
  • SonarQube: Includes security rules alongside code quality analysis.

DAST (Dynamic Application Security Testing)

Tests the running application from outside:

  • OWASP ZAP: Free, open-source web application security scanner. Can be run in CI/CD mode. Excellent starting point.
  • Burp Suite Community Edition: The professional's choice for manual security testing. Intercepts and modifies HTTP traffic between your browser and the server.
  • Nikto: Command-line web server scanner that checks for common vulnerabilities.

Running OWASP ZAP in CI/CD (GitHub Actions)

- name: OWASP ZAP Scan
  uses: zaproxy/action-baseline@v0.9.0
  with:
    target: 'https://staging.myapp.com'
    fail_action: false  # Set to true to block PRs with issues
    artifact_name: 'zap-report'

Building a Security Testing Mindset

Security testing is ultimately about thinking adversarially. Ask yourself: "If I were trying to break this, how would I do it?" Common adversarial questions:

  • What happens if I manipulate this hidden form field?
  • What if I send a request without the authentication token?
  • What if I change userId=123 in the URL to userId=456?
  • What if I upload a file with a dangerous extension (.exe, .php) where only images are expected?
  • What if I send a request for 10,000 items when the normal page size is 20?
  • What if I replay an old authentication token?

Security testing doesn't require a dedicated security team or external consultants to get started. By adding security checks to your existing functional testing, you can find and prevent a significant proportion of common vulnerabilities. The key is to make security thinking a habit, not a checklist.