session-security-reviewer
Purpose
Review session establishment, storage, rotation, expiry, revocation, and transport protections for web and API systems.
Trigger this skill when
- The current artifact has security implications that need structured review or hardening.
- You need to turn vague security concerns into concrete findings, controls, or requirements.
- You want the next security-focused action to be explicit rather than ad hoc.
Expected inputs
- session design
- cookie/token settings
- expiry rules
- revocation model
- transport/security headers
Deliverables
- session findings
- lifecycle risks
- token/cookie hardening actions
- rotation/revocation issues
- recommended changes
Operating procedure
- Read the artifact from a security perspective and identify the concrete trust and exposure model.
- Separate facts from assumptions and call out missing information that affects confidence.
- Map the highest-risk paths first rather than trying to describe every possible issue equally.
- Translate findings into concrete control or requirement language that a builder can act on.
- Prefer explicit attack paths, assets, boundaries, and failure conditions over generic advice.
- Finish with the most sensible handoff skill based on the dominant risk area you found.
Quality gates
- Findings are specific to the artifact and threat context, not generic security boilerplate.
- Output separates facts, assumptions, risks, controls, and recommended next action.
- Prioritization reflects impact and exposure, not just the number of issues found.
- Recommendations are implementable and framed in a way that can be tested or reviewed later.
Handoff targets
- secure-defaults-checker
- secrets-handling-checker
- security-requirements-writer
Output style
- Be explicit about uncertainty.
- Prefer concrete attack paths and control implications over generic slogans.
- Separate facts, risks, recommendations, and next steps.
- Make the output usable by engineers, reviewers, and test designers.
Failure modes to avoid
- Do not confuse compliance language with real security risk reduction.
- Do not bury critical exposure behind long, unprioritized issue lists.
- Do not recommend controls without explaining the attack or failure they address.
- Do not hide uncertainty when architecture or deployment details are missing.
Minimum output skeleton
## Summary
## Findings
## Structured outputs
## Risks
## Recommendations
## Recommended next skill
1---2name: session-security-reviewer3description: session-security-reviewer4---5# session-security-reviewer67## Purpose8Review session establishment, storage, rotation, expiry, revocation, and transport protections for web and API systems.910## Trigger this skill when11- The current artifact has security implications that need structured review or hardening.12- You need to turn vague security concerns into concrete findings, controls, or requirements.13- You want the next security-focused action to be explicit rather than ad hoc.1415## Expected inputs16- session design17- cookie/token settings18- expiry rules19- revocation model20- transport/security headers2122## Deliverables23- session findings24- lifecycle risks25- token/cookie hardening actions26- rotation/revocation issues27- recommended changes2829## Operating procedure301. Read the artifact from a security perspective and identify the concrete trust and exposure model.312. Separate facts from assumptions and call out missing information that affects confidence.323. Map the highest-risk paths first rather than trying to describe every possible issue equally.334. Translate findings into concrete control or requirement language that a builder can act on.345. Prefer explicit attack paths, assets, boundaries, and failure conditions over generic advice.356. Finish with the most sensible handoff skill based on the dominant risk area you found.3637## Quality gates38- Findings are specific to the artifact and threat context, not generic security boilerplate.39- Output separates facts, assumptions, risks, controls, and recommended next action.40- Prioritization reflects impact and exposure, not just the number of issues found.41- Recommendations are implementable and framed in a way that can be tested or reviewed later.4243## Handoff targets44- secure-defaults-checker45- secrets-handling-checker46- security-requirements-writer4748## Output style49- Be explicit about uncertainty.50- Prefer concrete attack paths and control implications over generic slogans.51- Separate facts, risks, recommendations, and next steps.52- Make the output usable by engineers, reviewers, and test designers.5354## Failure modes to avoid55- Do not confuse compliance language with real security risk reduction.56- Do not bury critical exposure behind long, unprioritized issue lists.57- Do not recommend controls without explaining the attack or failure they address.58- Do not hide uncertainty when architecture or deployment details are missing.5960## Minimum output skeleton61```md62## Summary63## Findings64## Structured outputs65## Risks66## Recommendations67## Recommended next skill68```