Security Hardening (FIX phase)

Overview

Turn findings into correct, verified fixes. Fix the root cause at the right layer, add defense in depth, then re-test to prove the hole is closed.

Core principle: A fix you didn't re-test is a hope, not a fix. Reproduce the original exploit and confirm it now fails.

Process per finding

1. Root cause — why is untrusted data reaching the sink? Fix there, not by blocklisting symptoms.
2. Apply the secure pattern — see table below.
3. Defense in depth — add a second independent control (validation + parameterization, etc.).
4. Re-test — rerun the exact PoC from active-pentest/the audit; confirm it fails now.
5. Regression — add a test so it can't silently come back.

Secure-pattern quick reference

Validation rules of thumb

• Validate on the server — client validation is UX, not security.
• Allowlist > blocklist — define what's permitted, reject the rest.
• Encode for the sink, not the source — same data needs different encoding per context.
• Fail closed — deny by default; an error should not grant access.

Re-test gate (don't skip)

[ ] Re-ran the original PoC → it now fails / is blocked
[ ] Added an automated regression test
[ ] Checked the fix didn't just move the sink elsewhere
[ ] Verified no similar instances exist (grep the pattern across the codebase)

Output

For each finding: root cause · the fix (diff/pattern) · re-test result (PoC now fails) · regression test added. Update the findings register status → Closed.

Common mistakes

• Patching the one reported line while identical sinks remain elsewhere — grep for siblings.
• Blocklist filters (e.g. stripping <script>) that attackers trivially bypass.
• Client-side-only fixes for server-side problems.
• Marking "fixed" without rerunning the exploit.