You do not need the CLI to use Fiber. But once you try fiber dev instead of manually restarting your server after every change, you will not go back.

Installation​

go install github.com/gofiber/cli/fiber@latest

Requires a recent Go version. After installation, fiber is available in your terminal.

fiber dev - Live Reload​

The most-used command. It watches your project files and restarts the server whenever something changes:

fiber dev

That is it. Edit a .go file, save, and your server restarts automatically. No external tools like Air or nodemon needed.

Customizing the Watch​

By default, fiber dev watches .go, .tmpl, .tpl, and .html files. You can adjust this:

# Watch additional file types
fiber dev -e go,tmpl,html,css,js

# Ignore specific directories
fiber dev -D assets,tmp,vendor,node_modules,dist

# Set a delay before restarting (avoid rapid restarts during save-all)
fiber dev -d 2s

# Run commands before each restart
fiber dev --pre-run="go generate ./..."

# Pass arguments to your app
fiber dev -a "-port=8080,-debug=true"

The --pre-run flag is powerful. If your project uses code generation, template compilation, or asset building, those commands run automatically before each restart.

Watch a Specific Target​

If your main.go is not in the project root:

fiber dev -t ./cmd/server

fiber new - Project Scaffolding​

Generate a new Fiber project from templates:

# Basic project structure
fiber new myapp

# With a custom Go module name
fiber new myapp github.com/yourname/myapp

# Complex project structure with more boilerplate
fiber new myapp -t complex

The basic template gives you a minimal Fiber project: main.go, go.mod, and a simple route. The complex template includes directory structure, configuration, middleware setup, and more.

Custom Templates​

You can generate projects from any GitHub repository:

# From a specific GitHub repo
fiber new myapp -t complex -r your-org/your-template

# From any Git URL
fiber new myapp -t complex -r https://gitlab.com/team/fiber-template.git

# SSH-based repo
fiber new myapp -t complex -r git@github.com:team/template.git

This lets your team maintain a standard project template and generate new services from it in seconds.

fiber serve - Static File Server​

Need to serve static files quickly? Maybe you are developing a frontend, reviewing a build output, or hosting documentation:

# Serve the current directory on :3000
fiber serve

# Serve a specific directory on a custom port
fiber serve --dir ./dist --addr :8080

# Enable directory browsing
fiber serve --browse

# Enable compression and CORS
fiber serve --compress --cors

# Serve with TLS
fiber serve --cert ./cert.pem --key ./key.pem

This is a full-featured static file server with caching, compression, CORS, health checks, byte-range requests, and optional TLS - all without writing a single line of Go code.

All serve options​

fiber migrate - Version Migration​

Upgrading Fiber versions usually means finding breaking changes, updating import paths, and adjusting API calls. The CLI automates this:

# Migrate to Fiber v3
fiber migrate --to 3.0.0

# Also refresh third-party modules (contrib, storage, template)
fiber migrate --to 3.0.0 --third-party contrib,storage,template

# Verbose output for debugging
fiber migrate --to 3.0.0 --verbose

The migration tool updates your go.mod, adjusts import paths, and runs go mod tidy automatically. It covers the mechanical work of migration so you can focus on the API changes that need manual attention.

fiber upgrade - Self-Update​

Keep the CLI itself up to date:

fiber upgrade

Checks for the latest release and updates in place.

fiber version​

Check your CLI and Fiber versions:

fiber version

Shows both the CLI version and the latest available version, so you know when an update is available.

The Development Workflow​

A typical development session with the Fiber CLI:

# Scaffold a new project
fiber new my-api github.com/myorg/my-api
cd my-api

# Start developing with live reload
fiber dev

# In another terminal, serve the frontend
fiber serve --dir ./frontend/dist --addr :8080 --cors

The CLI handles the infrastructure. You write the code.

Internal References​

• Fiber CLI Repository
• Recipes - for more project examples
• What's New in v3

That is what the Fiber Recipes repository is. Over 70 complete, runnable example projects covering everything from "Hello World" to clean architecture with Docker, OAuth2, and Kubernetes. Every recipe is a self-contained Go project with its own go.mod, main.go, and README.

Where to Find Them​

The recipes live in two places:

• Browse online: docs.gofiber.io/recipes - searchable, categorized, with full READMEs
• Clone and run: github.com/gofiber/recipes - git clone, cd into a recipe, go run .

Recipes by Category​

Authentication​

If you need authentication in your Fiber app, start with auth-jwt for the simplest case or auth-docker-postgres-jwt for a production-like setup.

Databases​

Deployment​

Real-Time​

Architecture Patterns​

Security​

How to Use a Recipe​

Every recipe follows the same pattern:

# Clone the recipes repository
git clone https://github.com/gofiber/recipes.git
cd recipes

# Pick a recipe
cd auth-jwt

# Read the README
cat README.md

# Run it
go run .

Most recipes start a server on :3000. Some require Docker for databases - the README tells you what you need.

Building on Recipes​

Recipes are starting points, not finished applications. The typical workflow:

1. Find a recipe that matches your use case
2. Copy it into your project (or use it as reference)
3. Adapt the code to your needs
4. Add production concerns (error handling, logging, config)

The clean-architecture and hexagonal recipes are especially useful as project templates - they show how to structure a larger Fiber application with layers, interfaces, and dependency injection.

Contributing Recipes​

If you have built something interesting with Fiber, the community would benefit from seeing it. The recipes repository accepts contributions following the existing pattern: one directory per recipe, a go.mod, a main.go, and a README.md that explains what the recipe demonstrates.

Internal References​

• Recipes Documentation
• Recipes Repository
• Awesome Fiber

The contrib packages are first-party middleware. Same team, same quality, same release cycle. The only difference is that they have external Go dependencies, so they are imported separately to keep your go.sum clean when you do not need them.

What is in Contrib​

The contrib repository contains 18+ middleware packages. Here are the ones you will reach for most often:

JWT Authentication​

The most popular contrib package. It validates JSON Web Tokens and protects routes:

import jwtware "github.com/gofiber/contrib/v3/jwt"

app.Use(jwtware.New(jwtware.Config{
    SigningKey: jwtware.SigningKey{Key: []byte("your-secret-key")},
}))

app.Get("/protected", func(c fiber.Ctx) error {
    user := c.Locals("user").(*jwt.Token)
    claims := user.Claims.(jwt.MapClaims)
    return c.JSON(fiber.Map{"user": claims["sub"]})
})

