Home/ Techniques/ Senior/ Security Testing
Senior · Non-Functional Technique

Security Testing

Think like an attacker. Security testing isn't just for "hackers" — it's a critical skill for every senior tester to protect user privacy and company reputation.

Senior ISTQB CTAL-TA 4.2 — K3 Apply ~18 min read + exercise

1 The Hook — The "Open Door" Bug

Imagine a hotel with 100 rooms. You have a key for Room 101. You walk up to the door of Room 102, turn your key, and it works. You can see the guest's luggage, their laptop, and their passport. You haven't used any "hacker tools" — the hotel just has a broken lock system.

In software, this is called an **IDOR** (Insecure Direct Object Reference). It's the most common critical bug in the world. Security testing is checking every door in the "hotel" to make sure your key only opens your room.

2 The Rule — The CIA Triad

Every security check must verify Confidentiality, Integrity, or Availability.

  • Confidentiality: Only the right people can see the data (No leaking).
  • Integrity: Data cannot be changed by the wrong people (No tampering).
  • Availability: The system stays up when attacked (No crashing).

3 The Analogy — The Bank Vault

Analogy

The Door vs. The Gears.

When you look at a bank vault, you see a massive steel door (The UI). It looks impenetrable. But the actual security is in the Gears (The API and Database) hidden behind the wall. An attacker won't try to smash the door; they'll try to reach around the side and turn the gears directly. Security testing is looking past the "Steel Door" of the UI and testing the "Gears" underneath.

4 Watch Me Do It — Spoofing NZ RealMe

Scenario: You're testing a government portal that uses NZ RealMe for login. You want to see if you can "Spoof" (fake) a successful login.

  • The Normal Flow: User clicks "Login" → Goes to RealMe → Returns with a "Success Token."
  • The Attack Guess: "What if I bypass RealMe and just send a fake 'Success' message directly to the portal's callback URL?"
  • The Test: Manually trigger the /auth/callback?status=success URL without ever going to RealMe.
  • The Result: If the portal logs you in, it's a Critical Security Bug. The system must verify the token server-side, not just trust the URL.

5 Decision Tool — Functional vs. Security

✅ Functional Testing says...

  • "Can the user log in?"
  • "Does the button work?"
  • "Is the data correct?"

🕵 Security Testing says...

  • "What if I'm NOT the user?"
  • "What if I break the button?"
  • "Can I see OTHER people's data?"

6 Common Mistakes

🚫 Thinking HTTPS = "Secure"

I used to think: It has the green padlock, so the data is safe.
Actually: HTTPS only protects the data while it's moving (Transit). It doesn't stop a user from changing a URL ID to see someone else's data once it arrives. A padlock on a house doesn't matter if the back door is wide open.

🚫 Trusting the Frontend

I used to think: The UI hides the 'Delete' button for Juniors, so it's safe.
Actually: An attacker doesn't use your UI. They use tools like Postman to send a DELETE request directly to your API. Security must be enforced on the Server, not the Browser.

7 Now You Try — Spot the Vulnerability

🎯 Interactive Exercise

Scenario: You're logged into a NZ Banking app. Your URL is:

https://bank.resync.nz/account/view?id=8827

What is the first thing a security tester would try?

Changing the ID is the #1 way to find **IDOR** bugs.

8 Self-Check

Q1. What is the "OWASP Top 10"?

It is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

Q2. What is "Cross-Site Scripting" (XSS)?

It's when an attacker injects a malicious script (like <script>alert(1)</script>) into a field. If the system doesn't "sanitize" that input, the script will run in the browsers of other users who view that data.

9 Interview Prep

"How do you handle a critical security bug you found right before a release?"

Answer: "I immediately escalate it. In New Zealand, the Privacy Act 2020 requires organisations to protect personal data. Releasing a known IDOR or SQL injection could lead to a mandatory breach notification to the Privacy Commissioner. I would document the exact risk, prove it with a 'Proof of Concept', and recommend a 'No-Go' for the release until it's patched."