Security Testing

<objective>
A login test that only checks the happy path passes while an expired JWT still grants admin, an
IDOR lets user A read user B's orders, and a webhook field reaches `169.254.169.254`. This skill
forces the negative-path checks — broken access control, injection, SSRF, auth bypass, supply-chain
drift — into CI on every PR, layered across DAST, SCA, SAST, and custom Playwright tests so no single
tool's blind spot ships. It produces runnable tests mapped to the OWASP Top 10 (2025) plus the CI
gates that fail the build when a category regresses.
</objective>

Discovery Questions

Check .agents/qa-project-context.md first — if it exists, use it and skip anything already answered there (auth mechanism, compliance requirements, infrastructure). Then:

1. Threat model: Has the team identified key assets, threat actors, and attack surfaces? If not, do a lightweight threat model before writing tests — it tells you which categories matter most.
2. Auth mechanism: Session cookies, JWT, OAuth 2.0/OIDC, API keys, or MFA? Each has distinct negative-path tests (alg confusion, session fixation, state tampering).
3. Compliance requirements: SOC 2, HIPAA, PCI DSS, GDPR? These mandate specific controls — map them with compliance-testing; this skill only proves the controls behave.
4. Existing security tooling: Already running OSV-Scanner, Snyk, Dependabot, Semgrep, or ZAP? Check CI config for existing security stages before adding duplicates.
5. API surface: REST, GraphQL, gRPC? Each protocol has specific injection and authorization vectors.
6. Deployment model: Cloud (AWS/GCP/Azure), containers, serverless? Cloud-metadata endpoints are prime SSRF targets and misconfiguration is A02.

---

Core Principles

1. Security is continuous, not a phase. Scans run in CI on every PR, not as a quarterly penetration test. A vulnerability caught on the PR that introduced it costs minutes; the same vulnerability found in prod costs an incident.

2. OWASP Top 10 is the floor, not the ceiling. It covers the most common impactful classes. Domain-specific threats (healthcare data, financial transactions, multi-tenant isolation) need their own analysis on top.

3. Defense in depth — no single tool catches everything. ZAP misses auth-logic bugs, SCA misses your custom code, Semgrep misses runtime issues. Layer DAST + SCA + SAST + auth tests + secret scanning. When one layer's blind spot is another layer's coverage, a regression has to beat all of them. SCA earns its layer because most of the shipped code is third-party — known CVEs in dependencies are the lowest-effort attack vector, so scan on every build.

4. Shift-left. Catch each class at the earliest stage: SAST and secret scanning on commit, dependency/supply-chain checks on the PR, DAST in staging, custom auth tests on every run. See shift-left-testing for the dev-QA workflow this rides on.

5. Test the attacker, not the user. Happy-path auth proves login works. Security tests prove logout invalidates the session, an expired token is rejected, role escalation fails, and a malformed payload fails closed. The negative path IS the test.

---

OWASP Top 10 (2025) Testing Checklist

The 2025 list (final, owasp.org/Top10/2025/) re-orders categories and introduces two new ones. Changes from 2021:

• A03 Software Supply Chain Failures is new (replaces "Vulnerable and Outdated Components"; broadens to provenance, build-pipeline trust, SBOM).
• A10 Mishandling of Exceptional Conditions is new. SSRF is no longer standalone — its tests now sit under A01 (access control) and A06 (insecure design).
• A02 Security Misconfiguration moved up from A05.
• A07 Authentication Failures — name shortened (drops "Identification and").
• A09 Security Logging and Alerting Failures — renamed (was "Logging and Monitoring").

For runnable test code per category, see references/owasp-tests.md.

A01: Broken Access Control

The #1 vulnerability. Users act outside intended permissions. SSRF is now an access-control failure when the server is induced to reach internal resources for an attacker.

