Senior · Security-Focused Technique

Advanced Security Testing

Q: Q1. What is the difference between SAST and DAST in security testing?

SAST (Static Application Security Testing) analyses source code without executing it — it finds issues like hardcoded secrets, injection-prone patterns, and insecure dependencies at build time. DAST (Dynamic Application Security Testing) attacks a running application the way an external attacker would — it finds issues that only appear at runtime, such as misconfigured headers, injection vulnerabilities that depend on server behaviour, and authentication bypasses. Both are needed: SAST catches code-level issues early, DAST catches configuration and runtime issues that SAST cannot see.

Q: Q2. What NZISM controls are most relevant to application security testing?

The New Zealand Information Security Manual (NZISM) controls most relevant to application security testing include: ISM-0045 (application whitelisting and code review), ISM-0109 (web application firewall and input validation), ISM-0396 (patch management and vulnerability scanning), and ISM-0490 (penetration testing for HIGH and VERY HIGH classified systems). For government projects, DAST scans and formal pen tests are typically required before go-live under the NZISM framework, not just recommended.

Q: Q3. How do you scope a penetration test for an NZ health-sector project?

Scoping a pen test for NZ health requires written authorisation from the system owner and the data custodian (often Te Whatu Ora or a DHB successor entity), a clearly defined scope document that lists in-scope IP ranges and URLs, a test environment that mirrors production but uses anonymised patient data under the Health Information Privacy Code, agreed safe-harbour clauses protecting the tester from prosecution under the Crimes Act 1961 section 252, and a reporting format aligned with NZISM classification levels. Pen tests on systems holding health information should never run against production patient data.

The scanner found nothing. The pen tester found seventeen issues in two hours. The difference is not the tool — it is the tester who knows which questions to ask and where to look when the obvious checks come back clean.

Senior ISTQB CTAL-TA 4.3 (Security Testing) — K4 Analyse — NZISM / OWASP ~14 min read + exercise

Senior engineer insight

The shift that changed how I approach advanced security testing was realising that automated DAST tools are evidence-gathering instruments, not verdict machines. On a central-government DAST engagement covering a service that touched IRD-linked identity data, OWASP ZAP came back clean on injection and headers — but a manual review of the request log showed the app was silently ignoring a malformed Content-Type header and processing the body as JSON anyway, bypassing the WAF rule the team was relying on. The scanner never flagged it because the response code was 200. What changed my thinking: a zero-finding DAST report does not mean secure; it means the tool found nothing in the surface it was configured to probe, and your job as a senior tester is to know what is outside that surface.

Most common mistake senior testers make: treating a passed DAST scan as a security sign-off, then handing it to stakeholders as evidence of compliance without documenting the scan scope, ruleset version, and what was explicitly excluded — leaving a false assurance gap that shows up in the next external audit.

1 The Hook — Why This Matters

A Wellington-based government digital service had passed three rounds of automated DAST scanning before its public beta. The scans were thorough: injection testing, header analysis, SSL configuration, known CVEs. Every report came back with a single medium finding about a missing Permissions-Policy header. Leadership was confident.

An external pen tester was brought in for a final assurance review. Within ninety minutes they had found a second-order SQL injection in the search export feature (the scanner only tested the input field, not the async job that consumed it), a JWT with a 10-year expiry issued to test accounts that had never been rotated, and a CORS policy that allowed null origin — exploitable from a sandboxed iframe. None of these appeared in any scan report.

The lesson for senior testers is not that scanners are useless. They are essential for consistent, repeatable baseline coverage. The lesson is that scanners are bounded instruments: they test what you configure them to test, against the surface they can reach, using rules written for known patterns. Advanced security testing is the discipline of understanding those bounds and filling the gaps with structured manual techniques, threat modelling, and targeted tooling. It is the difference between a compliance checkbox and actual assurance.

In NZ this distinction matters legally. NZISM requires formal penetration testing for systems classified HIGH or VERY HIGH, not just automated scanning. The Privacy Act 2020 imposes a duty to take reasonable steps to protect personal information — and "we ran ZAP" is not a complete answer when the breach came from a vector the scanner was not scoped to reach.

