Back to path
AdvancedLedgerline · Project 10 of 12 ~6h· 5 milestones

Attack the running app automatically

Continues from the last build: Static rules, policies, signatures and scans all gate the pipeline, but nothing has tested the app while it runs.

Every gate you have built so far reads code, dependency manifests, Dockerfiles and policy files.

OWASP ZAP baseline and full scansauthenticated DAST session handlingHTTP security headers (CSP, HSTS)secure cookie flagsCI/CD ephemeral test environmentsrisk triage against a threat modelGitHub Actions least-privilege pipelines
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

By the end, every pull request spins up it and its database in CI, ZAP attacks it both unauthenticated and logged in, the response headers and cookies pass a hardened baseline, the pipeline fails the build on new high-risk alerts, and every remaining ZAP finding is either fixed or recorded in the threat model with a named owner and an expiry date.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

security/zap/automation-auth.yamlyaml
env:
  contexts:
    - name: "ledgerline"
      urls:
        - "http://localhost:3000"
      authentication:
        method: "browser"
        parameters:
          loginPageUrl: "TODO"
          loginPageWait: 2
        verification:
          method: "response"
          loggedInRegex: "TODO"
          loggedOutRegex: "TODO"
      users:
        - name: "test-user"
          credentials:
            username: "TODO"
            password: "${ZAP_TEST_PASSWORD}"
jobs:
  - type: "spider"
    parameters:
      context: "ledgerline"
      user: "test-user"
  - type: "report"
    parameters:
      template: "sarif-json"
      reportFile: "zap-auth-report"

Reading this file

  • method: "browser"Starter is already set to browser-based auth, the more reliable ZAP login method for a real form.
  • loginPageUrl: "TODO"Fill this in with the actual login route once you confirm it in milestone 2.
  • password: "${ZAP_TEST_PASSWORD}"Already wired to read from an environment variable, never hardcode the test password here.
  • type: "spider"Starts with just a spider job; you add the activeScan and full report jobs as part of the milestone.

Fill in the loginPageUrl, verification regexes and test-user credentials for milestone 2, then add the activeScan job.

That's 1 of 8 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Baseline scan it with ZAP and read what static tools cannot see

    5 guided steps

    You need to feel the SAST-vs-DAST gap concretely before automating anything. A baseline scan is a spider plus passive rules with no active attack payloads, so it is safe to run against anything you own, including staging.

  2. 2

    Give ZAP a login so it tests the money-movement screens

    5 guided steps

    An unauthenticated scan sees a login page and nothing else. The transfer endpoint, the account IDOR surface and any admin routes all sit behind session cookies; unauthenticated DAST misses roughly half of the real attack surface on a fintech app.

  3. 3

    Turn ZAP's header and cookie alerts into a real fix

    5 guided steps

    Missing headers are exactly the class of runtime misconfiguration a SAST tool cannot see, because there is no vulnerable line of code, the vulnerability is an absent line.

  4. 4

    Run DAST in CI without flaking the build

    5 guided steps

    A DAST scan against a service that is not fully up yet, or a job that fails on every WARN, trains the team to ignore it within a week. Determinism, a real health check and a documented threshold, is what keeps this gate trusted.

  5. 5

    Triage every finding against the threat model and close the loop

    5 guided steps

    A DAST tool produces a list of alerts, not a security posture. The judgment call, what is a real risk to this app versus noise from a generic ruleset, is the actual senior-level work; an unreviewed ignore list is how real findings quietly disappear.

What's inside when you start

4 starter files, ready to clone
5 guided milestones
4 full reference solutions
8 code blocks explained line-by-line
5 "is it working?" checks
6 interview questions it prepares you for

You'll walk away with

A ZAP baseline scan report run against a locally running instance of it, with every alert read and classified
A ZAP automation framework config that logs in and scans behind authentication
A hardened security-headers middleware (CSP, HSTS, X-Content-Type-Options) and secure cookie flags, verified by ZAP
A dast.yml GitHub Actions workflow that boots app+db, runs baseline and authenticated scans, and fails on new high alerts
An updated threat-model.md with every ZAP finding mapped to a STRIDE/OWASP Top 10 category and marked fixed or accepted

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building