The middleware extracts the token from the Authorization: Bearer <token> header, validates it, and stores the parsed token in c.Locals("user"). Invalid or missing tokens return 401 automatically.

WebSocket​

Real-time communication with WebSocket support:

import "github.com/gofiber/contrib/v3/websocket"

app.Get("/ws", websocket.New(func(c *websocket.Conn) {
    for {
        mt, msg, err := c.ReadMessage()
        if err != nil {
            break
        }
        // Echo the message back
        c.WriteMessage(mt, msg)
    }
}))

The WebSocket middleware upgrades HTTP connections to WebSocket and gives you a connection object with ReadMessage / WriteMessage for bidirectional communication.

OpenTelemetry (otelfiber)​

Distributed tracing and metrics for your Fiber app:

import "github.com/gofiber/contrib/otelfiber/v2"

app.Use(otelfiber.Middleware())

One line. Every request gets a trace span with method, route, status code, and duration. The spans flow into whatever OpenTelemetry collector you have configured - Jaeger, Zipkin, Datadog, Grafana Tempo.

Swagger​

Auto-serve your Swagger/OpenAPI documentation:

import "github.com/gofiber/contrib/v3/swagger"

app.Use(swagger.New(swagger.Config{
    BasePath: "/api/",
    FilePath: "./docs/swagger.json",
    Path:     "docs",
}))

This serves the Swagger UI at /docs with your API specification. Generate the spec with tools like swag or write it manually.

Socket.io​

Full Socket.io server implementation for real-time event-based communication:

import "github.com/gofiber/contrib/v3/socketio"

socketio.On(socketio.EventMessage, func(ep *socketio.EventPayload) {
    ep.Kws.Emit([]byte("Hello back!"), socketio.TextMessage)
})

app.Get("/ws/:id", socketio.New(func(kws *socketio.Websocket) {}))

Circuit Breaker​

Protect your app from cascading failures when upstream services are down:

import "github.com/gofiber/contrib/v3/circuitbreaker"

app.Use(circuitbreaker.New(circuitbreaker.Config{
    Timeout:          5 * time.Second,
    MaxRequests:      3,
    Interval:         30 * time.Second,
    ReadyToTrip: func(counts circuitbreaker.Counts) bool {
        return counts.ConsecutiveFailures > 5
    },
}))

Load Shedding​

Reject excess traffic before it overwhelms your service:

import "github.com/gofiber/contrib/v3/loadshed"

app.Use(loadshed.New(loadshed.Config{
    MaxConcurrent: 100,
}))

When your service is at capacity, new requests get 503 instead of making everything slow.

More Contrib Packages​

Core vs. Contrib: How to Decide​

• If it has no external Go dependencies → it is in core (github.com/gofiber/fiber/v3/middleware/...)
• If it requires external libraries → it is in contrib (github.com/gofiber/contrib/...)

This split keeps your binary small. If you build an API that does not use JWT, you do not pull in the JWT library and its transitive dependencies.

v3 Support​

For Fiber v3, the contrib packages use a dedicated v3 base path. All v3-compatible imports start with github.com/gofiber/contrib/v3/:

// Fiber v3 import path
import jwtware "github.com/gofiber/contrib/v3/jwt"
import "github.com/gofiber/contrib/v3/websocket"
import "github.com/gofiber/contrib/v3/otelfiber"

The documentation shows the v3_ prefix in versioning to indicate Fiber v3 compatibility. Check each package's documentation page for the exact import path.

Internal References​

• Contrib Documentation
• JWT Middleware
• WebSocket
• OpenTelemetry
• Swagger
• Socket.io

The surprising part is not the number of engines. It is that switching from one engine to another requires changing exactly two lines of code: the import and the engine constructor. Your handlers, layouts, and rendering calls stay the same.

The Views Interface​

Every template engine implements Fiber's Views interface. Your handlers call c.Render() and Fiber delegates to whatever engine you configured:

app.Get("/", func(c fiber.Ctx) error {
    return c.Render("index", fiber.Map{
        "Title": "Welcome",
        "Items": items,
    })
})

This handler works identically whether you are using HTML templates, Pug, Django, or any other engine. The engine is configured once at startup and never referenced in handler code.

The 9 Engines​

Quick Start with html/template​

The most common choice - Go's built-in template engine with Fiber integration:

import (
    "github.com/gofiber/fiber/v3"
    "github.com/gofiber/template/html/v2"
)

func main() {
    // Point to your template directory and file extension
    engine := html.New("./views", ".html")

    app := fiber.New(fiber.Config{
        Views: engine,
    })

    app.Get("/", func(c fiber.Ctx) error {
        return c.Render("index", fiber.Map{
            "Title": "My App",
        })
    })

    app.Listen(":3000")
}

With a template file at ./views/index.html:

<!DOCTYPE html>
<html>
<head><title>{{.Title}}</title></head>
<body>
    <h1>{{.Title}}</h1>
</body>
</html>

Using Layouts​

Layouts let you define a shared structure (header, footer, navigation) and inject page content into it:

app.Get("/", func(c fiber.Ctx) error {
    return c.Render("index", fiber.Map{
        "Title": "Home",
    }, "layouts/main")
})

The layout file ./views/layouts/main.html:

<!DOCTYPE html>
<html>
<head><title>{{.Title}}</title></head>
<body>
    <nav><!-- shared navigation --></nav>
    {{embed}}
    <footer><!-- shared footer --></footer>
</body>
</html>

The {{embed}} tag marks where the page content is inserted. The page template (index.html) contains only the page-specific content.

Switching Engines​

Want to use Pug instead of HTML templates? Change two lines:

import "github.com/gofiber/template/pug/v2"

engine := pug.New("./views", ".pug")

Your handlers stay the same. Your layouts stay the same. Only the template files and the engine constructor change.

A Pug template for the same page:

h1= Title
p Welcome to #{Title}

Development Features​

Every engine supports features that make development easier:

engine := html.New("./views", ".html")

// Reload templates on every request (development only)
engine.Reload(true)

// Print parsed template names for debugging
engine.Debug(true)

// Add custom template functions
engine.AddFunc("upper", strings.ToUpper)
engine.AddFunc("formatDate", func(t time.Time) string {
    return t.Format("2006-01-02")
})

Reload(true) is essential during development - without it, you need to restart the server to see template changes. Disable it in production for performance.

