46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
|
# Security Review and Hardening
|
||
|
|
|
||
|
|
## Purpose
|
||
|
|
|
||
|
|
Reduce avoidable security risk by reviewing trust boundaries, sensitive data handling, exposure paths, and abuse opportunities in the relevant system area.
|
||
|
|
|
||
|
|
## When to use
|
||
|
|
|
||
|
|
- Shipping authentication, authorization, input handling, or sensitive workflows
|
||
|
|
- Reviewing an externally exposed feature or API
|
||
|
|
- Auditing risky changes for common security failures
|
||
|
|
- Hardening an existing system area with known gaps
|
||
|
|
|
||
|
|
## Inputs to gather
|
||
|
|
|
||
|
|
- Trust boundaries, user roles, and entry points
|
||
|
|
- Sensitive data flows, secrets, tokens, or privileged operations
|
||
|
|
- Existing auth, validation, logging, and rate limiting patterns
|
||
|
|
- Relevant compliance or threat concerns if known
|
||
|
|
|
||
|
|
## How to work
|
||
|
|
|
||
|
|
- Start with who can do what, from where, and with which inputs.
|
||
|
|
- Check validation, authorization, data exposure, secret handling, and abuse resistance.
|
||
|
|
- Prefer concrete mitigations over vague warnings.
|
||
|
|
- Align with existing security controls unless they are clearly insufficient.
|
||
|
|
- Call out unverified areas when the environment or tooling limits confidence.
|
||
|
|
|
||
|
|
## Output expectations
|
||
|
|
|
||
|
|
- Concrete risks found or a scoped hardening plan
|
||
|
|
- Recommended mitigations tied to the actual threat surface
|
||
|
|
- Clear statement of confidence and any blind spots
|
||
|
|
|
||
|
|
## Quality checklist
|
||
|
|
|
||
|
|
- Review covers the real trust boundaries and attack surface.
|
||
|
|
- Findings describe exploit consequence, not just theoretical concern.
|
||
|
|
- Mitigations are practical for the system and team.
|
||
|
|
- Residual risk is visible where hardening is incomplete.
|
||
|
|
|
||
|
|
## Handoff notes
|
||
|
|
|
||
|
|
- Separate must-fix risks from defense-in-depth improvements.
|
||
|
|
- Pair with code review, API/backend work, and observability when the issue spans implementation and detection.
|