FSD Frontend System Design

Part II — The Shield · Lesson 4.7

Security Testing

In one lineAutomate the scans that never get done manually, and put them in the pipeline as gates.

Where you've seen itThe merge that gets blocked because a transitive dependency picked up a known-critical CVE overnight.

  • Time14 min
  • DiagramPipeline with security gates at each stage
  • Chapter4 · Testing

Diagram

diagram
GATES ALONG THE PIPELINE — each catches a different class

  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐
  │  commit  │─►│    PR    │─►│  build   │─►│  staging │─►│  prod  │
  └──────────┘  └──────────┘  └──────────┘  └──────────┘  └────────┘
       │             │             │             │            │
   secret scan   SAST +        SBOM +        DAST scan   header
   (no keys in   dep audit     license       (running     monitor +
    the diff)    (static code  check         app, real     pentest
                  + CVEs)                     requests)    (periodic)
diagram
SAST vs DAST vs SCA — three different questions

  SAST   reads your source        "is this pattern dangerous?"
         fast, early, noisy       finds: innerHTML sinks, eval, secrets

  DAST   attacks the running app  "does this actually exploit?"
         slow, late, accurate     finds: missing headers, XSS, CSRF,
                                         auth bypass

  SCA    reads your lockfile      "is a dependency known-bad?"
         instant, high signal     finds: CVEs in your 1,200 packages
diagram
SEVERITY GATE — block on reachable, schedule the rest

  critical/high + reachable in prod code   ──► FAIL the build
  high, dev-dependency only                ──► ticket, next sprint
  moderate/low                             ──► batch monthly
  no fix available                         ──► document + compensating
                                                control

How it works

  1. Secret scanning at commit (gitleaks, pre-commit hooks) — the cheapest possible catch, before the key ever reaches the remote.
  2. SCA on every PR — npm audit, Dependabot, Snyk — gated on severity and reachability (see 3.7).
  3. SAST on changed files only, so the run stays fast and the signal stays readable.
  4. DAST against staging — OWASP ZAP baseline covers missing security headers, obvious injection, and cookie flags in minutes.
  5. Test your own controls: assert in CI that CSP, HSTS, and SameSite headers are actually present on responses.
js
// a security assertion is just a test
test('security headers present', async () => {
  const res = await fetch(BASE_URL);
  expect(res.headers.get('content-security-policy')).toBeTruthy();
  expect(res.headers.get('strict-transport-security')).toMatch(/max-age=\d{7,}/);
  expect(res.headers.get('x-content-type-options')).toBe('nosniff');
});

Trade-offs

ToolSpeedFalse positives
Secret scaninstantlow
SCA / dependency auditsecondsmedium (reachability)
SASTminuteshigh — tune it or it gets ignored
DASTminutes–hourslow
Manual pentestdayslowest, and finds logic flaws

Interview angle

"How do you test security in a frontend pipeline?"

  • Layer it: secrets at commit, dependencies and SAST on PR, DAST on staging, header assertions as ordinary tests.
  • Gate only on reachable high severity, or the team learns to bypass the gate entirely.
  • Automation finds known patterns; business-logic flaws — like an IDOR on an order id — still need a human.

Recap

  • Automate the boring scans and put them where they block, not where they nag.
  • SAST reads code, DAST attacks the app, SCA reads your lockfile — you need all three.
  • Header presence is testable; write it as a normal assertion.