Embedding Templates in the Binary​

For production deployments, you can embed templates into your Go binary using embed.FS:

import "embed"

//go:embed views/*
var viewsFS embed.FS

engine := html.NewFileSystem(http.FS(viewsFS), ".html")

This eliminates the need to ship template files alongside your binary. The templates are compiled into the executable, making deployment a single file copy.

When to Use Which Engine​

• Building a Go-native app? Use html - it is the standard, has the best tooling support, and is fast.
• Working with frontend developers who know Django/Jinja2? Use django - the syntax is familiar.
• Need clean, minimal markup? Use pug - indentation-based syntax reduces boilerplate.
• Rendering emails or simple content? Use mustache - logic-less templates force separation of concerns.
• Maximum rendering performance? Use jet - benchmarks show it is consistently fast.

Internal References​

• Template Documentation
• Templates Guide
• HTML Engine
• Django Engine
• Pug Engine

Most developers discover this the hard way: they build with the default in-memory storage, deploy to production, and realize their rate limiter resets on every restart and their sessions vanish during rolling deployments. The fix is not a rewrite - it is a one-line storage swap.

The Storage Interface​

Every storage driver implements the same interface:

type Storage interface {
    Get(key string) ([]byte, error)
    Set(key string, val []byte, exp time.Duration) error
    Delete(key string) error
    Reset() error
    Close() error
}

Five methods. That is the entire contract. Any middleware that accepts a Storage field works with any driver that implements this interface. No adapters, no wrappers, no glue code.

30+ Storage Drivers​

The gofiber/storage repository includes drivers for:

Key-Value Stores: Redis, Valkey, Rueidis, Memcache, Badger, Bbolt, Pebble, LevelDB, Ristretto, Etcd, NATS

SQL Databases: Postgres, MySQL, MSSQL, SQLite3

Cloud Services: DynamoDB, S3, Azure Blob, Cloudflare KV, Firestore, Minio

NoSQL / Document: MongoDB, ArangoDB, Couchbase, SurrealDB, Neo4j

Specialized: Aerospike, Cassandra, ScyllaDB, ClickHouse, Coherence, Memory

Every driver is tested against the latest two Go versions and has CI badges showing test status.

Picking the Right Storage​

The choice depends on your deployment:

Single Server, Simple App → SQLite3​

import "github.com/gofiber/storage/sqlite3/v3"

store := sqlite3.New(sqlite3.Config{
    Database: "./fiber_data.db",
})

No external dependencies. Survives restarts. Fast enough for most workloads. If your app runs on one server and you do not want to manage Redis, this is your answer.

Multiple Servers, Production → Redis​

import "github.com/gofiber/storage/redis/v3"

store := redis.New(redis.Config{
    Host:     "redis.internal",
    Port:     6379,
    Password: os.Getenv("REDIS_PASSWORD"),
    Database: 0,
})

Redis is the production default for a reason: fast, shared across instances, supports TTL natively, and you probably already have one running for caching.

Already Using Postgres → Postgres​

import "github.com/gofiber/storage/postgres/v3"

store := postgres.New(postgres.Config{
    Host:     "db.internal",
    Port:     5432,
    Username: "app",
    Password: os.Getenv("DB_PASSWORD"),
    Database: "myapp",
    Table:    "fiber_storage",
})

If your app already connects to Postgres, adding a fiber_storage table avoids a new infrastructure dependency. The driver creates the table automatically on first use.

AWS / Serverless → DynamoDB​

import "github.com/gofiber/storage/dynamodb/v2"

store := dynamodb.New(dynamodb.Config{
    Table: "fiber-sessions",
})

For serverless or AWS-native deployments, DynamoDB scales without management and integrates with IAM for authentication.

Development / Testing → Memory​

import "github.com/gofiber/storage/memory/v2"

store := memory.New()

Fast, zero config, no persistence. Use this for tests and local development where data loss on restart is fine.

Using Storage with Middleware​

Once you have a store, pass it to any middleware that accepts a Storage field:

store := redis.New(redis.Config{Host: "localhost", Port: 6379})

// Rate limiter  -  shared counters across instances
app.Use(limiter.New(limiter.Config{
    Max:        100,
    Expiration: time.Minute,
    Storage:    store,
}))

// Cache  -  shared cache across instances
app.Use(cache.New(cache.Config{
    Expiration:   30 * time.Minute,
    Storage:      store,
}))

// Sessions  -  persistent across restarts
sessionStore := session.New(session.Config{
    Storage: store,
})
app.Use(sessionStore.Handler())

Three middleware, one storage backend, zero code changes when you switch from Redis to Postgres.

Swapping Storage Without Code Changes​

A common pattern is to select the storage backend from an environment variable:

func newStorage() fiber.Storage {
    switch os.Getenv("STORAGE_BACKEND") {
    case "redis":
        return redis.New(redis.Config{
            Host: os.Getenv("REDIS_HOST"),
            Port: 6379,
        })
    case "postgres":
        return postgres.New(postgres.Config{
            ConnectionURI: os.Getenv("DATABASE_URL"),
        })
    default:
        return memory.New()
    }
}

This lets you run with in-memory storage locally and Redis in production without changing any middleware configuration.

Benchmarks​

Storage benchmarks are published at gofiber.github.io/storage/benchmarks. Before picking a backend for a high-throughput use case, check the numbers. The short version: Redis and Memory are fastest for reads, SQLite3 is surprisingly competitive for single-server workloads, and cloud-based stores (DynamoDB, S3) add network latency but scale infinitely.

Where to Start​

If you are using default in-memory storage in production, switch to Redis or SQLite3 today. It is a one-line change that prevents data loss on restart and makes your rate limiters and sessions work correctly across deployments.

Internal References​

• Storage Packages Documentation
• Session Middleware
• Limiter Middleware
• Cache Middleware

This sounds like a small change. It is not. The new approach changes how you initialize sessions, how you access them in handlers, and how you handle the interaction between sessions and other middleware like CSRF. If you migrate without understanding the new model, you will spend hours debugging session data that silently disappears.

The Old Way vs. The New Way​

In Fiber v2, you created a session store and manually got/saved sessions in every handler:

// v2 pattern  -  no longer works in v3
store := session.New()

app.Get("/", func(c *fiber.Ctx) error {
    sess, _ := store.Get(c)
    name := sess.Get("name")
    sess.Save()
    // ...
})

