Security Hardening

Security Hardening

Use this skill for pragmatic appsec work that produces prioritized fixes and residual-risk notes. Do not turn it into a compliance theater exercise.

Counterweight: threat before control

• Start with assets, trust boundaries, attacker capability, exposure, and plausible abuse paths. Do not apply the checklist uniformly.
• Add or change a control only for a concrete reachable risk. Record when framework or provider defaults already cover it.
• Prefer removing exposure, privilege, data, or code over adding middleware, policy layers, scanners, and monitoring.
• Do not add rate limits, CORS/CSRF machinery, headers, runtime schemas, encryption, secret rotation, or dependency upgrades where the threat model does not require them.
• Preserve one authorization source of truth; do not duplicate permission checks across artificial layers.
• Avoid speculative findings based only on pattern matches. Confirm actual callers, deployment topology, and runtime behavior.
• Keep fixes focused. Do not turn one vulnerability into a repo-wide security program, compliance project, dependency refresh, or release ceremony.
• A scoped review may correctly conclude that no code change is needed. Report accepted and out-of-scope risk plainly.
• Do not mutate production, rotate credentials, contact users, or change provider policy unless the active request explicitly authorizes it.

Workflow

1. Map the attack surface

   • Identify only the assets, entrypoints, trust boundaries, privileges, storage, and egress relevant to the defined review.
   • Trace plausible attacker paths through actual callers and deployment topology.

2. Build a risk-ranked plan

   • Prioritize exploitable paths over theoretical issues.
   • Separate must-fix before release, should-fix soon, and accepted/deferred risks.
   • Preserve product behavior unless the vulnerability requires a behavior change.

3. Harden the highest-risk paths

   • Add or tighten authorization checks at server/action boundaries.
   • Validate untrusted input at external/API/provider boundaries.
   • Protect secrets and redact sensitive logs.
   • Add rate limits, origin controls, CSRF/CORS policy, SSRF protections, upload constraints, or security headers only where the mapped threat requires them.
   • Audit dependencies and package scripts only within the reviewed attack surface.

4. Prove the fixes

   • Add focused tests for permission bypasses, input rejection, dangerous URL/file cases, auth/session edge cases, and safe error/log payloads.
   • Run focused dependency or security tools when their signal applies to the reviewed surface.
   • Document what could not be verified.

5. Report residual risk

   • List fixed issues with evidence.
   • List remaining risks with severity, exploit sketch, and recommended next action.
   • Avoid claiming the app is "secure"; state the reviewed scope.

Quality Bar

• Every reviewed server mutation has an authorization story.
• Reviewed secrets are not exposed through reachable logs, clients, fixtures, or outputs.
• Reviewed external inputs have threat-appropriate validation before side effects.
• Reviewed dangerous network or file operations have threat-appropriate restrictions.
• Focused tests prove the highest-risk changed bypass or failure cases.

For the audit checklist, read checklist.md.