Security Testing
Verify that a system protects data, maintains functionality as intended, and resists unauthorised access, disclosure, or modification. A significant portion of security bugs can be found by functional testers — without specialist tools.
What it is
Security testing evaluates whether a system protects its data and functionality against threats. It covers confidentiality (only authorised users see data), integrity (data isn’t altered without authorisation), and availability (the system stays up under attack).
Security testing is a spectrum. At one end, functional testers check basic things like whether admin URLs require login and whether error messages reveal stack traces. At the other end, specialist penetration testers (pentesters) use advanced tools and techniques to probe for deeper vulnerabilities. Most teams need both — and functional testers can find a surprising number of critical bugs before a pentester ever arrives.
The distinction that matters: security testing is not just about what the application is supposed to do. It’s about what happens when you deliberately try to make it do something it’s not supposed to. Thinking like an attacker is the core skill.
When to use it
- Before any release involving user data, authentication, or personal information
- Before releasing payment functionality (PCI-DSS requirements apply)
- When new endpoints are added that accept user-supplied input
- When authentication or session management code is changed
- In NZ, whenever a system stores or processes personal information — Privacy Act 2020 requires “reasonable security safeguards”
OWASP Top 10
The Open Web Application Security Project (OWASP) maintains a list of the ten most critical web application security risks. Understanding these helps you think like an attacker and know what to look for.
| # | Risk | What it means in practice |
|---|---|---|
| A01 | Broken Access Control | User A can view or modify User B’s data. Example: changing ?orderId=1001 to ?orderId=1002 shows another NZ customer’s order. The most common critical vulnerability in production systems. |
| A02 | Cryptographic Failures | Sensitive data is inadequately protected. Passwords stored in plain text; credit card numbers logged; pages served over HTTP instead of HTTPS; weak TLS configuration. |
| A03 | Injection | User-supplied data is interpreted as code. SQL injection via a search box; XSS (cross-site scripting) where a review field stores <script>alert(1)</script> and it executes when another user views it. |
| A04 | Insecure Design | Fundamental design flaws. Example: a “forgot password” flow that emails the user their actual password (meaning it was never hashed); no rate limiting on a login endpoint. |
| A05 | Security Misconfiguration | Default credentials left enabled (admin/admin); verbose error messages that show stack traces with file paths; directory listing enabled on a web server; debug mode left on in production. |
| A06 | Vulnerable Components | Using outdated libraries with known CVEs (Common Vulnerabilities and Exposures). A critical vulnerability in an npm package or Java library can compromise the entire application. |
| A07 | Auth and Session Failures | Session tokens that never expire; tokens that remain valid after logout; weak password requirements; no multi-factor authentication on high-value accounts. |
| A08 | Software Integrity Failures | No verification of third-party scripts loaded from CDNs; a compromised npm package silently published under the same name; no code signing for auto-update mechanisms. |
| A09 | Logging & Monitoring Failures | No audit trail for admin actions (who deleted that customer record?); failed login attempts not logged; no alerting when abnormal access patterns occur. |
| A10 | SSRF | Server-Side Request Forgery. The server fetches URLs supplied by users — allowing an attacker to make the server request internal resources (AWS metadata endpoints, internal APIs) that should never be publicly accessible. |
NZ context: Privacy Act 2020
In New Zealand, the Privacy Act 2020 requires organisations to have reasonable security safeguards to protect personal information. Unlike its predecessor, the 2020 Act introduced mandatory breach notification: if a privacy breach occurs and is likely to cause serious harm to affected individuals, the organisation must notify both the Privacy Commissioner and the affected individuals as soon as practicable.
The Privacy Commissioner has the power to investigate complaints, issue compliance notices, and refer cases to the Human Rights Review Tribunal. Penalties of up to NZD$10,000 per offence can apply.
What this means for testers: if you discover a vulnerability during testing — especially one that could expose personal information — treat it as a high-priority defect and ensure it is tracked, addressed, and verified before release. Document your finding clearly: what data was accessible, under what conditions, and what the potential harm is.
What functional testers can check
You don’t need Burp Suite or specialist training to find these bugs. A browser and some curiosity is sufficient:
| Check | How to do it | What a bug looks like |
|---|---|---|
| IDOR (Insecure Direct Object Reference) | Find a URL with an ID (e.g. /orders/1001). Log in as a different user. Try /orders/1001 — can you see the first user’s order? |
Any response other than 403 Forbidden is a critical bug |
| HTTPS everywhere | Try loading http:// versions of all pages. Check for mixed content warnings in browser DevTools. |
Any page that loads over HTTP, or loads resources (scripts, images) over HTTP on an HTTPS page |
| Verbose error messages | Submit malformed data; try accessing non-existent URLs; trigger server errors. Check the response body. | Stack traces, file paths (/var/www/html/app.php), database table names in error messages |
| Session expiry after logout | Log in. Copy a session cookie or auth token. Log out. Try using the copied token to make a request. | A 200 response after logout means the session was not invalidated server-side |
| Session expiry after inactivity | Log in. Leave the session idle for 30 minutes. Try to perform an action. | Session still valid after a long period of inactivity |
| XSS in input fields | Submit <script>alert(1)</script> in text fields (name, address, review, search). Save and view the result in a browser. |
An alert box appears, or the script tag appears unescaped in the HTML source |
| Unauthenticated admin access | Copy an admin URL (e.g. /admin/users). Open a private/incognito window and paste it without logging in. |
Page loads instead of redirecting to the login page |
Common bugs
- IDOR — changing
?customerId=123to?customerId=124returns another customer’s personal data. Extremely common and often critical. - Verbose error messages — a 500 response that includes a Java stack trace or internal file paths; attackers use this to understand the system architecture
- No rate limiting on login — allows an attacker to try thousands of password combinations (brute force) without being blocked
- Missing CSRF tokens — state-changing forms (change email, change password, transfer money) without CSRF tokens can be triggered by malicious sites if a victim is already logged in
- Password stored in plain text — detectable if “forgot password” sends you your actual password rather than a reset link
- Auth token in URL — tokens in query parameters (
?token=abc123) are logged by web servers, proxies, and browser history, leaking credentials
Tools
- OWASP ZAP (free) — automated scanner that crawls your application and identifies common vulnerabilities; good starting point for teams without a dedicated pentester
- Burp Suite Community (free) — intercepting proxy that lets you inspect and modify requests/responses; used by professional pentesters and advanced testers
- Browser DevTools — built into every browser; use the Network tab to inspect requests/responses, the Application tab to view cookies and storage, and the Console to spot JavaScript errors
Tips
Think like an attacker. As a functional tester, you can find a significant portion of security bugs without specialised tools — just by thinking like an attacker. What would happen if I changed this ID? What if I remove the auth header? What if I submit a script tag? What if I try to access this admin URL when logged out? These questions cost nothing and catch critical issues.
- Raise security bugs as high priority — a bug that exposes personal data is more critical than a bug that breaks a feature. Make sure your defect severity model reflects this.
- Don’t just test happy paths — the most dangerous bugs are found when you deliberately behave as a malicious user would
- Check error messages carefully — they frequently reveal internal implementation details that are useful to an attacker and should never be exposed to end users
- Include security testing in your Definition of Done — at minimum, the functional-tester security checklist above should be completed before any user story is marked done
Practice this technique: Try Test Lead Practice 03 — Security surface.
NZ context — Privacy Act 2020 and security obligations
The New Zealand Privacy Act 2020 (effective December 2020) replaced the 1993 Act and introduced mandatory breach notification. Under the Act, organisations must notify the Privacy Commissioner and affected individuals of a privacy breach that causes or is likely to cause serious harm — within 72 hours is best practice (the Act requires “as soon as practicable”).
Key testing implications:
- Data at rest — is personal information (name, DOB, IRD number, bank account) encrypted in the database?
- Data in transit — is all PII transmitted over HTTPS?
- Right to access and correction — can users view and correct their personal data?
- Data minimisation — is the system collecting only what it needs?
- Retention — does the system delete data when it’s no longer needed?
For security testing in a NZ context, OWASP Top 10 remains the technical baseline, but compliance with the Privacy Act adds the legal requirement. A SQL injection vulnerability that exposes customer records is both a technical security failure AND a Privacy Act breach notifiable to the Privacy Commissioner.
Testers working on NZ government or health systems also need to be aware of the Health Information Privacy Code 2020, which has stricter rules for health data.