In v3, sessions are middleware. You register the store once, and sessions are automatically loaded and saved:

// v3 pattern
sessionStore := session.New()

app.Use(sessionStore.Handler())

app.Get("/", func(c fiber.Ctx) error {
    sess := session.FromContext(c)
    name, _ := sess.Get("name").(string)
    // No manual Save() needed  -  the middleware handles it
    return c.SendString("Hello, " + name)
})

The key differences:

• Middleware-based: Register once with app.Use(), not per-handler
• Automatic lifecycle: Sessions are loaded before your handler and saved after
• Context access: Use session.FromContext(c) instead of store.Get(c)

Configuring the Session Store​

The session store controls cookie behavior and storage backend:

sessionStore := session.New(session.Config{
    CookieName:        "__Host-session",
    CookieSecure:      true,
    CookieHTTPOnly:    true,
    CookieSameSite:    "Lax",
    CookieSessionOnly: true,  // Cookie expires when browser closes
    IdleTimeout:       30 * time.Minute,
})

Cookie Name: Use the __Host- Prefix​

The __Host- prefix is a browser security feature. Browsers enforce that cookies with this prefix:

• Must have Secure set to true
• Must not have a Domain attribute (scoped to the exact host)
• Must have Path set to /

This prevents subdomain cookie injection attacks. If an attacker controls evil.example.com, they cannot set a cookie for app.example.com when the __Host- prefix is used.

CookieHTTPOnly: Almost Always True​

Set this to true unless your JavaScript needs to read the session cookie. For sessions, there is almost never a reason for JavaScript to access the session ID - the browser sends it automatically with every request.

IdleTimeout vs. AbsoluteTimeout​

Two different timeout concepts:

• IdleTimeout: How long a session survives without activity. Each request resets the timer. Default: 30 minutes.
• AbsoluteTimeout: Maximum session lifetime regardless of activity. Default: 0 (no absolute limit).

For a typical web app:

sessionStore := session.New(session.Config{
    IdleTimeout:      30 * time.Minute,  // Inactive users get logged out
    AbsoluteTimeout:  24 * time.Hour,    // Everyone gets logged out after 24h
})

The absolute timeout is important for security. Without it, a session that stays active forever is a session that can be stolen forever.

Storage Backends​

By default, sessions are stored in memory. This works for development but fails in production for two reasons: memory fills up, and sessions are lost on restart.

Redis - The Production Default​

import "github.com/gofiber/storage/redis/v3"

storage := redis.New(redis.Config{
    Host:     "localhost",
    Port:     6379,
    Password: "",
    Database: 0,
})

sessionStore := session.New(session.Config{
    Storage: storage,
})

Redis is the natural choice: fast, persistent across restarts, and supports TTL natively. If you are already using Redis for caching, reuse the same instance with a different database number.

SQLite - For Small Apps​

import "github.com/gofiber/storage/sqlite3/v3"

storage := sqlite3.New(sqlite3.Config{
    Database: "./sessions.db",
})

SQLite works well for single-server deployments where you do not want to run Redis. Sessions survive restarts, and the performance is sufficient for small to medium traffic.

Postgres or MySQL - When You Already Have One​

import "github.com/gofiber/storage/postgres/v3"

storage := postgres.New(postgres.Config{
    Host:     "localhost",
    Port:     5432,
    Username: "app",
    Password: "secret",
    Database: "myapp",
    Table:    "sessions",
})

If your app already connects to Postgres or MySQL, using it for sessions avoids adding another infrastructure dependency.

Session + CSRF: The Order That Matters​

When using sessions with CSRF protection, the session middleware must come before CSRF:

// Correct order
app.Use(sessionStore.Handler())  // Sessions first
app.Use(csrf.New(csrf.Config{
    Session: sessionStore,       // CSRF uses the session store
}))

CSRF in session mode stores the CSRF token inside the user's session. If the session middleware has not run yet, CSRF cannot access the session and token validation fails silently.

Working with Session Data​

Setting Values​

app.Post("/login", func(c fiber.Ctx) error {
    sess := session.FromContext(c)

    sess.Set("userID", user.ID)
    sess.Set("role", user.Role)
    sess.Set("loginAt", time.Now().Unix())

    return c.Redirect().To("/dashboard")
})

Getting Values​

Session values are stored as any, so you need type assertions:

app.Get("/dashboard", func(c fiber.Ctx) error {
    sess := session.FromContext(c)

    userID, ok := sess.Get("userID").(uint64)
    if !ok {
        return c.Redirect().To("/login")
    }

    return c.JSON(fiber.Map{"userID": userID})
})

Destroying Sessions (Logout)​

app.Post("/logout", func(c fiber.Ctx) error {
    sess := session.FromContext(c)

    if err := sess.Destroy(); err != nil {
        return err
    }

    return c.Redirect().To("/login")
})

Destroy() removes all session data from storage and clears the session cookie. After calling Destroy(), any subsequent sess.Get() calls in the same request return nil.

Regenerating Session IDs​

After authentication state changes - login, logout, privilege escalation - regenerate the session ID to prevent session fixation attacks:

app.Post("/login", func(c fiber.Ctx) error {
    sess := session.FromContext(c)

    // Authenticate user...

    // Regenerate session ID to prevent fixation
    if err := sess.Regenerate(); err != nil {
        return err
    }

    sess.Set("userID", user.ID)
    return c.Redirect().To("/dashboard")
})

This creates a new session ID while preserving the existing session data. The old session ID becomes invalid.

The Middleware You Should Pair with Sessions​

Sessions rarely work alone. Here is the typical middleware stack for an authenticated app:

app := fiber.New()

// 1. Security headers
app.Use(helmet.New())

// 2. Sessions  -  before anything that needs auth state
app.Use(sessionStore.Handler())

// 3. CSRF  -  uses session store
app.Use(csrf.New(csrf.Config{
    Session:        sessionStore,
    CookieSecure:   true,
    CookieHTTPOnly: true,
}))

// 4. Auth middleware  -  checks session for user
app.Use(authMiddleware)

// 5. Routes
app.Get("/dashboard", dashboardHandler)

The order is not arbitrary. Each layer depends on the one above it.

Where to Start​

If you are migrating from v2 sessions, start by switching to the middleware pattern. Register sessionStore.Handler() early in your middleware stack, replace all store.Get(c) calls with session.FromContext(c), and remove manual sess.Save() calls. The middleware handles saving automatically.

