Session Token Management Documentation Prompt

This prompt is designed for platform security engineers and technical writers who need to produce or audit documentation covering the full lifecycle of session tokens. The job-to-be-done is generating unambiguous, implementation-ready reference material that describes how tokens are created, stored, refreshed, revoked, and protected against common attacks like session fixation. The ideal user is someone who already understands their system's session architecture but needs to translate that into documentation that prevents integration errors and security misconfigurations by downstream developers.

Use this prompt when you need a structured, checklist-driven output that covers cookie attribute specifications (HttpOnly, Secure, SameSite), concurrency handling, and revocation mechanics. It is appropriate for new feature documentation, security audits of existing docs, or generating a baseline reference before a penetration test. The prompt requires concrete inputs: your session architecture details, token storage mechanisms, refresh policies, and any existing security constraints. Without these inputs, the model will produce plausible but potentially incorrect generalizations that could introduce security gaps.

Do not use this prompt as a substitute for a security review or to generate security policy from scratch without expert validation. It is not designed for documenting OAuth token flows, API key management, or JWT internals—those require separate, specialized prompts. The output must always be reviewed by a security engineer who can verify the accuracy of cookie attributes, the absence of session fixation vulnerabilities, and the correctness of revocation procedures before publication. If your session implementation is still in flux, fix the implementation first, then use this prompt to document the stable design.

This prompt template is designed for platform security teams who need to produce consistent, comprehensive documentation for session token lifecycles. It forces the model to address token creation, storage, refresh, concurrency, and revocation while mandating specific cookie attribute specifications (HttpOnly, Secure, SameSite) and requiring explicit checks for session fixation vulnerability descriptions. The template is structured to be wired into a documentation pipeline where the output must pass security review before publication.

textCopy
You are a senior security documentation engineer writing for an internal platform team. Your task is to produce a complete Session Token Management reference document from the provided specifications.

## INPUT
[API_SPECIFICATION]
[SESSION_CONFIGURATION]

## CONSTRAINTS
- Document the full session lifecycle: creation, storage, refresh, concurrency handling, and revocation.
- For every token storage mechanism, specify the exact cookie attributes: HttpOnly, Secure, SameSite, Domain, Path, and Max-Age or Expires.
- Include a dedicated section on session fixation: describe the vulnerability, how the current implementation prevents it, and what developers must never do (e.g., accept session IDs from URL parameters).
- Use the exact terminology from [GLOSSARY] for all auth-related terms.
- Every code example must be runnable and must not contain hardcoded secrets.
- Do not invent configuration values not present in [SESSION_CONFIGURATION].

## OUTPUT_SCHEMA
{
  "document_title": "string",
  "sections": [
    {
      "heading": "string",
      "content": "string (markdown)",
      "subsections": [
        {
          "heading": "string",
          "content": "string (markdown)",
          "code_examples": [
            {
              "language": "string",
              "code": "string",
              "description": "string"
            }
          ]
        }
      ]
    }
  ],
  "security_considerations": ["string"],
  "session_fixation_mitigation": "string (detailed markdown)"
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK_LEVEL
HIGH - Output requires security team review before publication.

To adapt this template, replace the square-bracket placeholders with your actual inputs. [API_SPECIFICATION] should contain the relevant endpoint definitions and auth schemes. [SESSION_CONFIGURATION] must include your token lifetime policies, cookie settings, and concurrency rules. [GLOSSARY] should be your organization's standardized auth terminology. [FEW_SHOT_EXAMPLES] is optional but strongly recommended: provide 1-2 examples of well-structured session documentation from your existing codebase to anchor the model's output style and depth. If your platform uses a specific framework (Express, Django, etc.), add a [FRAMEWORK] placeholder and constrain code examples to that stack. The output schema enforces a dedicated session_fixation_mitigation field, which you should validate in post-processing to ensure it contains concrete prevention mechanisms, not generic descriptions. Before wiring this into a CI/CD pipeline, run the output through a security review step and a schema validator that confirms all required cookie attributes are present.

This prompt is designed to be called programmatically as part of a documentation generation or review pipeline, not as a one-off chat interaction. The primary integration point is a CI/CD step that triggers whenever session management source code, configuration schemas, or security policies change. The application layer should supply the [INPUT] (raw source code, config files, or policy documents), [CONTEXT] (existing documentation, cookie attribute standards, and session fixation vulnerability descriptions), and [OUTPUT_SCHEMA] (a strict JSON schema defining the expected documentation structure). The model should be instructed to return only valid JSON conforming to that schema, which the harness then validates before merging into the documentation site.

The implementation harness must enforce several guardrails. First, validate the model's JSON output against the [OUTPUT_SCHEMA] using a library like ajv (for JSON Schema) or pydantic (for Python). If validation fails, retry the prompt once with the validation error message appended to the [CONSTRAINTS] block. Second, implement a content safety check: scan the generated documentation for any hardcoded secrets, example tokens that look real, or missing HttpOnly, Secure, and SameSite cookie attributes. Flag these for human review. Third, log every generation attempt—including the prompt hash, model version, output hash, and validation result—to an audit table. This is critical for security documentation, where a regressive prompt change could introduce dangerous advice.

For model choice, use a model with strong instruction-following and JSON mode capabilities, such as gpt-4o or claude-3.5-sonnet. Set temperature to 0.1 to maximize determinism. Do not use RAG for this workflow unless the [CONTEXT] includes a large corpus of internal security policies; the primary source of truth should be the [INPUT] code and configs. If the prompt includes a [RISK_LEVEL] of 'high', the harness should automatically route the output to a human security reviewer via a pull request, blocking automatic merge. The harness should also run a set of evals defined in the 'Evaluation and Testing' section—specifically, checks for session fixation descriptions, cookie attribute completeness, and revocation procedure clarity—and fail the pipeline if any eval score drops below a predefined threshold.