Web Security Testing in Practice

Security Testing for QA Engineers #

Security testing is not just for penetration testers. QA engineers encounter security-relevant features daily: login forms, user input fields, API endpoints, and file uploads. Understanding common vulnerabilities and how to test for them makes you a more effective tester and helps prevent security breaches.

This lesson focuses on practical, hands-on security testing that QA engineers can perform without specialized tools.

The OWASP Top 10 #

The OWASP Top 10 is the most widely referenced list of web application security risks. The most relevant for QA testing:

Cross-Site Scripting (XSS) Testing #

Types of XSS #

Basic XSS Test Payloads #

Test these in every input field, search box, URL parameter, and user profile field:

<script>alert('XSS')</script>
"><script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
javascript:alert('XSS')
" onfocus="alert('XSS')" autofocus="

If any of these trigger a JavaScript alert, the application is vulnerable.

Where to Test for XSS #

• Search boxes (reflected in search results)
• Comment/review fields (stored XSS)
• User profile fields (name, bio, website URL)
• URL parameters (?q=<script>alert(1)</script>)
• File upload names
• Error messages that reflect user input

CSRF Testing #

How CSRF Works #

1. User is logged into bank.com
2. User visits malicious evil.com
3. evil.com has a hidden form that submits to bank.com/transfer?to=attacker&amount=1000
4. Browser automatically includes bank.com cookies
5. Transfer executes without user’s knowledge

Testing for CSRF Protection #

1. Find a state-changing action (change password, update profile, delete item)
2. Inspect the form — look for a hidden CSRF token field
3. Submit the form normally — it should work
4. Remove or modify the CSRF token — the request should be rejected
5. Replay the request from a different origin — it should be rejected

<!-- Check for CSRF token in forms -->
<form action="/api/change-password" method="POST">
  <input type="hidden" name="_csrf" value="abc123token">
  <!-- Without this token, the server should reject the request -->
</form>

SQL Injection Testing #

Basic SQL Injection Payloads #

Test in login forms, search fields, and URL parameters:

' OR '1'='1
' OR '1'='1' --
' UNION SELECT NULL--
'; DROP TABLE users--
1 OR 1=1

If any of these produce unexpected behavior (login bypass, error with SQL syntax, extra data), the application may be vulnerable.

Note: Modern frameworks with parameterized queries largely prevent SQL injection. However, custom queries and legacy code may still be vulnerable.

Security Headers Testing #

Check that security-related HTTP headers are set:

curl -I https://example.com

Sensitive Data Testing #

• No passwords visible in page source or network requests
• Credit card numbers masked in UI and logs
• Session tokens not in URL parameters (use cookies with HttpOnly and Secure flags)
• No sensitive data in browser localStorage (check Application tab)
• API responses do not include unnecessary sensitive fields

Exercise: Web Security Audit #

Perform a security-focused test of a web application’s authentication and user input handling.

Part 1: XSS Testing #

Test 5 input fields with XSS payloads:

Part 2: CSRF Testing #

Part 3: Security Headers #

curl -I https://your-site.com

Part 4: Authentication Security #

Security Testing Tools for QA #

Key Takeaways #

• QA engineers can and should perform basic security testing on every feature
• Test all user inputs for XSS — search boxes, profile fields, comments, URL parameters
• Verify CSRF protection on every state-changing action (forms, API calls)
• Check security headers with curl or browser DevTools on every deployment
• Never expose technical details in error messages — they help attackers
• Session cookies must have HttpOnly and Secure flags
• Use the OWASP Top 10 as a checklist for security-focused test planning