Session Management Security Review Prompt

This prompt is built for a security architect or lead engineer who has a session management design document, an architecture diagram description, or a configuration specification and needs a rigorous, lifecycle-based threat review. The job-to-be-done is not a runtime penetration test or a code-level vulnerability scan; it is a design-level analysis that identifies missing controls, architectural weaknesses, and threat vectors across the entire session lifecycle: creation, storage, transmission, timeout, refresh, and termination. The ideal user brings a concrete design artifact and wants a structured output that maps specific threats—such as session fixation, hijacking, cross-device token replay, and logout CSRF—to the controls that are present, weak, or absent.

To use this prompt effectively, you must supply a detailed [DESIGN_SPEC] that describes the proposed session mechanism. This could include token types (opaque, JWT, reference), storage locations (cookies, local storage, secure enclaves), transmission channels, cookie attributes (Secure, HttpOnly, SameSite), timeout policies (idle, absolute), refresh token flows, and termination procedures. The prompt is not suitable for reviewing a live system's configuration or for generating a penetration test plan. It also should not be used in isolation; it belongs in a security review gate alongside an authentication flow review and an authorization model audit. The output is a structured threat analysis, not a compliance checklist, and it assumes the reviewer will apply their own judgment to the findings.

Before running the prompt, ensure the design spec is complete enough to reason about each lifecycle stage. A vague or incomplete spec will produce a vague analysis. After receiving the output, map each identified threat to a specific design change or acceptance of risk. Do not treat the AI's output as a final sign-off; it is a structured starting point for a human-led security review. The next step is to take the threat list and missing controls into a design discussion with the engineering team, updating the session management design before implementation begins.

The following prompt template is designed to be pasted directly into your AI workflow. It instructs the model to act as a security architect and perform a structured threat analysis of a session management design. The template uses square-bracket placeholders for all variable inputs, such as the design document, risk tolerance, and specific compliance standards. You must replace these placeholders with your concrete details before execution. The prompt is self-contained and forces the model to produce a structured output, making it suitable for direct integration into a CI/CD pipeline, a design review checklist, or an architecture decision record (ADR) workflow.

markdownCopy
You are a principal security architect reviewing a system's session management design. Your task is to produce a structured threat analysis covering the entire session lifecycle: creation, storage, transmission, refresh, and termination.

**DESIGN DOCUMENT:**
[DESIGN_DOCUMENT]

**REVIEW CONTEXT:**
- Risk Tolerance: [RISK_TOLERANCE, e.g., "moderate", "highly sensitive financial data"]
- Compliance Standards: [COMPLIANCE_STANDARDS, e.g., "OWASP ASVS V3", "PCI DSS", "NIST SP 800-63B"]
- Client Types: [CLIENT_TYPES, e.g., "SPA", "mobile native", "server-rendered web app"]

**OUTPUT SCHEMA:**
Return a valid JSON object with the following structure. Do not include any text outside the JSON object.
{
  "summary": "A one-paragraph executive summary of the session management posture.",
  "lifecycle_analysis": [
    {
      "phase": "One of: creation, storage, transmission, refresh, termination",
      "finding": "Description of a specific threat, misconfiguration, or missing control.",
      "severity": "critical | high | medium | low",
      "cve_or_owasp_ref": "Relevant CWE or OWASP ASVS reference, e.g., CWE-384.",
      "remediation": "A specific, actionable recommendation."
    }
  ],
  "cookie_attribute_audit": {
    "session_cookie_name": "[Inferred or 'unknown']",
    "secure_flag": "set | missing | unknown",
    "httponly_flag": "set | missing | unknown",
    "samesite_attribute": "Strict | Lax | None | missing | unknown",
    "path_attribute": "[value or 'unknown']",
    "domain_attribute": "[value or 'unknown']",
    "expires_maxage": "[value or 'unknown']"
  },
  "token_binding_assessment": "An assessment of whether token binding (e.g., mTLS, DPoP) is used to prevent token replay and hijacking. State 'not applicable' if no evidence is found.",
  "cross_device_risk": "An analysis of risks related to session transfer, QR-code login, or multi-device session continuity.",
  "overall_risk_rating": "critical | high | medium | low",
  "top_3_actions": ["Action 1", "Action 2", "Action 3"]
}

**CONSTRAINTS:**
- Base every finding on evidence in the provided design document. If a detail is not specified, state it as 'unknown' and explain the implied risk.
- Do not hallucinate features or controls not present in the design.
- Prioritize findings that could lead to session fixation, session hijacking, or unauthorized access.

To adapt this prompt, replace the placeholders in the REVIEW CONTEXT section with your project's specific parameters. The OUTPUT_SCHEMA is designed to be parsed by an application, so maintain its strict JSON structure. For high-risk deployments, ensure the output is not acted upon automatically; a human security engineer should review the generated lifecycle_analysis and validate the severity ratings before any remediation tickets are filed. The cookie_attribute_audit provides a quick, automatable check that can be compared against your security headers policy.

This prompt is designed to operate as a security review microservice within a larger architecture pipeline. It should be invoked programmatically after a design document or architecture specification has been parsed into a structured text block. The primary integration point is a CI/CD pipeline, a design review tool (like a structured Architecture Decision Record system), or a security chatbot. The harness must treat the model's output as a draft threat assessment, not a final verdict. Every finding must be traceable back to the input text or a well-known standard (like OWASP ASVS V3) before it is accepted.

The implementation harness requires a pre-processing step to extract the session management section from the broader design document. Feed the prompt only the relevant text to avoid context-window pollution and reduce the risk of the model hallucinating threats about unrelated components. After the model returns its JSON output, a validation layer must check for schema compliance: every threat object must have a non-empty finding, risk, and owasp_category field. Any output that fails this structural check should trigger a single retry with a more explicit formatting instruction appended to the original prompt. If the retry also fails, the task must be routed to a human review queue with the raw input and partial output attached.

For high-assurance environments, implement a two-pass evaluation. First, run the prompt as described to generate the initial threat list. Second, run a separate 'verification prompt' that takes the original design text and the generated threats as input, asking the model to confirm or refute each finding with direct quotes from the source material. This significantly reduces false positives. Log every invocation, including the model version, prompt template hash, input token count, and output schema version, to an immutable audit store. This traceability is critical for demonstrating due diligence during compliance audits. Never allow the model's output to automatically block a release; always require a human security engineer to approve or dismiss findings before the review is considered complete.