Q274: Frontend Security Testing SAST DAST and Abuse Case Coverage

What Interviewers Want To Evaluate

Interviewers want to know whether you can test frontend security beyond happy-path unit tests.

They want to hear how static analysis, dynamic testing, dependency scanning, accessibility tooling, route smoke tests, abuse cases, and manual review fit together.

Short Interview Answer

Frontend security testing combines automated scanning with abuse-case validation. I would use dependency scanning, lint rules, type checks, SAST-style checks for dangerous patterns, DAST or browser tests for deployed behavior, header checks, auth and authorization tests, upload tests, XSS regression cases, and manual review for high-risk flows. The goal is not perfect automation; it is repeatable coverage for the most likely and highest-impact failures.

Detailed Interview Answer

Security testing should match frontend risk.

Frontend risks include:

XSS
broken access control
token exposure
unsafe storage
CSRF
CORS mistakes
clickjacking
insecure uploads
privacy leaks
dependency compromise
missing security headers

No single tool catches all of these.

Use layers.

Static Checks

Static checks inspect code without running the app.

Examples:

lint rules
TypeScript
dependency scanning
secret scanning
dangerous API detection
custom grep or AST checks

Patterns to catch:

dangerouslySetInnerHTML
localStorage token usage
console logging sensitive fields
wildcard postMessage usage
unsafe iframe sandbox tokens
hardcoded secrets

Static checks are fast and good for CI.

They can produce false positives.

Dynamic Checks

Dynamic checks run against an application.

Examples:

Playwright route tests
security header checks
auth redirect checks
CORS behavior checks
upload behavior tests
XSS payload regression tests
manual proxy testing

Dynamic checks catch integration problems static tools miss.

They need realistic environments.

Dependency and Secret Scanning

Use tools to detect:

known vulnerabilities
compromised versions
license issues
hardcoded keys
high-risk transitive packages

But scanning is not enough.

Teams still need ownership and decisions.

A warning with no owner becomes background noise.

Abuse Cases

Abuse cases are negative user stories.

Examples:

as an attacker, I try to read another user's progress
as an attacker, I upload HTML disguised as PDF
as an attacker, I send postMessage from the wrong origin
as an attacker, I replay an old mutation
as an attacker, I put a reset token in a URL and check logs

Abuse cases make security concrete.

They are excellent for senior design interviews.

Header Checks

Check production headers:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
frame-ancestors
Cache-Control

Headers can differ by route and deployment.

Test the actual deployed URL, not only local dev.

Auth and Authorization Tests

Test:

anonymous access
authenticated access
forbidden role
wrong tenant
expired session
revoked session
logout state
direct URL access
API access without UI

The frontend should handle these states clearly, but the server must enforce final decisions.

Regression Suite

Security bugs should become tests.

If a bug happened once:

write a regression test
add a checklist item
add monitoring if useful
document ownership

This turns incidents into learning.

Interview Example

If asked, "How would you test against XSS in a markdown handbook app?"

Answer:

"I would validate the MDX/markdown rendering pipeline, avoid rendering untrusted HTML, add tests with script-like payloads, verify sanitization if user content is introduced, use CSP as defense-in-depth, and check that code blocks render as text rather than executable markup."

Common Mistakes

Common mistakes include:

only testing happy paths
assuming TypeScript catches security issues
ignoring deployed headers
not testing wrong-tenant access
not turning incidents into regression tests
accepting scanner alerts without triage
not testing browser-specific behavior
not testing privacy leaks in logs

Senior-Level Framing

The senior framing:

"Security testing is layered. I combine fast static checks, realistic dynamic tests, dependency and secret scanning, abuse-case coverage, manual review for high-risk flows, and incident-driven regression tests."

Practice Prompt

Create a security test plan for:

practice console
PDF export
progress tracking
future login
file upload
embedded code editor

For each, list static checks, dynamic checks, and abuse cases.

Final Mental Model

Security tests should prove the app resists misuse, not only that it works for friendly users.

Senior engineers test the boundary, not just the button.