2 The Rule — The One-Sentence Version

Advanced security testing is not about running more tools — it is about understanding what each tool cannot see, then deliberately testing those blind spots with structured manual technique and threat-model-driven attack scenarios.

At the senior level, security testing moves from "did the scanner pass?" to "what is the actual attack surface, which controls are critical for this specific system's risk profile, and how do we test those controls in a way that gives the business meaningful assurance?" That requires knowing the OWASP Top 10 as a taxonomy, not a checklist, and understanding how NZ-specific frameworks like NZISM and the Health Information Privacy Code translate into concrete test obligations.

3 The Analogy — Think Of It Like...

Analogy

A burglar alarm company testing a house versus a skilled locksmith testing it.

The alarm company installs sensors on every door and window and verifies that triggering each one fires the alert. That is DAST: comprehensive coverage of the known entry points. But the locksmith comes in and tries the garage side door that shares a lock with the garden shed, checks whether the alarm covers the internal door between the double garage and the kitchen, and notices that the upstairs bathroom window is twenty centimetres outside the sensor range. The house "passed" the alarm test. It is not secure. Advanced security testing is the locksmith's discipline: you need both the systematic coverage of the alarm company and the adversarial curiosity of the locksmith who looks at the system the way an attacker would, not the way the designer planned it.

From the field

On an NZ district health network patient-scheduling system, the team had done everything right by the checklist: OWASP ZAP scan, dependency audit, TLS configuration review, and a code walkthrough. The penetration test was a formality before go-live, scoped to the public-facing booking portal. The pen tester spent the first hour on the in-scope surface and found one medium issue. Then they asked: "Is the internal staff portal on a different subdomain?" It was. It was out of scope. But the session cookie from the patient portal was being sent to that subdomain because the cookie domain was set to .healthnet.example.nz instead of booking.healthnet.example.nz. A patient who obtained a staff email address and sent a crafted link could have harvested a session token valid for the staff scheduling system. The NZISM control ISM-0109 on session management was nominally met for the in-scope portal and completely unmet for the out-of-scope one. The lesson that generalises: scope creep in security testing almost always means scope restriction, and the attack path you most need to find is the one that crosses the boundary you drew around the engagement.

4 Watch Me Do It — Step by Step

Here is the systematic approach a senior tester uses to move from automated scan to meaningful security assurance. The context is a medium-complexity NZ government web application handling citizens' tax and benefit information.