If you are starting fresh, use Redis as your storage backend and set up the __Host- cookie prefix from day one. These two decisions prevent the most common session-related production issues.

Internal References​

• Session Middleware
• CSRF Middleware
• Encrypt Cookie Middleware
• Storage Packages

Production file handling needs three things the tutorials skip: size limits that protect your server, type validation that goes beyond the extension, and storage patterns that do not block your event loop.

Single File Upload​

The basic pattern is straightforward. Fiber parses multipart forms and gives you a *multipart.FileHeader:

app.Post("/upload", func(c fiber.Ctx) error {
    file, err := c.FormFile("document")
    if err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "No file uploaded")
    }

    // Save to disk
    err = c.SaveFile(file, fmt.Sprintf("./uploads/%s", file.Filename))
    if err != nil {
        return fiber.NewError(fiber.StatusInternalServerError, "Failed to save file")
    }

    return c.JSON(fiber.Map{
        "filename": file.Filename,
        "size":     file.Size,
    })
})

This works but has problems. The filename comes from the client - it could contain path traversal characters like ../. The file could be any size. The file could be anything, not just a document.

Never Trust the Filename​

The first rule of file uploads: never use the client's filename directly. A malicious client can send a filename like ../../etc/passwd or ../../../app/config.yaml.

Generate your own filenames. This example uses github.com/google/uuid - install it with go get github.com/google/uuid:

import (
    "fmt"
    "path/filepath"

    "github.com/gofiber/fiber/v3"
    "github.com/google/uuid"
)

app.Post("/upload", func(c fiber.Ctx) error {
    file, err := c.FormFile("avatar")
    if err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "No file uploaded")
    }

    // Generate a safe filename
    ext := filepath.Ext(file.Filename)
    safeName := fmt.Sprintf("%s%s", uuid.New().String(), ext)
    savePath := filepath.Join("./uploads", safeName)

    if err := c.SaveFile(file, savePath); err != nil {
        return err
    }

    return c.JSON(fiber.Map{"path": safeName})
})

Setting Body Limits​

By default, Fiber (via fasthttp) allows request bodies up to 4MB. For file uploads, you probably want to change this:

app := fiber.New(fiber.Config{
    BodyLimit: 50 * 1024 * 1024, // 50MB
})

When a client sends a body larger than this limit, Fiber returns 413 Request Entity Too Large automatically. No parsing, no disk usage, no memory allocation for the oversized body.

For different limits on different routes, use the limiter approach:

// Small limit for API routes
api := app.Group("/api")
api.Use(func(c fiber.Ctx) error {
    if c.Request().Header.ContentLength() > 1*1024*1024 {
        return fiber.ErrRequestEntityTooLarge
    }
    return c.Next()
})

// Larger limit for upload routes
app.Post("/upload", uploadHandler)

Validating File Types​

The file extension means nothing - anyone can rename a file. Check the actual content by reading the first bytes and detecting the MIME type:

import "net/http"

func validateFileType(file *multipart.FileHeader, allowed []string) error {
    f, err := file.Open()
    if err != nil {
        return err
    }
    defer f.Close()

    // Read the first 512 bytes for MIME detection
    buf := make([]byte, 512)
    n, err := f.Read(buf)
    if err != nil {
        return err
    }

    mimeType := http.DetectContentType(buf[:n])

    for _, a := range allowed {
        if mimeType == a {
            return nil
        }
    }

    return fmt.Errorf("file type %s is not allowed", mimeType)
}

Use it in your handler:

app.Post("/avatar", func(c fiber.Ctx) error {
    file, err := c.FormFile("avatar")
    if err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "No file uploaded")
    }

    // Only allow images
    allowed := []string{"image/jpeg", "image/png", "image/webp"}
    if err := validateFileType(file, allowed); err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "Only JPEG, PNG, and WebP images are allowed")
    }

    safeName := fmt.Sprintf("%s%s", uuid.New().String(), filepath.Ext(file.Filename))
    return c.SaveFile(file, filepath.Join("./uploads", safeName))
})

http.DetectContentType uses the first 512 bytes of the file to determine the MIME type based on the file's magic bytes. It is not foolproof - a determined attacker can craft files that pass detection - but it blocks casual misuse and accidental uploads of wrong file types.

Multiple File Uploads​

Fiber handles multiple files from the same form field:

app.Post("/gallery", func(c fiber.Ctx) error {
    form, err := c.MultipartForm()
    if err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "Invalid form data")
    }

    files := form.File["photos"]
    if len(files) == 0 {
        return fiber.NewError(fiber.StatusBadRequest, "No photos uploaded")
    }

    if len(files) > 10 {
        return fiber.NewError(fiber.StatusBadRequest, "Maximum 10 photos allowed")
    }

    var saved []string
    for _, file := range files {
        safeName := fmt.Sprintf("%s%s", uuid.New().String(), filepath.Ext(file.Filename))
        savePath := filepath.Join("./uploads/gallery", safeName)

        if err := c.SaveFile(file, savePath); err != nil {
            return err
        }
        saved = append(saved, safeName)
    }

    return c.JSON(fiber.Map{
        "uploaded": len(saved),
        "files":    saved,
    })
})

Always limit the number of files. Without a count limit, a client could send thousands of files in a single request and exhaust your disk I/O.

Mixed File and Data Uploads​

Often you need metadata alongside the file - a title, description, or category:

type DocumentUpload struct {
    Title    string `form:"title"`
    Category string `form:"category"`
}

app.Post("/documents", func(c fiber.Ctx) error {
    var meta DocumentUpload
    if err := c.Bind().Body(&meta); err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "Invalid form data")
    }

    file, err := c.FormFile("file")
    if err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "No file uploaded")
    }

    safeName := fmt.Sprintf("%s%s", uuid.New().String(), filepath.Ext(file.Filename))
    if err := c.SaveFile(file, filepath.Join("./uploads", safeName)); err != nil {
        return err
    }

    return c.JSON(fiber.Map{
        "title":    meta.Title,
        "category": meta.Category,
        "file":     safeName,
        "size":     file.Size,
    })
})

The client sends a multipart/form-data request with both form fields and file parts. Fiber's binding handles the form fields, and FormFile handles the file.

Cleaning Up on Error​

If saving to database fails after the file is written to disk, you have an orphaned file. Clean up explicitly:

