Security Testing
One missed authorization check can expose a million patient records. Learn how to find security holes before attackers do.
1 The Hook — Why This Matters
In 2020, a New Zealand district health board rolled out a new patient portal. The system allowed clinicians to view records, prescribe medication, and update allergy information. During a routine security review after launch, a penetration tester discovered that changing the patient_id parameter in the URL gave access to any patient's records. There was no server-side authorization check.
The vulnerability existed for eleven weeks. During that window, an estimated 4,000 patient records were accessible without authentication beyond a single clinician login. The Privacy Commissioner opened an investigation. Under the Privacy Act 2020, the DHB was required to notify affected individuals within 72 hours of discovery. The reputational damage and remediation costs ran into the millions.
The defect was not a complex cryptographic failure. It was a missing access control check — something a structured security test plan would have caught in the first week of testing.
2 The Rule — The One-Sentence Version
Security is not a phase; it is a constraint that must be validated at every layer.
You cannot bolt security onto a finished product. If you only run a vulnerability scan two days before release, you are not doing security testing. You are doing security theatre. Real security testing starts in design, continues through every build, and never stops in production.
3 The Analogy — Think Of It Like...
Airport security with multiple checkpoints.
You don't secure an airport with a single metal detector at the gate. You have perimeter fencing, ID checks at the door, bag screening, body scanners, and air-marshals on the plane. Each layer catches threats the others miss. Security testing works the same way: threat modelling is the fence, SAST is the bag scan, penetration testing is the red-team exercise, and logging is the CCTV that catches what still slips through. Relying on only one layer is how breaches happen.
4 Watch Me Do It — Step by Step
Here is a real NZ example: security testing a health records system. Follow these steps on any system that handles sensitive data.
-
Threat model with STRIDE
Before writing a single test case, identify what can go wrong. STRIDE gives you six categories:
- Spoofing — Fake clinician credentials
- Tampering — Modifying a prescription dosage
- Repudiation — A clinician denies accessing a record
- Information Disclosure — Patient data leaked to unauthorised users
- Denial of Service — System flooded until ambulances can't access records
- Elevation of Privilege — Patient account gains admin rights
- Review security requirements Map requirements to OWASP ASVS levels. For a health system, Level 2 (standard application security) is the minimum. Verify that authentication, session management, access control, and input validation are all specified before code is written.
- Run automated vulnerability scanning Use OWASP ZAP or Burp Suite to scan the running application. Automated tools catch known vulnerabilities quickly: SQL injection points, XSS vectors, and misconfigured headers. Record every finding with severity and CVSS score.
-
Perform manual penetration testing
Automated scanners cannot test business logic. A human tester verifies that changing
patient_idin the URL is blocked, that prescription limits are enforced server-side, and that audit logs capture every access attempt. - Review code for security patterns (SAST) Static analysis checks source code for dangerous patterns: unsanitised SQL queries, hard-coded secrets, weak cryptography, and insecure deserialization. Run SAST in the CI/CD pipeline so defects are caught before merge.
- Scan dependencies for known vulnerabilities (SCA) A modern application is 80% third-party libraries. Use dependency scanning to detect known CVEs in open-source packages. A vulnerable version of Log4j or OpenSSL is a breach waiting to happen.
- Verify logging and monitoring Security is not just prevention; it is detection. Verify that failed logins, access denials, and suspicious input patterns are logged with enough detail to support incident response. If you cannot detect a breach, you cannot respond within 72 hours.
| Threat | Test case | Expected result |
|---|---|---|
| Injection | SQL injection in patient search field | Input sanitised; no unauthorised data returned |
| XSS | JavaScript payload in clinical notes | Output encoded; script does not execute |
| Broken Access Control | Clinician A accesses Patient B's records | 403 Forbidden; access denied and logged |
| Audit Logging | View prescription history | Event recorded with user ID, timestamp, patient ID |
| Session Management | Reuse session token after logout | Token invalidated; request rejected |
5 When to Use It / When NOT to Use It
✅ Use security testing when...
- The system processes personal information (health, financial, identity)
- There are role-based access controls or multi-tenancy
- The application is internet-facing or has public APIs
- Regulatory frameworks apply (Privacy Act 2020, NZISM, RBNZ)
- You are handling payment data, IRD numbers, or ACC claims
❌ Don't treat security testing as...
- A replacement for secure coding practices and developer training
- A one-time gate before release instead of a continuous activity
- A substitute for infrastructure hardening or network segmentation
- Sufficient on its own if the system has no authorization logic to test
- A checkbox to satisfy auditors without fixing findings
Before you plan security testing, ask:
- Do you have threat models or a documented list of assets worth protecting?
- Does your team have security skills, or will you need a specialist or third-party tester?
- Are there compliance frameworks (OWASP Top 10, NZ Information Security Manual) you must align with?
- Will security testing be continuous (every sprint) or gated (before release), and who owns fixing findings?
6 Common Mistakes — Don't Do This
🚫 Leaving security testing to the end of the project
I used to think: Security is the final quality gate before go-live.
Actually: A vulnerability found in the last week cannot be fixed without slipping the release or shipping a hotfix. Shift-left: run SAST in CI/CD, threat-model during design, and review security requirements before coding starts. The earlier you find a security defect, the cheaper it is to fix.
🚫 Relying only on automated scans
I used to think: If OWASP ZAP reports zero alerts, the application is secure.
Actually: Automated scanners find known vulnerabilities in generic patterns. They cannot test business logic flaws, race conditions in payment flows, or authorization gaps that depend on your specific data model. Automated scanning is necessary but never sufficient. Always pair it with manual penetration testing.
🚫 Skipping threat modelling
I used to think: Testing every OWASP Top 10 category is comprehensive enough.
Actually: OWASP gives you a generic checklist. STRIDE threat modelling gives you your system's specific risks. Without threat modelling, you are testing in the dark. You might test for SQL injection while missing that your mobile app caches patient data unencrypted on the device. Context matters.
When this technique fails
Security testing fails when it is treated as a compliance checkbox rather than a continuous practice. Vulnerabilities found days before release cannot be fixed without emergency patching. It also fails when automated scans are the only testing: they miss business logic flaws, authorization gaps, and domain-specific risks. Finally, without threat modelling, testing is unfocused and may miss the assets most worth protecting.
7 Now You Try — Interview Warm-Up
Scenario: An NZ online pharmacy allows registered users to upload prescriptions and order medication. The application has login, upload, search, and checkout features. A junior tester has run OWASP ZAP and found zero alerts. They claim the site is "secure."
Question: List three security tests that ZAP cannot perform, but a manual tester should.
Three tests ZAP cannot perform:
- Business logic authorization: Can User A view User B's prescription history by changing an order ID in the URL? ZAP does not understand your domain model.
- Prescription validation bypass: Can a user upload a fake PDF and order restricted medication without a valid prescription? This requires domain knowledge that a scanner lacks.
- Session fixation after password change: If a user changes their password, do old sessions remain valid? ZAP does not test session lifecycle logic specific to your authentication flow.
Tip: In interviews, always mention that automated tools catch syntax-level vulnerabilities, but business logic and authorization require human testers who understand the domain.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. What is the difference between vulnerability scanning and penetration testing?
Vulnerability scanning uses automated tools to detect known vulnerabilities against a database of signatures (CVEs, misconfigurations). It is fast and scalable but cannot find business logic flaws. Penetration testing simulates real attacker behaviour, including chaining vulnerabilities, social engineering, and exploiting domain-specific logic. Pen testing finds what scanners miss but requires skilled humans and more time.
Q2. Name three NZ regulatory frameworks that influence security testing scope.
The Privacy Act 2020 mandates breach notification within 72 hours and requires reasonable safeguards for personal information. The NZ Information Security Manual (NZISM) defines security controls for government agencies. The Reserve Bank of New Zealand (RBNZ) cyber resilience standards require financial institutions to maintain robust security testing and incident response capabilities.
Q3. Why is SAST not enough on its own?
SAST (Static Application Security Testing) analyses source code for dangerous patterns but cannot detect runtime issues: misconfigured servers, missing security headers, race conditions, or flaws in third-party integrations. It also produces false positives that waste time if not triaged. SAST must be combined with DAST (dynamic scanning), dependency scanning, and manual testing for complete coverage.
9 Interview Prep — What They'll Ask
These are real questions from Test Lead interviews in the NZ market. Click to reveal a strong answer.
Q1. What's the difference between vulnerability scanning and penetration testing?
Vulnerability scanning is automated. It finds known issues quickly and cheaply but misses business logic flaws. Penetration testing is manual and simulates real attacks, including social engineering, privilege escalation chains, and domain-specific abuse. I use scanning for continuous baseline monitoring and pen testing quarterly or after major releases. Both are necessary; neither is sufficient alone.
Q2. How do you prioritise which security findings to fix first?
I use a composite score combining CVSS severity, exploitability in our environment, and business impact. A critical vulnerability on an internal admin panel with IP whitelisting may be lower priority than a medium vulnerability on a public API handling payment data. I also consider whether the vulnerability is actively exploited in the wild. The goal is risk reduction, not checklist completion.
Q3. How do you convince a product owner to invest in security testing?
I translate security risk into business language: breach notification costs under the Privacy Act, reputational damage, customer churn, and regulatory fines. I show them a recent NZ example and calculate the cost of fixing a defect in production versus during development. If they still resist, I propose a phased approach: threat model first (low cost, high value), then add automated scanning, then manual testing.
Q4. What is "shift-left" security and how do you implement it?
Shift-left means moving security activities earlier in the SDLC. I implement it by adding security requirements to user stories, running SAST in CI/CD before merge, threat-modelling during design reviews, and training developers in secure coding. The earlier a security defect is found, the cheaper it is to fix. A defect found in design costs minutes; the same defect found in production costs days and regulatory exposure.