Web & API Security — Test an App's Defences

Plan and run a defensive security test pass over a web/API application: map the OWASP risks to the right scanning approach (SAST/DAST/SCA), probe access control and injection, and triage findings — all within authorised scope.

Role

QA engineer

Difficulty

Intermediate

Time limit

~120 min

Scenario

You've joined the QA team for an e-commerce app called ShopFlow, and security has been an afterthought — there's no security testing in the pipeline and a recent audit flagged an access-control bug where one customer could view another's orders by changing an id. Your job is to bring basic, defensive security testing discipline to the app: decide which OWASP risks matter, pick the right scanning approach for each, run an authorised pass against a practice target, and produce findings the dev team can act on. You will NOT test any system you don't own — you'll use a deliberately-vulnerable practice app (OWASP Juice Shop or DVWA) as your stand-in for ShopFlow, which is exactly what those apps exist for.

Requirements

1.Stand up a practice target you control (OWASP Juice Shop or DVWA) and confirm in writing that all testing is against this authorised, self-owned target only.
2.Produce a short test plan mapping at least six OWASP Top 10 risks to the scanning approach that best finds each (SAST, DAST, or SCA) and justify each mapping in one sentence.
3.Run a DAST baseline scan (e.g. OWASP ZAP) against the running practice app and summarise the top findings, separating likely-real issues from likely false positives.
4.Manually test broken object-level access (IDOR/BOLA): authenticate as one user, attempt to reach another user's resource by manipulating an id, and document whether the app prevents it and how you confirmed it.
5.Test at least two injection inputs (e.g. a search or login field) with classic payloads and record whether input is treated as data or interpreted — without attacking anything outside the practice app.
6.Run an SCA scan (e.g. Snyk) on the app's dependencies and report how many known-vulnerable packages were found and what the suggested remediation is.
7.Write at least three authentication/authorisation checks (session invalidation on logout, token/cookie handling, access to an admin action as a non-admin) and record results.
8.Produce a prioritised findings report: each issue with its OWASP category, severity, how you found it, and a remediation suggestion — and a one-paragraph recommendation for which checks should run in CI (SAST/SCA on PRs, DAST against a test env).

Starter data

›OWASP Juice Shop: a modern deliberately-insecure web app, runnable via Docker (docker run -d -p 3000:3000 bkimminich/juice-shop) — built for legal security training.
›DVWA (Damn Vulnerable Web Application): an older PHP/MySQL practice target with adjustable difficulty.
›OWASP ZAP runs a baseline scan via Docker; Snyk free tier scans a repo's dependencies via CLI.
›OWASP Top 10 (current) is the reference checklist for which risks to consider.

Expected deliverables

✓A risk-to-approach test plan covering at least six OWASP Top 10 risks.
✓A DAST scan summary with real-vs-false-positive triage.
✓Documented IDOR/BOLA and injection test results from the authorised practice app.
✓An SCA dependency-scan summary.
✓A prioritised findings report with OWASP category, severity, evidence, and remediation per issue, plus a CI recommendation.

Evaluation rubric

Dimension	What reviewers look for
Approach selection (SAST/DAST/SCA)	Does the plan map each risk to the approach that actually finds it? A weak submission treats 'security testing' as one undifferentiated activity. A strong one knows vulnerable dependencies need SCA, runtime exploitability needs DAST, and insecure code patterns need SAST — and says why.
Access-control testing depth	Does the IDOR/BOLA test actually demonstrate the bug class? A weak answer checks only that login works. A strong one authenticates as user A, manipulates an id to reach user B's data, and documents exactly how it confirmed access was (or wasn't) prevented.
Injection testing	Does the candidate test whether input is interpreted vs treated as data? A weak submission pastes a payload and notes the response. A strong one reasons about what a successful injection would look like and confirms the app's handling, staying strictly within the practice target.
Findings triage	Does the report separate real issues from scanner noise? A weak answer dumps the raw scan output. A strong one triages — false positives identified, real issues prioritised by severity — because an untriaged report is one nobody acts on.
Remediation and CI thinking	Does each finding come with an actionable fix, and does the candidate place the right checks in the pipeline? A weak answer lists problems. A strong one suggests remediation and recommends SAST/SCA on PRs with DAST against a test environment.
Authorised-scope discipline	Did the candidate test only an authorised, self-owned target and say so explicitly? This is non-negotiable: a strong submission makes scope and authorisation clear up front; a weak one is vague about what was tested.

Sample solution outline

›Target: OWASP Juice Shop via Docker on localhost:3000, self-owned — authorisation stated explicitly.
›Risk-to-approach plan: broken access control -> DAST + manual; injection -> DAST + manual; vulnerable components -> SCA; security misconfig -> DAST; auth failures -> manual; crypto failures -> manual/config review.
›DAST: ZAP baseline scan against localhost:3000; summarise alerts; flag e.g. missing security headers (likely real) vs informational noise (triage out).
›IDOR/BOLA: log in as user A, request another basket/order id, confirm whether app returns user B's data; document request/response evidence.
›Injection: test search and login fields with classic payloads; record whether input is parameterised/escaped or interpreted.
›SCA: Snyk test on the app's dependencies; report count of known-vulnerable packages + top suggested upgrades.
›Auth checks: logout invalidates session; non-admin cannot reach an admin route; token/cookie flags set.
›Findings report: each issue -> OWASP category, severity, evidence, remediation; CI recommendation = SAST+SCA on PRs, DAST baseline against a test env, triage gate.

Common mistakes

Treating security testing as a single activity instead of choosing SAST, DAST, or SCA for the risk at hand — the core conceptual error.
Testing only that features work (login succeeds) and never testing that they fail safely (user A cannot reach user B's data).
Dumping raw scanner output as 'findings' without triaging false positives — producing a report nobody trusts or acts on.
Confusing authentication with authorisation, and testing only the former.
Reporting problems without remediation suggestions, leaving developers with a list and no path forward.
Any testing against a system the candidate doesn't own or isn't authorised to test — an immediate fail regardless of technical quality.

Submission checklist

Authorised, self-owned practice target named and scope stated explicitly
Risk-to-approach plan covering at least six OWASP Top 10 risks
DAST baseline scan summary with real-vs-false-positive triage
Documented IDOR/BOLA access-control test with evidence
At least two injection input tests recorded
SCA dependency-scan summary
At least three authentication/authorisation checks with results
Prioritised findings report (OWASP category, severity, evidence, remediation) + CI recommendation

Extension ideas

+Add a SAST scan (e.g. SonarQube) of a small sample codebase and compare what it finds vs the DAST scan — illustrating why both exist.
+Wire the SCA and a DAST baseline into a CI pipeline and gate on severity, proving the access-control regression can't silently return.
+Write a one-page threat model for ShopFlow's checkout flow and derive targeted tests from it.