app.Post("/upload", func(c fiber.Ctx) error {
    file, err := c.FormFile("file")
    if err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "No file uploaded")
    }

    safeName := fmt.Sprintf("%s%s", uuid.New().String(), filepath.Ext(file.Filename))
    savePath := filepath.Join("./uploads", safeName)

    if err := c.SaveFile(file, savePath); err != nil {
        return err
    }

    // Try to save metadata to database
    if err := db.SaveFileRecord(safeName, file.Size); err != nil {
        // Clean up the file we just saved
        os.Remove(savePath)
        return err
    }

    return c.JSON(fiber.Map{"file": safeName})
})

This pattern prevents disk space from filling up with files that have no database record pointing to them.

Where to Start​

If your current upload handler uses the client filename directly, fix that first - it is a path traversal vulnerability. Then add body limits and file type validation. These three changes cover the most common attack vectors and the most common production incidents.

Internal References​

• Ctx FormFile
• Ctx MultipartForm
• Ctx SaveFile
• Bind

But Fiber has a trick that most Go frameworks do not: prefork mode. One line of config, and Fiber spawns multiple OS processes, each with its own event loop, all listening on the same port. It is the same pattern that Nginx and Node.js cluster mode use.

The surprise is not that Fiber supports this. The surprise is when it actually helps - and when it makes your app slower.

What Prefork Does​

In normal mode, Fiber runs one process with one fasthttp server. That server uses goroutines to handle concurrent requests. It works well for most workloads.

In prefork mode, Fiber uses SO_REUSEPORT (on Linux) to let multiple processes bind to the same port. The kernel distributes incoming connections across the processes:

app := fiber.New()

app.Listen(":3000", fiber.ListenConfig{
    EnablePrefork: true,
})

That is it. One setting in ListenConfig. Fiber detects the number of CPU cores and spawns that many child processes. Each child is a full copy of your application with its own memory space.

Note: In Fiber v2, this was fiber.Config{Prefork: true}. In v3, it moved to ListenConfig as EnablePrefork.

How It Works Under the Hood​

When you start a preforked Fiber app:

1. The master process starts and detects it is the parent.
2. It forks runtime.GOMAXPROCS(0) child processes (typically one per CPU core).
3. Each child process creates its own fasthttp server and binds to the same port.
4. The kernel's SO_REUSEPORT distributes incoming connections across children.
5. The master monitors children and restarts them if they crash.

Each child is an independent OS process with its own Go runtime, its own goroutine scheduler, and its own memory. There is no shared state between children.

When It Actually Helps​

Prefork mode helps in a very specific scenario: CPU-bound workloads that saturate the Go scheduler.

Go's runtime scheduler is good, but it has overhead. When every request requires heavy computation - image processing, cryptographic operations, complex template rendering - the scheduler's lock contention becomes measurable. Prefork eliminates cross-process scheduler contention because each process has its own scheduler.

Benchmarks show measurable improvement (10-20% more throughput) for:

• Heavy JSON serialization/deserialization
• Template rendering with complex logic
• Image processing or PDF generation
• Cryptographic operations per request

When It Makes Things Worse​

For the vast majority of web applications - API servers that do database queries, call upstream services, and return JSON - prefork mode is neutral or harmful.

Why it can hurt:

1. Memory multiplication: Each child is a full process. An app that uses 100MB of memory now uses 100MB × number of cores. On a 16-core machine, that is 1.6GB just for the Go runtime and your app code.

2. No shared state: In-memory caches, rate limiter counters, session stores - none of these work across prefork children. A rate limiter that allows 100 requests per minute will actually allow 100 × number of children because each child has its own counter.

3. Connection pool multiplication: Each child opens its own database connections. If your pool is set to 20 connections and you have 8 children, that is 160 database connections. Your database might not appreciate that.

4. I/O-bound workloads see no benefit: If your handler spends 95% of its time waiting for a database response, the CPU is mostly idle. Adding more processes to share an idle CPU does not help.

The Shared State Problem​

This is the biggest gotcha. Consider this rate limiter:

app.Use(limiter.New(limiter.Config{
    Max:        100,
    Expiration: time.Minute,
}))

Without prefork, this allows 100 requests per IP per minute. With prefork on 8 cores, each child has its own counter, so the effective limit is 800 requests per minute.

The fix is to use an external store:

import "github.com/gofiber/storage/redis/v3"

store := redis.New(redis.Config{
    Host: "localhost",
    Port: 6379,
})

app.Use(limiter.New(limiter.Config{
    Max:        100,
    Expiration: time.Minute,
    Storage:    store,
}))

This applies to every middleware that maintains state: sessions, CSRF tokens, cache. If you use prefork, all stateful middleware needs an external storage backend.

Detecting Prefork in Your Code​

Sometimes you need to know whether you are running in the master or a child:

if fiber.IsChild() {
    // This is a prefork child process
    // Don't start background jobs, cron schedulers, etc.
} else {
    // This is the master process (or non-prefork mode)
    // Safe to start background jobs
}

This is important for background workers. If you start a cron job in your app, prefork mode would start 8 copies of it. Use fiber.IsChild() to only start background work in the master.

The Decision Framework​

Use prefork when:

• Your profiling shows CPU is the bottleneck (not I/O)
• Your workload is compute-heavy per request
• You already use external storage for all state (Redis, database)
• You have enough memory for process multiplication

Do not use prefork when:

• Your app is I/O-bound (most API servers)
• You rely on in-memory state (rate limiters, caches, sessions)
• Memory is constrained
• You are running in containers with limited CPU allocation

The default - no prefork - is correct for most applications. Go's goroutine scheduler is highly efficient for I/O-bound work. Only switch to prefork after profiling shows that CPU scheduling is your actual bottleneck.

Measuring the Difference​

Before turning on prefork, establish a baseline:

# Without prefork
go build -o app .
./app &
wrk -t12 -c400 -d30s http://localhost:3000/your-endpoint

# With prefork
PREFORK=true ./app &
wrk -t12 -c400 -d30s http://localhost:3000/your-endpoint

Compare the requests/second and latency percentiles. If prefork does not show at least a 10% improvement, the operational complexity is not worth it.

Internal References​

• App Configuration - Prefork
• Make Fiber Faster
• Benchmarks

The problem is three settings you did not configure. Fiber, by default, does not trust proxy headers - and it should not. But when you deploy behind a reverse proxy, you need to explicitly tell Fiber which headers to read and which proxies to trust.

