Security Testing

What a QA engineer needs to test an application's security: the main testing approaches, the vulnerability classes worth knowing, and which tool does which job. This is defensive testing of systems you're authorised to test — pair it with the API Testing Concepts sheet for the API side.

The three scanning approaches

The single most useful distinction in security testing is what each tool looks at. They are complementary, not interchangeable.

Approach	What it scans	When it runs	Finds
SAST	Your source code (static)	No running app needed	Insecure code patterns, injection-prone code
DAST	A running app (dynamic)	Against a deployed target	Runtime vulnerabilities, real exploitable behaviour
SCA	Your dependencies	On the manifest/lockfile	Known vulnerabilities in third-party packages

A mature pipeline uses all three: SAST and SCA early (on every commit/PR), DAST against a deployed test environment. They catch different things — SAST sees code you wrote, SCA sees code you imported, DAST sees what's actually exploitable at runtime.

Choosing a tool by approach

Approach	Tools
SAST	SonarQube, Checkmarx, Veracode SAST
DAST	OWASP ZAP, Burp Suite
SCA	Snyk
API security (test-driven)	Pynt
Targeted pentest	SQLMap (SQLi), Nmap (network recon)

The OWASP Top 10 — the baseline checklist

The OWASP Top 10 is the industry's consensus list of the most critical web application security risks. It's the natural starting checklist for what to test.

Risk	What to test for
Broken access control	Can a user reach data/actions they shouldn't? (incl. IDOR/BOLA)
Cryptographic failures	Is sensitive data encrypted in transit and at rest?
Injection	SQL, NoSQL, command, LDAP — is untrusted input ever interpreted?
Insecure design	Are there missing controls by design, not just bugs?
Security misconfiguration	Default creds, verbose errors, unnecessary open services
Vulnerable components	Known-vulnerable dependencies (this is what SCA finds)
Authentication failures	Weak passwords, broken session handling, missing MFA
Data integrity failures	Unsigned updates, insecure deserialisation
Logging/monitoring failures	Are attacks detectable after the fact?
Server-side request forgery	Can the server be tricked into making requests?

You don't test all ten with one tool — map each risk to the approach that finds it (access control and injection via DAST/manual; vulnerable components via SCA; insecure patterns via SAST).

Injection — the classic, and how to test it

Injection happens when untrusted input is interpreted as code or a command. SQL injection is the canonical example.

-- Vulnerable: input concatenated into the query
"SELECT * FROM users WHERE id = " + userInput
 
-- An attacker sends:  1 OR 1=1   ->  returns all users

The fix is parameterised queries (the input is data, never code) — the same principle as GraphQL variables. To test:

Send classic injection payloads to every input that reaches a query and assert they're rejected or treated as literal data, not executed.
Use a specialist tool (SQLMap, authorised targets only) to probe thoroughly.
Verify a known-fixed endpoint stays fixed (regression).

Authentication vs authorisation testing

Two different things, both heavily tested, often confused.

Authentication — who are you? Test login, session handling, password policy, MFA, token expiry, and logout actually invalidating the session.
Authorisation — what are you allowed to do? Test that a logged-in user cannot access another user's data or admin actions.

The highest-value authorisation bug class is broken object-level access (IDOR/BOLA): changing an id in a request (/orders/1001 → /orders/1002) to reach data you don't own. Test it explicitly — authenticate as user A and try to reach user B's resources.

Testing in the pipeline

Stage	What to run
On every commit/PR	SAST + SCA (fast, no deploy needed)
Against a deployed test env	DAST baseline scan
Scheduled / pre-release	Full DAST active scan, deeper SAST
Always	Triage findings — separate false positives from real issues

The triage discipline matters as much as the scanning: security tools are noisy, and a gate nobody trusts gets ignored. Tune rules so failures mean something.

A note on authorised testing

Dynamic scanning, injection testing and network scanning probe live systems. Only run them against systems you own or have explicit written authorisation to test. Scanning or attacking systems without permission is illegal in most jurisdictions, regardless of intent. Define scope before you start.