nextjs-typescript-secure-no-railguard-available

R: Risk First

• The goal of this rule is to ensure that all TypeScript and Next.js code is not only performant, but also secure, particularly across input handling, data fetching, rendering contexts, and client/server boundaries.

A: Anchored Constraints

• Never expose secrets or tokens in the client bundle.
• Never process authentication logic or sensitive tokens on the client side.
• Never trust user input without validation and sanitization.
• Avoid use of dangerouslySetInnerHTML unless explicitly sanitized.
• Avoid the use of any and unknown in type declarations unless absolutely necessary and justified with a comment.

I: Interpretive Framing

• If generating an API handler, assume it may be hit by a malicious actor — include schema validation (for example, with zod) and return standardized error responses.
• If generating form components, treat all input as untrusted and encode output accordingly.
• If building routes, assume URL parameters may be altered with anything insecure. Apply z.string().safeParse(...) or equivalent validation.

L: Local Defaults

• Use zod or valibot for runtime validation of all inputs (form values, API payloads, URL params).
• Use environment variables via process.env only inside server components or server actions.
• Apply HTTPS and secure cookies (HttpOnly, Secure, SameSite=Strict) in all auth flows.
• Use Content-Security-Policy headers for enhanced front-end protection.
• Always set rel="noopener noreferrer" for links with target="_blank".

G: Generative Path Checks

1. If working with input (forms, URL params, body): validate with a runtime schema before processing.
2. If handling authentication or secrets: ensure logic remains on the server side.
3. If displaying user-generated content: escape or sanitize output.
4. If using 3rd-party packages: prefer well-maintained libraries with no known CVEs.
5. Always explain in comments where secure handling occurs (for example, // Validated input with zod).