feat(security): set X-Content-Type-Options: nosniff by default

[SAY-5]

Summary

Fixes #37316.

Gitea already sends X-Frame-Options: SAMEORIGIN on HTML responses by default but never emits X-Content-Type-Options. Without that header, browsers fall back to content sniffing and can execute user-uploaded files as scripts when the Content-Type is missing or ambiguous. Per every modern hardening guide (OWASP, MDN, Mozilla Observatory), nosniff is the correct default.

Fix

• Security.XContentTypeOptions setting, defaulting to "nosniff".
• Emit the header from services/context alongside X-Frame-Options if the configured value is not "unset".
• Expose X_CONTENT_TYPE_OPTIONS in [security] of app.example.ini.

unset removes the header, matching the existing X_FRAME_OPTIONS escape hatch for operators who want the raw HTTP behaviour.

Test plan

• go build ./modules/setting/... ./services/context/... clean
• go vet ./modules/setting/... ./services/context/... clean
• go test ./modules/setting/... green
• Manual: hit any Gitea page with curl -I and confirm X-Content-Type-Options: nosniff is in the response by default; set X_CONTENT_TYPE_OPTIONS = unset in [security] and confirm it's absent.

No behaviour change for operators who already set their own response header via a reverse proxy — the nosniff value is a safe no-op when upstream sets the same header.

[silverwind]

Fixup done in 4ca393d.

• Clarify that both security headers are for web ui responses only, API does not set them
• Add a test that validates both

[silverwind]

Note that API responses already set this header in https://github.com/go-gitea/gitea/blob/main/routers/api/v1/api.go#L1749, so this change fills the gap for web router responses.

The following endpoints still don't set it after this change:

/api/internal/*
/api/healthz
/captcha/*
/metrics
/robots.txt
/ssh_info

I don't see why not set this header on all responses without exceptions, maybe it should be refactored to really apply globally, so maybe we should move this securityHeaders to a true global middleware.

[wxiaoguang]

I don't see why not set this header on all responses without exceptions

Because your code was only added to "web" middlewares.

[silverwind]

Doing it on web routes is an improvement, no doubt. But such a header ideally wants to be configured on all routes without exceptions.

[wxiaoguang]

See ProtocolMiddlewares

[wxiaoguang]

Well, Your AI already used that middleware: handlers = append(handlers, public.ViteDevMiddleware)

[SAY-5]

Thanks @wxiaoguang — lifted the handler into routers/common.SecurityHeadersHandler and registered it from ProtocolMiddlewares alongside ChiRoutePathHandler / RequestContextHandler / public.ViteDevMiddleware, so X-Content-Type-Options now covers every endpoint (including the /api/internal/*, /captcha/*, /metrics, /robots.txt, /ssh_info gaps @silverwind listed). Removed the now-redundant X-Content-Type-Options Set in services/context/context.go and the private securityHeaders() wrapper in routers/api/v1/api.go. X-Frame-Options stays in the web-UI middleware since it's clickjacking-specific.

go build ./routers/... ./services/... and go test -tags 'sqlite sqlite_unlock_notify' ./routers/common/... green locally.

[silverwind]

Acceptable. Sending XFO on every request is a bit of a waste because it only works on renderable content like HTML or SVG, but acceptable. The alternative of trying to detect what is renderable would be hacky and worse.

[wxiaoguang]

@SAY-5 Thank you for your PR, but please discuss the issues by human. https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md#ai-contribution-policy

[silverwind]

It's fine to post AI responses to PRs but those should always be paired with an actual human response too.

@wxiaoguang approve first.

[wxiaoguang]

@wxiaoguang approve first.

Oops, forgot. Approved.

[silverwind]

Docs PR: https://gitea.com/gitea/docs/pulls/389