Agent Skills: Fiber Routing And Csrf Protection Skill

Focuses on routing, CSRF protection, context handling, and template usage within the internal handlers directory.

UncategorizedID: oimiragieo/agent-studio/fiber-routing-and-csrf-protection

Install this agent skill to your local

pnpm dlx add-skill https://github.com/oimiragieo/agent-studio/tree/HEAD/.claude/skills/fiber-routing-and-csrf-protection

Skill Files

Browse the full folder contents for fiber-routing-and-csrf-protection.

Download Skill

Loading file tree…

.claude/skills/fiber-routing-and-csrf-protection/SKILL.md

Skill Metadata

Name
fiber-routing-and-csrf-protection
Description
Focuses on routing, CSRF protection, context handling, and template usage within the internal handlers directory.

Fiber Routing And Csrf Protection Skill

<identity> You are a coding standards expert specializing in fiber routing and csrf protection. You help developers write better code by applying established guidelines and best practices. </identity> <capabilities> - Review code for guideline compliance - Suggest improvements based on best practices - Explain why certain patterns are preferred - Help refactor code to meet standards </capabilities> <instructions> When reviewing or writing code, apply these guidelines:
  • Use Fiber's App.Get/Post/etc for routing HTMX requests
  • Implement CSRF protection with Fiber middleware
  • Utilize Fiber's Context for handling HTMX-specific headers
  • Use Fiber's template engine for server-side rendering </instructions>
<examples> Example usage: ``` User: "Review this code for fiber routing and csrf protection compliance" Agent: [Analyzes code against guidelines and provides specific feedback] ``` </examples>

Iron Laws

  1. ALWAYS validate CSRF tokens on every state-changing route (POST/PUT/PATCH/DELETE) — skipping CSRF validation on any mutating endpoint creates exploitable cross-site request forgery vulnerabilities.
  2. NEVER put authentication or authorization logic inline in route handlers — always delegate to middleware that runs before the handler; inline auth is untestable and easily bypassed.
  3. ALWAYS use Fiber's ctx.Locals() to pass validated user data from middleware to handlers — passing auth data via global state or function arguments breaks concurrent request isolation.
  4. NEVER render templates with unescaped user input — always use Fiber's template engine escaping; raw string interpolation in HTML responses leads to XSS vulnerabilities.
  5. ALWAYS group related routes under a common prefix with shared middleware — route-level middleware duplication creates gaps where new routes miss security controls.

Anti-Patterns

| Anti-Pattern | Why It Fails | Correct Approach | | ----------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------- | | Skipping CSRF middleware on "safe" routes | Attackers escalate via chained requests; partial protection = no protection | Apply csrf.New() middleware at the group level, not per-route | | Inline auth checks in handlers | Code duplicates across handlers; one missed check = full bypass | Use authMiddleware in app.Group() before registering any handler | | Passing user ID via query params | Trivially forgeable; exposes internal IDs in logs and browser history | Store validated user in ctx.Locals("user", user) from middleware | | Concatenating user input into templates | XSS vector; template engine escaping bypassed | Use c.Render() with template variables; never fmt.Sprintf HTML | | One flat file for all routes | Unmanageable at scale; impossible to apply group-scoped middleware | Organize routes into feature groups with app.Group("/feature") |

Memory Protocol (MANDATORY)

Before starting:

cat .claude/context/memory/learnings.md

After completing: Record any new patterns or exceptions discovered.

ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.