CSRF Protection Pattern Documentation Prompt

Use this prompt when you are a frontend security engineer, platform architect, or technical writer tasked with creating unambiguous, framework-specific documentation for Cross-Site Request Forgery (CSRF) defenses. The primary job-to-be-done is transforming a set of implementation decisions—such as choosing between a synchronizer token pattern or a double-submit cookie—into a structured, testable reference document that a developer can follow without introducing security gaps. This prompt excels when you need to enforce consistency across multiple services, ensure that SameSite cookie attributes are correctly documented alongside application-level controls, and provide copy-pasteable code examples for frameworks like Express, Django, or Next.js. It is designed for teams that treat security documentation as a product surface, where a missing Secure flag or an incorrect token extraction method in the docs can lead to a real vulnerability in production.

The ideal input context includes a concrete anti-CSRF strategy decision, the target framework or language, and any internal security policies that must be reflected in the documentation. You should provide the prompt with specific constraints such as [CONSTRAINTS: must use SameSite=Lax as baseline, token must be scoped to the user's session, no localStorage]. The prompt is most effective when you supply a detailed [OUTPUT_SCHEMA] that defines the required sections—for example, 'Token Generation,' 'Client-Side Integration,' 'Validation Endpoint,' and 'Common Misconfigurations'—so the generated output can be directly validated against a checklist. This is not a prompt for brainstorming security architectures; it assumes the architecture is already decided and the task is strictly documentation generation.

Do not use this prompt for generating actual cryptographic tokens, secrets, or any runtime security code that will be deployed without human review. It produces documentation only and must not be wired into a live token-generation pipeline. Similarly, avoid this prompt for general authentication flow documentation (e.g., OAuth grant types, session management lifecycle) or for threat modeling exercises. If you need to document a Single Page Application (SPA) that relies solely on Authorization headers with no cookie-based session, this prompt is not the right fit; its value is in documenting the defense-in-depth patterns that protect cookie-authenticated requests. After reading this section, proceed to the prompt template to copy and adapt it, then review the implementation harness to understand how to validate the output before it reaches a developer portal.

This prompt template generates comprehensive CSRF protection documentation for frontend security engineers. It covers token generation patterns, double-submit cookie implementations, custom header approaches, and framework-specific configuration. The template includes explicit validation checks to prevent common documentation gaps, particularly around SameSite cookie attributes and token storage guidance. Copy the template below and replace each square-bracket placeholder with your specific values before sending to the model.

codeCopy
You are a frontend security documentation engineer. Generate a complete CSRF protection reference document based on the following inputs.

[FRAMEWORK]: The target frontend or full-stack framework (e.g., Next.js, Express+React, Django, Rails, Spring Boot).
[CSRF_PATTERN]: The anti-CSRF pattern to document. Choose one: 'synchronizer-token', 'double-submit-cookie', 'custom-header', or 'all'.
[TOKEN_STORAGE]: Where tokens are stored client-side (e.g., 'memory', 'sessionStorage', 'cookie with HttpOnly+Secure+SameSite').
[ENDPOINT_EXAMPLES]: One or more example endpoints requiring CSRF protection, with HTTP methods and paths.
[AUTH_CONTEXT]: How the application handles authentication (e.g., 'session cookie', 'JWT in HttpOnly cookie', 'Bearer token in Authorization header').
[OUTPUT_SECTIONS]: List the required documentation sections from: 'overview', 'threat-model', 'token-generation', 'token-storage', 'token-transmission', 'server-validation', 'framework-config', 'ajax-integration', 'error-handling', 'testing', 'migration-guide'.
[CODE_LANGUAGE]: The primary language for code examples (e.g., 'TypeScript', 'Python', 'Java', 'Ruby').
[CONSTRAINTS]: Additional constraints such as 'no localStorage examples', 'include SameSite=Lax rationale', 'document token rotation', 'include CSP header recommendations'.

For each requested output section, provide:
1. A clear heading and purpose statement.
2. Step-by-step implementation instructions specific to [FRAMEWORK].
3. Runnable code examples in [CODE_LANGUAGE] with error handling.
4. Security considerations and common misconfigurations.

Before finalizing the output, validate that:
- SameSite cookie attribute is explicitly addressed for every cookie-based pattern.
- Token storage guidance never recommends localStorage for sensitive tokens.
- Every code example includes proper error handling for missing or invalid tokens.
- The threat model section explains what CSRF protects against and what it does not (e.g., XSS).
- If 'double-submit-cookie' is selected, the document explains why the cookie must not be HttpOnly.
- If 'custom-header' is selected, the document explains CORS preflight implications.
- All endpoint examples match the HTTP methods specified in [ENDPOINT_EXAMPLES].

Flag any sections you cannot complete due to missing information and explain what additional input is needed.

To adapt this template, start by filling in the [FRAMEWORK] and [CSRF_PATTERN] placeholders—these determine the entire shape of the output. If you select 'all' for [CSRF_PATTERN], the model will produce a comparison document covering every pattern, which is useful for architecture decision records. The [CONSTRAINTS] field is your primary quality lever: use it to enforce specific security requirements like 'never show localStorage' or 'include SameSite=Strict migration notes'. After generating the output, run the built-in validation checks manually or wire them into an eval harness to confirm the model did not skip SameSite guidance or produce insecure storage examples.

This prompt is designed to be integrated into a documentation generation pipeline where the primary input is a framework specification, an existing API route definition, or a security requirement ticket. The harness should treat the prompt as a single step in a larger workflow: collect context, generate the documentation draft, validate the output against a security checklist, and route for human review. Because CSRF misconfigurations are a high-severity vulnerability class, the implementation must never publish the generated documentation directly to a production docs site without a human approval gate.

The application layer should assemble the [FRAMEWORK], [AUTH_MECHANISM], and [ENDPOINT_CONTEXT] placeholders from structured sources—such as an OpenAPI spec, a framework detector (e.g., reading package.json or route annotations), and a session configuration object. Before calling the model, validate that the input includes the current SameSite cookie policy, the token storage mechanism (cookie, header, meta tag), and the HTTP method allowlist for the protected endpoints. If any of these fields are missing, the harness should either abort with a clear error or route to a human to supply the missing context. After the model returns the documentation draft, run a post-generation validator that checks for the presence of: SameSite attribute guidance, token rotation advice, a warning against using GET for state-changing operations, and explicit framework-specific code examples. If the validator flags missing sections, retry the prompt once with the validation errors appended as [CONSTRAINTS] before escalating to a human reviewer.

For model selection, prefer a model with strong instruction-following and code generation capabilities, such as Claude 3.5 Sonnet or GPT-4o. Set the temperature low (0.1–0.2) to maximize consistency across documentation versions. Log every generation attempt, including the assembled prompt, the raw model output, the validator results, and the final human review decision. Store these artifacts in an audit trail so that security reviewers can trace why a specific CSRF pattern was documented in a particular way. Avoid wiring this prompt into a fully automated CI/CD pipeline that publishes directly to production; the final step must always be a pull request or a review queue where a security engineer or senior developer confirms the documentation is accurate and does not introduce new vulnerabilities through omission or misleading examples.