The Three Settings​

Every Fiber app behind a reverse proxy needs exactly three configuration options:

app := fiber.New(fiber.Config{
    TrustProxy:  true,                           // 1. Enable proxy trust
    ProxyHeader: fiber.HeaderXForwardedFor,       // 2. Which header has the real IP
    TrustProxyConfig: fiber.TrustProxyConfig{     // 3. Which proxies to trust
        Loopback: true,
    },
})

Without these, c.IP() returns the proxy's IP address, not the client's. With them configured wrong, an attacker can forge any IP address they want.

Why Fiber Ignores Proxy Headers by Default​

When Fiber receives a request, c.IP() returns the remote address of the TCP connection. If the connection comes from Nginx on the same machine, that IP is 127.0.0.1.

Reverse proxies add headers like X-Forwarded-For to carry the real client IP. But Fiber ignores these headers unless you enable TrustProxy. This is correct behavior - if Fiber blindly trusted X-Forwarded-For, any client could set the header directly and claim to be any IP address.

The trust model is: "I will read the real IP from a header, but only if the request came from a proxy I explicitly trust."

Setting 1: TrustProxy​

TrustProxy: true,

This is the switch that enables proxy header reading. Without it, the other settings do nothing. But this alone is not enough - you also need to tell Fiber which header and which proxies.

Setting 2: ProxyHeader​

Different proxies use different headers:

The most common choice is X-Forwarded-For, but check your proxy's documentation. Using the wrong header means c.IP() returns an empty string or an incorrect value.

ProxyHeader: fiber.HeaderXForwardedFor,

Setting 3: TrustProxyConfig​

This is where most people get it wrong. You need to specify which IPs are allowed to set the proxy header:

TrustProxyConfig: fiber.TrustProxyConfig{
    // Specific IPs or CIDR ranges
    Proxies: []string{
        "10.10.0.58",
        "192.168.0.0/24",
    },
},

Or use convenience flags:

TrustProxyConfig: fiber.TrustProxyConfig{
    Loopback:  true,  // 127.0.0.0/8, ::1/128
    Private:   true,  // 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
    LinkLocal: true,  // 169.254.0.0/16, fe80::/10
},

Use Loopback: true when the proxy is on the same machine. Use Private: true when the proxy is on your internal network. Use specific IPs when you know the exact proxy addresses and want maximum security.

What Happens When You Skip This​

If you set TrustProxy: true without configuring TrustProxyConfig, Fiber trusts nobody - and c.IP() still returns the TCP source address. The setting only works when both sides are configured.

What Happens When You Trust Everyone​

If you somehow trusted all addresses, any client could set X-Forwarded-For: 1.2.3.4 and your app would believe them. This breaks:

• Rate limiting: An attacker rotates fake IPs to bypass limits
• IP-based access control: Attackers spoof allowed IPs
• Audit logs: Every logged IP is fake
• Geo-IP: Attackers appear to be from any country

Real-World Configurations​

Nginx on the Same Machine​

The simplest case: Nginx and Fiber on the same server.

Nginx config:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Fiber config:

app := fiber.New(fiber.Config{
    TrustProxy:  true,
    ProxyHeader: fiber.HeaderXForwardedFor,
    TrustProxyConfig: fiber.TrustProxyConfig{
        Loopback: true,
    },
})

Traefik in Docker​

Traefik typically runs in the same Docker network:

app := fiber.New(fiber.Config{
    TrustProxy:  true,
    ProxyHeader: fiber.HeaderXForwardedFor,
    TrustProxyConfig: fiber.TrustProxyConfig{
        Private: true, // Docker networks use private IPs
    },
})

Cloudflare → Nginx → Fiber​

When you have multiple proxies in a chain, each one appends to X-Forwarded-For. The header might look like: 203.0.113.50, 198.51.100.178, 127.0.0.1.

Fiber reads the rightmost untrusted IP. With Loopback: true, it skips 127.0.0.1 (Nginx) and returns the next one. But the Cloudflare IP (198.51.100.178) needs to be trusted too.

For Cloudflare, use CF-Connecting-IP instead - it is always the real client IP regardless of proxy chain:

app := fiber.New(fiber.Config{
    TrustProxy:  true,
    ProxyHeader: "CF-Connecting-IP",
    TrustProxyConfig: fiber.TrustProxyConfig{
        Loopback: true,
    },
})

Detecting HTTPS Behind a Proxy​

When Nginx terminates TLS, Fiber's connection is plain HTTP. c.Protocol() returns "http" even though the client used HTTPS. This breaks CSRF (which checks the Referer scheme) and redirect logic.

The fix is the X-Forwarded-Proto header. Nginx sets it (see the config above), and Fiber reads it automatically when TrustProxy is enabled. No additional configuration needed - c.Protocol() will return "https" when the proxy says so.

A Debug Endpoint​

When setting up, add a temporary debug endpoint to verify everything works:

app.Get("/debug/proxy", func(c fiber.Ctx) error {
    return c.JSON(fiber.Map{
        "c.IP()":           c.IP(),
        "c.IPs()":          c.IPs(),
        "c.Protocol()":     c.Protocol(),
        "IsProxyTrusted":   c.IsProxyTrusted(),
        "X-Forwarded-For":  c.Get("X-Forwarded-For"),
        "X-Forwarded-Proto": c.Get("X-Forwarded-Proto"),
    })
})

Hit this endpoint and verify that c.IP() shows the real client IP and c.Protocol() shows https. Remove the endpoint before deploying to production.

Internal References​

• Reverse Proxy Guide
• App Configuration
• Ctx IP Method

Except it is not. The default Helmet config does not set HSTS. The default CORS config allows every origin. The default CSRF config uses insecure cookies. And the order you register them in? That matters more than you think.

Most Fiber applications in production run with at least one of these misconfigured. Here is how to set them up so they actually protect your users.

Why Order Matters​

Middleware in Fiber executes in registration order. For security middleware, this creates dependencies:

1. Helmet should come first - it sets response headers on every request regardless of outcome.
2. CORS should come next - it handles preflight OPTIONS requests and may short-circuit before your routes run.
3. CSRF should come after CORS - it needs the Origin header that CORS validates, and it should not interfere with preflight requests.

app := fiber.New()

// 1. Security headers on every response
app.Use(helmet.New(helmet.Config{
    // Config below
}))

