Lesson 02 · Security Testing

Beyond the 1Z0-830 exam

Every tester should be able to spot the most common vulnerabilities and verify the basic defenses. This isn't about becoming a penetration tester — it's awareness: knowing the OWASP Top 10, the difference between SAST and DAST, and how tools like OWASP ZAP find low-hanging fruit.

Objectives

After this lesson you will be able to:

• Recognize the OWASP Top 10 categories at a high level.
• Distinguish SAST, DAST, and dependency scanning.
• Test the standard defenses (parameterization, validation, access control).
• Run a baseline scan mentally with ZAP.

OWASP Top 10 (awareness)

The OWASP Top 10 is the industry's shortlist of critical web-app risks. You don't need them memorized, but you should recognize them:

Category	Example	Tester's check
Broken access control	user A reads user B's data	test authz on every endpoint, not just login
Injection (SQL/command)	x' OR '1'='1	parameterized queries; reject/encode input
Cryptographic failures	secrets in plaintext, weak hashing	TLS, salted hashing, no secrets in logs
Security misconfiguration	default creds, verbose errors	scan config; don't leak stack traces
Vulnerable components	an old library with a CVE	dependency scanning (below)
Identification/auth failures	weak passwords, no lockout	test brute-force/lockout, session handling

Injection — the one you already met

Module 16 showed the canonical defense: a PreparedStatement sends input as a value, never as SQL, so x' OR '1'='1 matches nothing. The same principle generalizes:

• SQL injection → parameterize queries (never concatenate input).
• Command injection → don't pass user input to a shell; use APIs with explicit arguments.
• XSS → encode output for its context (HTML/JS/URL); validate input.
• Path traversal → canonicalize and allow-list paths; reject ...

The throughline: never trust input, and keep the structure (SQL, shell, HTML) separate from the data.

SAST vs DAST vs dependency scanning

Approach	What it does	When
SAST (static)	analyzes source/bytecode for vulnerable patterns	build time, no running app
DAST (dynamic)	attacks the running app from outside (e.g. ZAP)	against a deployed instance
Dependency scanning	flags libraries with known CVEs (OWASP Dependency-Check, mvn/Snyk)	every build

They're complementary: SAST finds bad code, DAST finds bad behavior, dependency scanning finds bad libraries — and the last is often the highest-value, lowest-effort win.

OWASP ZAP — a baseline scan

ZAP (Zed Attack Proxy) is a free DAST tool. A baseline scan crawls your running app and reports common issues — missing security headers, cookies without HttpOnly/Secure, obvious injection/XSS points — without active attacking. It runs headless in CI:

docker run owasp/zap2docker-stable zap-baseline.py -t https://staging.example.com

Treat its findings as a triage list, not gospel — DAST has false positives.

Exam-style trap — security isn't a feature you bolt on

"We'll add security testing later" is how vulnerabilities ship. The cheap wins — parameterized queries, dependency scanning, a ZAP baseline in CI, not logging secrets — belong in the pipeline from day one. A test suite that never probes authz or injection is giving false confidence.

SDET note

Bake the easy checks into the suite you already run: assert that an unauthenticated request gets 401, that a user can't read another user's record (403), that an injection payload returns no rows. Add dependency scanning to CI (Module 20). Security testing isn't a separate team's job — it's a set of assertions you can write today.

Key Takeaways

• Know the OWASP Top 10 categories: broken access control, injection, crypto failures, misconfiguration, vulnerable components, auth failures.
• The injection defense generalizes: separate structure from data, never trust input, parameterize/encode/allow-list.
• SAST (static code), DAST (running app, e.g. ZAP), and dependency scanning (CVEs) are complementary.
• A ZAP baseline scan finds low-hanging fruit and runs headless in CI.
• Write security assertions (authz, injection) into your existing suite — don't defer it.

Lesson Quiz

Lesson Quiz · Security Testing0 / 5

1. The OWASP Top 10 is…

   • AThe 10 fastest Java libraries
   • BAn awareness list of the most critical web application security risks
   • CA JUnit feature
   • DA list of CI tools

2. The general principle behind defending against injection is…

   • AHide error messages
   • BKeep the command/query STRUCTURE separate from untrusted DATA (parameterize, encode, allow-list)
   • CUse longer variable names
   • DRun as root

3. SAST vs DAST:

   • ASAST attacks a running app; DAST reads source
   • BSAST analyzes source/bytecode at build time; DAST attacks the running app from outside
   • CThey're the same
   • DBoth require production access

4. Which is often the highest-value, lowest-effort security win?

   • ARewriting the app
   • BDependency scanning for libraries with known CVEs
   • CDisabling logging
   • DRemoving all tests

5. A practical SDET security assertion is…

   • AAssert the homepage loads
   • BAssert an unauthenticated request returns 401 and a user can't read another user's record
   • CAssert the build is green
   • DAssert the average latency

---

Next: Contract Testing. This module's lab is in labs/src/main/java/com/jse21/m19_specialized/.