Build a threat model before you write a single test case Start with the data: what is the most sensitive thing this system holds or transmits? For an IRD-adjacent service, it is tax identifiers and income data — a breach triggers Privacy Act 2020 notification obligations. List your trust boundaries: browser to CDN, CDN to application server, application server to identity provider (RealMe), application server to backend APIs. Every boundary is a potential attack surface. Ask: what can a malicious actor with network access to each segment do? What can a malicious authenticated user do? What can a compromised internal account do? This thinking shapes your entire test strategy.
Run baseline DAST with OWASP ZAP in active scan mode Configure ZAP to authenticate as a test user so it can scan authenticated pages. Run the active scanner against all in-scope URLs. Review every finding — do not just filter to High and Critical, because Medium findings often chain with each other to produce exploitable conditions. Export the scan configuration alongside the report so you can prove to auditors exactly what was tested and with which ruleset version. Document what was explicitly excluded and why.
Manually test the OWASP Top 10 gaps that DAST misses DAST reliably finds injection, header issues, and exposed administrative interfaces. It consistently misses: (A01) IDOR and horizontal privilege escalation (because it tests as one user, not two), (A04) insecure design patterns visible only through business-logic analysis, (A08) software and data integrity failures in CI/CD pipelines, and (A10) server-side request forgery where the vulnerable parameter is buried in a JSON body. For each of these, write targeted manual test cases driven by your threat model.
Test IDOR and authorisation with two accounts at the API layer Log in as User A and capture every API call that contains a user-specific identifier — account numbers, record IDs, file references, UUIDs. For each, repeat the request authenticated as User B. The server must return 403 or 404, never User A's data. Use Burp Suite's Repeater or Postman collections to systematise this. For government systems, this test directly addresses NZISM ISM-0045 (access control) and the Privacy Act principle that personal information is only accessible to the person it belongs to.
Assess and test CORS, CSP, and security header configuration Retrieve the response headers for every distinct host and API endpoint in scope. Verify that Content-Security-Policy is present and does not contain unsafe-inline or wildcard sources unless documented and justified. Check that Access-Control-Allow-Origin does not allow null or wildcard on endpoints that return authenticated data. Verify Strict-Transport-Security has a max-age of at least one year and includes includeSubDomains where appropriate. These are common NZISM findings that automated tools flag but teams often defer without understanding the actual risk.
Test business logic and second-order vulnerabilities manually Second-order injection is input stored in the database and executed later — a search query saved for "daily digest" emails, a CSV export that serialises user-supplied data, a webhook URL stored in account settings. Trace every user-controlled value from its input point to every place it is later processed or output, and test the processing endpoint directly, not just the input field. This is where scanners fail because they cannot observe asynchronous behaviour.
Check dependency and supply-chain security Run npm audit or pip-audit and triage the results against exploitability in your specific deployment context — a critical CVE in a library used only for server-side PDF rendering is a very different risk from the same severity in an authentication library. For NZ health and government projects, check whether third-party dependencies are processed under the Government Cloud Computing Requirements and whether data leaves NZ jurisdiction during processing. Flag any transitive dependency that phones home to an external service.
Write a finding report that supports business decision-making Each finding needs: the vulnerability type (OWASP category and NZISM reference if applicable), proof of concept steps reproducible by a developer, the actual business impact in NZ terms (e.g., "a breach would trigger mandatory Privacy Commissioner notification under section 113 of the Privacy Act 2020"), a recommended remediation, and a suggested CVSS score with your rationale. A finding that says "SQL injection found" without reproduction steps and business impact does not help the team prioritise or fix it. Your report is a risk communication document, not a scanner printout.

Advanced security testing coverage matrix

Test area	Primary method	OWASP ref	NZISM control
Injection (SQL, NoSQL, LDAP, OS command)	DAST active scan + manual payload testing	A03	ISM-0109
Broken access control / IDOR	Manual two-account API testing	A01	ISM-0045
Cryptographic failures (TLS, hashing)	SSL Labs scan + certificate inspection	A02	ISM-0396
Security misconfiguration (headers, CORS)	DAST baseline + manual header review	A05	ISM-0109
Business logic / second-order vulnerabilities	Manual trace of user-controlled values	A04	—
Dependency / supply-chain vulnerabilities	Composition analysis (npm audit / pip-audit)	A06, A08	ISM-0396
SSRF	Manual probe of URL-accepting parameters	A10	—

Pro tip: For NZ government DAST, GCIO and NZISM expect a repeatable, documented process — not just a one-time scan. Build your ZAP configuration into the CI/CD pipeline so every merge to main runs a baseline scan, and save every scan report with its configuration file in version control. This creates an audit trail and surfaces regressions immediately.

Second Example: NZ Health Sector Penetration Testing

A primary care management system serving twelve GP clinics in the South Island was preparing for NZISM classification review. The system stored patient health records, appointment notes, and referral letters. Pen-test findings included:

Finding	Method that found it	OWASP / NZISM	Actual risk
Referral document IDOR	Manual two-account API test: GET /referrals/{id} with a different clinician's credentials returned the document without authorisation check	A01 / ISM-0045	CRITICAL — patient health information exposed to unauthorised staff; Health Information Privacy Code breach
Second-order XSS in clinical notes export	Injected payload in appointment note field; triggered when admin generated weekly PDF report via headless Chrome	A03 / ISM-0109	HIGH — payload executed with admin session context; could exfiltrate session token
Outdated TLS 1.0 on legacy lab-results API	SSL Labs scan against internal endpoint included in scope	A02 / ISM-0396	MEDIUM — downgrade attack risk on internal network segment; not internet-exposed
CORS null origin on patient-search endpoint	Manual header review; ZAP missed it because it only tests cross-origin requests from its own origin	A05 / ISM-0109	HIGH — exploitable from sandboxed iframe on any site the logged-in clinician visits

