Dynamic analysis
🏠The everyday picture
After a building is finished, an inspector walks through it, tries the doors, tests the fire alarms and checks the exits actually open. Plans can't show everything.
📘What it really is
-
Dynamic analysis (DAST) tests the running application from outside, as an attacker would, by sending requests and watching responses.
-
OWASP ZAP (free) is the common tool:
- a baseline scan passively checks headers, cookies and common misconfigurations; safe and quick;
- a full scan actively tries attacks (injection, XSS); run it only against your own local or staging environment, never production with real data, and never anyone else's site;
-
it can run in CI against a staging deploy (
zaproxy/action-baseline). -
Your own security tests are often the most valuable dynamic tests: automated API tests that try forbidden actions, other users' IDs, oversized inputs, hostile strings (Modules 74, 75).
-
Fuzzing sends large amounts of random or malformed input to find crashes and unexpected behaviour.
-
Penetration testing: skilled testers try to break in, with written permission and agreed scope (Module 80). Worth it before handling sensitive data at scale.
-
Combine methods: SAST finds code patterns, DAST finds runtime and configuration problems, tests and review find logic flaws. None is enough alone.
🖱️Try it
Run ZAP's baseline scan against your staging CRM (docker run --rm -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t
https://your-staging-address), only on your own site. Fix the warnings that matter. Then run a full active scan against your
local copy only, review the findings, and add a ZAP baseline step to your deploy workflow after staging.
✅Quick check
Where may you run an active ZAP scan?
Show the answer
Only on your own local or staging environments (or systems you have written permission to test), never others' sites.
Why use both static and dynamic analysis?
Show the answer
They find different problems: code patterns versus runtime and configuration issues.