Security Testing Basics: Think Like a Hacker, Test Like a QA

Part of the “10 Days of QA — From Beginner to Expert”

Intro — You can build the fastest, most stable application in the world, but if someone can access another user’s data or bypass login with a simple trick — it’s game over. Security testing isn’t about paranoia; it’s about protecting trust. As a QA, you don’t have to be a hacker — but you must think like one.

1️⃣ The Mindset: QA vs Hacker

Hackers are curious by nature. They don’t just click buttons — they ask, “What happens if I don’t follow the rules?” A QA should ask the same. When a login says, “Enter your email,” a hacker wonders, “What if I inject something else?” That curiosity — controlled, ethical, and purposeful — is what makes you a better QA engineer.

⚡ QA Tip: The best security testers are those who care about user safety as much as user experience.

2️⃣ What Is Security Testing?

Security testing ensures your application’s data and behavior are protected against threats like unauthorized access, data leaks, or malicious inputs.

• ✅ Verify data confidentiality — no one sees what they shouldn’t.
• ✅ Ensure integrity — data can’t be modified unnoticed.
• ✅ Maintain availability — system remains usable even under attack.
• ✅ Validate authentication and authorization controls.

For QA teams, it’s not about hacking — it’s about validation and awareness. You verify how well defenses hold up against real-world misuse.

3️⃣ The OWASP Top 10 — QA’s Starter Map

The OWASP Top 10 is a global standard for common web security risks. Here are the ones every QA should know:

1. Broken Authentication — weak login or session handling
2. Injection — unfiltered input (SQL, command, LDAP)
3. Cross-Site Scripting (XSS) — malicious JS injected into the UI
4. Insecure Direct Object Reference (IDOR) — access to others’ data via predictable IDs
5. Security Misconfiguration — default creds, debug mode, open ports
6. Sensitive Data Exposure — storing passwords or tokens in plain text
7. Broken Access Control — role-based access missing or flawed
8. Insufficient Logging & Monitoring — missing traces of attack attempts

4️⃣ Real QA Scenario — The “Hidden” Admin Panel

In one of my early projects, a QA casually typed /admin at the end of the URL. To everyone’s surprise, an internal dashboard appeared — no login required. It wasn’t malicious intent, just curiosity — but it revealed a major flaw. That’s what being a good QA is about: not assuming “it must be secure,” but checking, calmly and responsibly.

5️⃣ Tools Every QA Should Know

• Burp Suite (Community Edition) — Intercept HTTP requests and modify data between browser and server.
• OWASP ZAP — Great free alternative for scanning vulnerabilities.
• Postman — For API security testing (auth, token leaks, headers).
• Browser DevTools — Inspect cookies, headers, and scripts.
• Dirbuster / ffuf — To check hidden directories (for advanced users).

6️⃣ Safe Example: Testing for SQL Injection

Let’s say your login form sends this POST request:

POST /login
Content-Type: application/json
{
  "username": "admin",
  "password": "password123"
}

A curious QA might test with harmless variations:

{
  "username": "admin' --",
  "password": "anything"
}

If the system lets you log in — the backend likely isn’t escaping SQL input properly. You just found a potential SQL Injection vulnerability. (Note: Always test in staging or QA environments — never in production.)

7️⃣ XSS — Cross-Site Scripting

XSS happens when the app displays user input without sanitizing it. For example:

<script>alert('Hacked!')</script>

If a comment box or profile name field displays this as an alert, your app is vulnerable. It might seem small — but in real cases, attackers use this to steal cookies or tokens.

Mentor Note: XSS is not about “funny pop-ups.” It’s about stolen sessions, hijacked users, and brand damage.

8️⃣ Broken Authentication — When Sessions Misbehave

Try these in QA environments:

• After logout, press browser back — does the dashboard still show?
• Copy your session token, paste in another browser — still works?
• Does the password reset email reveal internal system info?

Each of these tests validates how secure your authentication really is.

9️⃣ API Security Testing with Postman

Most modern apps rely on APIs — so do hackers. Test your endpoints for:

• Unsecured methods (e.g., DELETE open to anyone)
• Missing auth headers
• Predictable IDs in URLs (e.g., /user/123 vs /user/{{token}})
• Sensitive info in response bodies

Example:

// Unauthenticated GET
GET /users/123
Authorization: none

If you still get user data, that’s an IDOR — a data leak waiting to happen.

🔟 Secure Headers to Check

Use browser DevTools → Network tab → Response headers. Look for:

• Content-Security-Policy — helps prevent XSS
• Strict-Transport-Security — enforces HTTPS
• X-Frame-Options — stops clickjacking
• Set-Cookie: HttpOnly; Secure — prevents cookie theft

1️⃣1️⃣ Reporting Security Issues Responsibly

When you find something sensitive, don’t share it in screenshots or Slack groups. Use private issue trackers, anonymize data, and follow your organization’s disclosure policy. Security testing is about safety, not showmanship.

1️⃣2️⃣ Automating Security Scans

You can integrate OWASP ZAP or Burp into CI pipelines for nightly scans:

name: Security Scan
on: [push]
jobs:
  zap:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run OWASP ZAP Baseline Scan
        run: docker run -t owasp/zap2docker-stable zap-baseline.py -t https://staging.example.com

1️⃣3️⃣ Common Security Gaps Found by QAs

• Forgotten admin endpoints (like /test, /admin)
• Plaintext credentials in console logs
• Debug error messages showing SQL traces
• APIs exposing internal IPs or system versions
• No rate-limiting on login attempts

1️⃣4️⃣ Hands-On Mini Exercise

Try this (safely in QA environment):

1. Use Postman or ZAP to call a few APIs with invalid tokens.
2. Try URL variations like /users/1 and /users/2.
3. Look for data leaks or unhandled 500 errors.
4. Document findings and suggest validations to devs.

1️⃣5️⃣ Mindset Shift: QA as the Guardian of Trust

Being a QA is not about breaking systems — it’s about protecting them from being broken by others. You are the first ethical hacker your users never meet. Your curiosity keeps their data safe.

1️⃣6️⃣ Recap

• 🧠 Learn OWASP Top 10 — your baseline knowledge.
• 🛠️ Use Burp, ZAP, Postman to explore hidden flows.
• 🧩 Validate APIs and sessions — not just UI screens.
• 📜 Always report securely and ethically.

© Bugged_But_Happy· All Rights Reserved

#SecurityTesting #OWASP #BurpSuite #Postman #QualityAssurance