Remediation approach: (1) Add server-side ownership check to every referral document endpoint — confirm clinician has treating relationship with patient. (2) Sanitise clinical note output using a server-side HTML sanitiser before PDF generation; do not rely on the PDF renderer to be XSS-safe. (3) Disable TLS 1.0/1.1 on all endpoints and enforce TLS 1.2 minimum. (4) Restrict CORS to the application's own origin on all authenticated endpoints; remove null allowance.

5 Running DAST in a CI/CD Pipeline

DAST that only runs before go-live is better than nothing, but it misses the regressions introduced in every sprint. Embedding a baseline DAST scan into your pipeline creates a continuous security feedback loop that is much harder to ignore than a quarterly report.

The standard approach for NZ government projects is OWASP ZAP in baseline mode on every pull request (fast, passive-only, catches obvious misconfigurations) and full active scan on merge to main against a staging environment that mirrors production configuration. The active scan must authenticate to reach protected routes — without authentication it only tests the login page and any public surfaces, missing the majority of the attack surface.

Configure ZAP authentication for your application ZAP supports form-based login, HTTP authentication, JSON POST login, and script-based authentication for OAuth2/OIDC flows. For most NZ government apps using RealMe or an internal OIDC provider, script-based authentication is required. Save the authentication configuration as a ZAP context file and commit it to the repository alongside your pipeline scripts so authentication changes are tracked in version control.
Define an explicit target scope A ZAP scan without a scope can spider into third-party services, shared infrastructure, or environments that are out of bounds. Always configure an include-url list limited to in-scope hosts and an exclude-url list for logout endpoints (to prevent the scanner logging itself out) and destructive operations like "delete account". Save the scope to the context file.
Fail the build on High and Critical findings only Failing on every Medium finding creates noise and trains teams to ignore the pipeline. Configure ZAP to fail the build on CVSS 7.0+ findings. Route Medium and Low findings to a security backlog in your issue tracker automatically using the ZAP JIRA or GitHub Issues integration. Review the backlog in each sprint planning session; do not let it become a graveyard.
Archive scan reports as build artefacts Every scan report, its configuration file, and the ZAP version must be archived with the build. NZISM and external auditors will ask for evidence of security testing; a scan report with no version or configuration information is not audit-grade evidence. A report that references a specific configuration file in version control is.

Pro tip: The GCIO Cloud Security Framework requires that DAST is performed "in a way that is consistent with the classification of information handled." For RESTRICTED systems, that typically means the scan must be performed against a test environment with the same security controls as production, not a stripped-down dev instance with authentication disabled. Check your classification before scoping the scan environment.

6 When to Use It / When NOT to Use It

✅ Use advanced security testing when...

The system holds personal, health, or financial data
NZISM classification is RESTRICTED, HIGH, or VERY HIGH
A formal penetration test or security audit is required for go-live
Automated DAST findings are zero or suspiciously few
Business logic handles financial transactions or access grants
Third-party or supply-chain dependencies have changed recently

❌ Do not treat DAST alone as sufficient when...

The system handles health information under the HIPC
Authentication flows use OAuth2/OIDC (manual review needed)
User-supplied data is stored and processed asynchronously
The CORS policy has not been reviewed by a human this release
No two-account authorisation test has been run at the API layer
The pen test scope excluded subdomains or internal APIs

7 Common Mistakes — Don't Do This

🚫 Treating a clean DAST report as a security sign-off

I used to think: If ZAP comes back clean, the application is secure enough to ship.
Actually: ZAP tests the surface it is configured to reach, using rules written for known patterns. It will not find IDOR, second-order injection, insecure business logic, or supply-chain issues. A clean DAST report means "no known patterns detected in the configured scope." That is valuable evidence, but it is not a security sign-off.

🚫 Running DAST without authentication

