Secure Defaults - go-security

go-security is secure by default. securityhttp is designed so that adding features cannot accidentally remove security, and misconfiguration causes a build-time error rather than a runtime vulnerability.

What is always on

Every chain built with securityhttp.New() includes:

Security headers

Written on every response:

Header	Default value
`X-Content-Type-Options`	`nosniff`
`X-Frame-Options`	`DENY`
`Referrer-Policy`	`no-referrer`

These are conservative, broadly-compatible defaults chosen to block MIME sniffing, clickjacking, and referrer leakage without requiring any configuration.

Session cookies

When SessionStore is configured, the session cookie is:

Set-Cookie: SESSION=...; Path=/; Secure; HttpOnly; SameSite=Lax

Secure — transmitted only over HTTPS (set to false for localhost dev only)
HttpOnly — inaccessible to JavaScript
SameSite=Lax — blocks cross-site POST forgery while allowing top-level navigations

CSRF protection

On once SessionStore is set. The default strategy is the synchronizer token (session-backed). An X-CSRF-Token header is required for all unsafe methods (POST, PUT, PATCH, DELETE). The double-submit cookie strategy (csrf.NewDoubleSubmitRepository) is also available when a session does not yet exist (e.g. the login endpoint itself):

securityhttp.New(
    securityhttp.WithCSRF(csrf.NewDoubleSubmitRepository(csrfCookie)),
)

Default-deny authorization

Build() errors if your route set has no AnyRequest() rule and AllowUnmatched() was not called. This prevents accidental fail-open configurations.

Opting out

You can only opt out of CSRF explicitly, and only for bearer-token APIs:

securityhttp.New(securityhttp.CSRFDisabled())

Combining Login() with CSRFDisabled() is a login-CSRF risk: an attacker can silently log a victim into an attacker-controlled account. New() errors on this pair unless you also call AllowLoginWithoutCSRF() — which is only for deployments that enforce CSRF at another layer (e.g. an edge gateway).

Errors on misconfiguration

New() / NewHandler() never return a half-configured chain. They return an error for:

WithLogin() without a WithSessionStore()
WithLogin() + CSRFDisabled() without AllowLoginWithoutCSRF()
WithAuthorize() with no AnyRequest() and no AllowUnmatched()
Invalid CORS configuration (credentials + wildcard origin)

Middleware ordering

The secure-correct fixed order is:

SecurityHeaders
  CORS
    RateLimit
      SessionAuthentication
        Anonymous
          CSRF
            Authorization
              Your handler (with login mounted inside)

Session resolution before CSRF ensures the session-backed synchronizer token can always be found. This ordering is not configurable — changing it would introduce security gaps.

HTTPS in production

Set Secure: true on your cookie config (the default) and enable HSTS:

securityhttp.New(
    securityhttp.WithHeaders(
        middleware.WithHSTS(
            31536000, // max-age: 1 year
            true,     // includeSubDomains
            true,     // preload
        ),
    ),
)

HSTS is off by default because it is only meaningful over TLS. Enable it when you serve HTTPS in production.

​What is always on

​Security headers

​Session cookies

​CSRF protection

​Default-deny authorization

​Opting out

​Errors on misconfiguration

​Middleware ordering

​HTTPS in production