---
name: security-hardening
description: Audit or harden a defined application-security attack surface when the user explicitly requests a security audit, vulnerability investigation, or scoped security-hardening pass. Do not trigger for routine authentication changes, role design, scoped permissions, ordinary authorization bugs, dependency updates, generic production readiness, or feature implementation with incidental security implications.
---

# 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](references/checklist.md).