I used to think: The scanner will find issues in the public surface; the authenticated surface is protected by login anyway.
Actually: The majority of a typical web application's attack surface is behind authentication. Running DAST without configuring login means you have tested the login page and the marketing content. For most systems, that is less than 10% of the actual surface. Configuring DAST authentication is not optional; it is what makes the scan meaningful.

🚫 Scoping the pen test too narrowly to protect the go-live date

I used to think: We can scope the pen test to the new features only; the old codebase has been running fine for two years.
Actually: Attack paths almost always cross component boundaries. A new feature might introduce a CORS misconfiguration that makes a two-year-old IDOR suddenly exploitable from a third-party origin. Scope creep towards restriction is one of the most common reasons pen tests miss critical findings. If you cannot test everything, document what was excluded and why, and accept the residual risk explicitly.

⚠ When Advanced Security Testing Fails in NZ Projects

Advanced security testing fails when it is treated as a single gate event rather than a continuous activity. Teams run ZAP before go-live, file the report, and never touch security again until the next major release. Six sprints later, a new endpoint is added without an authorisation check, a dependency with a critical CVE is pulled in via a transitive import, and a CORS header that was correct at go-live has been changed to accommodate a third-party widget. None of this is caught because the "security was done." Continuous DAST in the pipeline and a security item in every sprint's definition of done are the structural fixes that prevent this pattern.

8 Now You Try — Assess the Security Test Plan

🎯 Interactive Exercise

Scenario: You are the senior tester on an NZ government job-matching platform. The system holds Work and Income client data (income, employment history, benefit status) and is classified RESTRICTED under NZISM. The development team has handed you a security test plan that consists of: (1) an OWASP ZAP baseline scan run against the staging environment with authentication disabled, and (2) a review of the login page against OWASP A07. Go-live is in three weeks.

Question: Identify at least four gaps in this security test plan and state what you would add for each. Write your answer before revealing.

Four critical gaps and what to add:

DAST running without authentication. A RESTRICTED system's primary attack surface is the authenticated application. Add ZAP authentication configuration (script-based for the government identity provider) so the full authenticated surface is scanned. Without this, the DAST is testing the wrong 10% of the application.
No authorisation / IDOR testing. OWASP A01 (Broken Access Control) is the highest-risk category and DAST does not test it. Add a mandatory two-account API test: log in as Client A and attempt to access Client B's employment history, benefit status, and documents by ID substitution. This directly tests the NZISM ISM-0045 access-control requirement.
No NZISM control mapping. For a RESTRICTED system, NZISM requires formal penetration testing, not just automated scanning. Add a scoped penetration test covering the authentication layer (A07), access control (A01), injection surface (A03), and business-logic flows (A04). Document which NZISM controls each test addresses.
No dependency / supply-chain review. OWASP A06 (Vulnerable and Outdated Components) and A08 (Software and Data Integrity Failures) are not addressed. Add a npm audit or pip-audit run and review transitive dependencies for critical CVEs. For government systems, also verify that third-party packages do not transmit data outside NZ jurisdiction.

Three-week plan: Week 1 — configure ZAP authentication and rerun baseline scan; start IDOR test suite. Week 2 — run full active DAST scan; dependency audit; begin pen test engagement. Week 3 — pen test reporting and remediation triage; retest critical findings.

9 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you are ready to practise.

Why teams fail here

Running DAST without authentication so the scanner never reaches the authenticated surface where most vulnerabilities live — the scan looks thorough but covers less than 10% of the actual risk.
Treating the OWASP Top 10 as a checklist to tick rather than a threat taxonomy to reason from — teams verify each category has "a test" without asking whether that test would actually detect the flaw in their specific architecture.
Scoping the penetration test to exclude internal APIs, subdomains, or legacy components because of schedule pressure — the excluded surface is almost always where the cross-boundary attack path that exploits the in-scope finding lives.
Writing security findings without business-impact framing, so developers and stakeholders cannot triage them — a report that says "XSS found" without a reproduction path, a CVSS score, and a statement of what data is at risk gets filed and forgotten.