// 2. CORS for cross-origin access
app.Use(cors.New(cors.Config{
    // Config below
}))

// 3. CSRF protection for state-changing requests
app.Use(csrf.New(csrf.Config{
    // Config below
}))

If you put CSRF before CORS, preflight OPTIONS requests will fail CSRF validation and your frontend will get 403 errors before the actual request is even sent.

Helmet: The Defaults That Leave Gaps​

Helmet adds security headers to every response. The default configuration is reasonable, but it misses two critical settings for production.

Missing: HSTS​

HTTP Strict Transport Security tells browsers to always use HTTPS. The default HSTSMaxAge is 0, which means the header is not sent at all:

app.Use(helmet.New(helmet.Config{
    HSTSMaxAge:         63072000, // 2 years in seconds
    HSTSPreloadEnabled: true,
    // include subdomains by default (HSTSExcludeSubdomains is false)
}))

Without HSTS, a user who types http://yoursite.com makes an unencrypted request before the redirect to HTTPS. An attacker on the same network can intercept that request.

Missing: Content Security Policy​

The default ContentSecurityPolicy is an empty string - no CSP header is sent. CSP is your primary defense against XSS:

app.Use(helmet.New(helmet.Config{
    HSTSMaxAge:            63072000,
    HSTSPreloadEnabled:    true,
    ContentSecurityPolicy: "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'",
}))

Start strict and loosen as needed. default-src 'self' blocks everything from external sources by default. You add exceptions for what your app actually needs.

What You Get for Free​

The defaults do include useful protections:

• X-Content-Type-Options: nosniff - prevents MIME sniffing
• X-Frame-Options: SAMEORIGIN - blocks clickjacking
• Referrer-Policy: no-referrer - prevents leaking URLs to third parties
• Cross-Origin-Embedder-Policy: require-corp - isolates your origin
• X-DNS-Prefetch-Control: off - prevents DNS prefetching leaks

These are solid defaults. Do not change them unless you have a specific reason.

CORS: The Wildcard Trap​

The default CORS configuration allows all origins with AllowOrigins: []string{"*"}. For a public API with no authentication, that might be fine. For anything with cookies, sessions, or tokens, it is a security hole.

For an API with Authentication​

app.Use(cors.New(cors.Config{
    AllowOrigins:     []string{"https://app.example.com", "https://admin.example.com"},
    AllowMethods:     []string{"GET", "POST", "PUT", "DELETE"},
    AllowHeaders:     []string{"Origin", "Content-Type", "Accept", "Authorization", "X-Csrf-Token"},
    AllowCredentials: true,
    MaxAge:           3600,
}))

Key points:

• AllowOrigins lists the exact domains that need access. No wildcards when using credentials.
• AllowHeaders must include X-Csrf-Token if you are using CSRF with header extraction.
• AllowCredentials is true because your frontend sends cookies.
• MaxAge is 3600 (1 hour) so browsers cache preflight results instead of making an OPTIONS request before every POST.

The Wildcard + Credentials Panic​

If you try to set AllowOrigins: []string{"*"} with AllowCredentials: true, Fiber will panic at startup. This is intentional - the combination would let any website make authenticated requests to your API.

Subdomain Patterns​

For apps with multiple subdomains:

AllowOrigins: []string{"https://*.example.com"},

This matches app.example.com, admin.example.com, and even deep.nested.example.com. Use this when you control the parent domain.

CSRF: The Cookie Nobody Configures​

The default CSRF configuration works for development but is insecure in production. The cookie is not marked as secure, not scoped to HTTPS, and uses a generic name.

Production Configuration for SPAs​

app.Use(csrf.New(csrf.Config{
    CookieName:        "__Host-csrf_",
    CookieSecure:      true,
    CookieHTTPOnly:    false, // SPAs need JavaScript access
    CookieSameSite:    "Lax",
    CookieSessionOnly: true,
    Extractor:         extractors.FromHeader("X-Csrf-Token"),
}))

Why these settings:

• __Host- prefix: Browsers enforce that __Host- cookies are secure, have no domain, and have a path of /. This prevents cookie injection attacks.
• CookieSecure: true: The cookie is only sent over HTTPS.
• CookieHTTPOnly: false: Your JavaScript needs to read the cookie to send the token in a header. This is the necessary trade-off for SPAs.
• CookieSameSite: "Lax": The cookie is sent with top-level navigations but not with cross-site requests. This is the baseline CSRF protection.
• Extractor from header: The CSRF token comes from the X-Csrf-Token header, not from the cookie itself. This is the Double Submit Cookie pattern.

Production Configuration for Server-Rendered Apps​

app.Use(csrf.New(csrf.Config{
    CookieName:        "__Host-csrf_",
    CookieSecure:      true,
    CookieHTTPOnly:    true, // No JavaScript access needed
    CookieSameSite:    "Lax",
    CookieSessionOnly: true,
    Extractor:         extractors.FromForm("_csrf"),
    Session:           sessionStore, // More secure with sessions
}))

For server-rendered apps, the token goes in a hidden form field, so CookieHTTPOnly: true is correct - JavaScript should not need the token.

The Complete Stack​

Here is the full security middleware stack for a typical SPA backend:

import (
    "github.com/gofiber/fiber/v3"
    "github.com/gofiber/fiber/v3/extractors"
    "github.com/gofiber/fiber/v3/middleware/cors"
    "github.com/gofiber/fiber/v3/middleware/csrf"
    "github.com/gofiber/fiber/v3/middleware/helmet"
)

app := fiber.New()

// Security headers
app.Use(helmet.New(helmet.Config{
    HSTSMaxAge:            63072000,
    HSTSPreloadEnabled:    true,
    ContentSecurityPolicy: "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'",
}))

// CORS
app.Use(cors.New(cors.Config{
    AllowOrigins:     []string{"https://app.example.com"},
    AllowMethods:     []string{"GET", "POST", "PUT", "DELETE"},
    AllowHeaders:     []string{"Origin", "Content-Type", "Accept", "Authorization", "X-Csrf-Token"},
    AllowCredentials: true,
    MaxAge:           3600,
}))

// CSRF
app.Use(csrf.New(csrf.Config{
    CookieName:        "__Host-csrf_",
    CookieSecure:      true,
    CookieHTTPOnly:    false,
    CookieSameSite:    "Lax",
    CookieSessionOnly: true,
    Extractor:         extractors.FromHeader("X-Csrf-Token"),
}))