What to test: IDOR (change resource IDs to reach other users' data), missing function-level access control (admin endpoints as a regular user), path traversal (../../etc/passwd), CORS misconfiguration, SSRF (user URLs reaching internal networks, cloud-metadata endpoints, file://).

A02: Security Misconfiguration

Default credentials, unnecessary features, verbose errors. Promoted from A05 — still the easiest way in.

What to test: stack traces disabled in prod, default credentials changed, unnecessary HTTP methods (e.g. TRACE) disabled, directory listing off, admin panels not public, cloud buckets not public.

A03: Software Supply Chain Failures

New in 2025. Beyond "outdated dependencies" — provenance, build-pipeline integrity, the supply chain end-to-end.

What to test: lockfile committed and CI installs from it (npm ci, never npm install); SBOM generated and stored as a build artifact (Syft / anchore/sbom-action); provenance attestation for built artifacts (SLSA v1.0 L2/3, signed via cosign / actions/attest-build-provenance); dependency review on every PR; CI secrets not exposed to forks; self-hosted runners isolated from untrusted PR code.

See references/owasp-tests.md for the dependency-review / SBOM / provenance workflow and the lockfile-drift check.

A04: Cryptographic Failures

Sensitive data exposed via weak or missing encryption.

What to test: TLS version / cipher suites / HSTS; passwords hashed with bcrypt/argon2 (not MD5/SHA1); no sensitive data in URLs, logs, or errors; cookies carry Secure, HttpOnly, SameSite; security headers present (HSTS, X-Content-Type-Options: nosniff, X-Frame-Options).

A05: Injection

Untrusted data sent to an interpreter.

What to test: SQL injection in params/fields/headers; XSS (reflected, stored, DOM) in user content; CSRF on state-changing operations; command injection in filenames, search queries, webhook URLs.

A06: Insecure Design

Flawed architecture implementation alone can't fix. Includes design-level SSRF (URL-accepting features without an allow-list), credential stuffing without rate limits, business-logic abuse.

What to test: rate limiting on auth endpoints (fire 15 concurrent login attempts, expect a 429 in the responses); business-logic abuse (negative quantities, coupon stacking); account lockout after failed attempts; allow-list architecture for any feature that fetches a user-supplied URL.

A07: Authentication Failures

Broken authentication, weak passwords, credential stuffing. Session rotation after login, expired/alg:none JWT rejection, RBAC matrix, OAuth state tampering. See references/auth-tests.md.

A08: Software or Data Integrity Failures

Unsigned updates, insecure deserialization, untrusted CI/CD.

What to test: Subresource Integrity (SRI) on CDN scripts; Content-Security-Policy header present and free of 'unsafe-inline' / 'unsafe-eval'.

A09: Security Logging and Alerting Failures

Insufficient logging and missing alerts on what is logged. Renamed in 2025 to stress that logs without alerts are after-the-fact evidence, not detection.

What to test: failed logins logged AND alerting above threshold; admin actions audit-logged AND alerting on out-of-hours events; logs free of secrets/PII; the alert pipeline itself monitored.

A10: Mishandling of Exceptional Conditions

New in 2025. Errors and unexpected states are an attack surface — fail-open defaults, uncaught exceptions leaking internals, race conditions in error paths, security checks skipped when "something went wrong."

What to test: error responses leak no stack traces / framework names / DB schema; auth fails closed (deny by default); timeouts and partial failures never bypass authorization; resource cleanup on every error path; fuzz every endpoint and verify responses stay within the documented error contract.

---

OWASP LLM Top 10 (2025)

If your app embeds an LLM (chatbot, RAG, agent, copilot), the classic Top 10 above does not cover its failure modes — use the OWASP Gen AI Security Project's separate list (genai.owasp.org/llm-top-10/). This is the security/CI-gate view: one-line "what to test" per category. For the DEEP behavioral coverage of LLM01 and LLM02 — indirect injection via tool/RAG data, defend-the-tester technique, jailbreak red-teaming, and the runnable injection detector — hand off to ai-system-testing; do not duplicate it here.

LLM05 (Improper Output Handling) is where the classic Top 10 reconnects: treat LLM output as untrusted input and re-run the A05 Injection checks on anything it produces.

---