Key takeaway

Advanced security testing is the discipline of knowing exactly what your scanner cannot see — and then going to look there yourself, armed with a threat model, two user accounts, and the question an attacker would ask.

Q1. What is the difference between SAST and DAST in security testing?

SAST (Static Application Security Testing) analyses source code without executing it — it finds issues like hardcoded secrets, injection-prone patterns, and insecure dependencies at build time. DAST (Dynamic Application Security Testing) attacks a running application the way an external attacker would — it finds issues that only appear at runtime, such as misconfigured headers, injection vulnerabilities that depend on server behaviour, and authentication bypasses. Both are needed: SAST catches code-level issues early; DAST catches configuration and runtime issues that SAST cannot see.

Q2. What NZISM controls are most relevant to application security testing?

The NZISM controls most directly relevant include: ISM-0045 (access control — personal information accessible only to authorised users), ISM-0109 (web application firewall, input validation, and output encoding), and ISM-0396 (patch management, vulnerability scanning, and dependency currency). For RESTRICTED and above systems, NZISM also requires formal penetration testing, not just automated scanning, before go-live and at periodic intervals thereafter.

Q3. How do you scope a penetration test for an NZ health-sector project?

Scoping requires: written authorisation from the system owner and data custodian (often Te Whatu Ora or a successor DHB entity), a scope document listing in-scope IP ranges and URLs, a test environment using anonymised patient data under the Health Information Privacy Code, agreed safe-harbour clauses protecting the tester under the Crimes Act 1961 section 252, and a reporting format aligned with NZISM classification levels. Penetration tests on health systems must never run against production patient data, and the safe-harbour agreement must be in writing before any active testing begins.

10 Interview Prep — Q&A

Q. How do you approach security testing beyond running a DAST scanner?

I start with a threat model: what is the most sensitive data, where are the trust boundaries, and what does a malicious user with legitimate credentials look like? Then I run DAST as the baseline, but I treat the report as a starting point, not a conclusion. I supplement it with manual two-account IDOR testing at the API layer, a review of async and business-logic flows that scanners cannot observe, a CORS and security-header review, and a dependency audit. For NZISM-classified systems I also coordinate the formal penetration test and map findings to specific NZISM controls in the report.

Q. How would you test for second-order injection vulnerabilities?

Second-order injection means the payload is stored and executed later, not echoed back immediately. To test for it, I trace every user-controlled input to every place the value is later used: export functions, email templates, background jobs, PDF generators, webhooks, and admin reporting screens. I inject a test payload into the input, then trigger each downstream consumer and observe the output. I also check the database directly for stored payloads to confirm the input was accepted. DAST will not find this because it only observes the response to the input request, not what happens to the data later.

Q. What are the key differences between security testing for NZ government and NZ health-sector projects?

Both are regulated, but the frameworks differ. Government projects follow the NZISM and GCIO guidance — the classification level (UNCLASSIFIED through TOP SECRET) determines required controls, scan frequency, and whether a formal pen test is mandatory. Health projects must additionally comply with the Health Information Privacy Code 2020, which imposes specific rules on health information access, retention, and breach notification independent of NZISM. Health pen tests require a safe-harbour agreement citing the Crimes Act and must use anonymised test data. In practice, health projects often have more onerous access-control requirements because the harm from a privacy breach (disclosure of diagnosis, mental health history, genetic data) is more severe and less reversible than most government data breaches.

Q. How do you ensure a DAST scan is audit-grade evidence for a compliance review?

Three things make a DAST report audit-grade: (1) the scan configuration is saved alongside the report, including which ZAP version was used, which ruleset was active, which URLs were in scope and excluded, and how authentication was configured; (2) the report is archived with the build artefacts so it is traceable to a specific deployment; and (3) the report explicitly documents what was not tested and why. A clean report with no configuration documentation is not evidence of anything — an auditor cannot tell what was actually tested. A report with a committed context file and version-controlled pipeline configuration is reproducible and defensible.

← All Senior learning Session & Auth Testing → Security Labs: Broken Auth & Access Control →