security: harden CSRF Origin check and CORS credentials handling (#5, #16)

[lakhansamani]

Summary

Two related issues:

#5 — CSRF bypass with wildcard AllowedOrigins
The CSRF middleware called validators.IsValidOrigin to check the Origin header, but IsValidOrigin returns true for ANY origin when AllowedOrigins == ["*"] (the default). It also skipped the check entirely when Origin was missing, accepting an X-Requested-With trick. Combined, an attacker could send a state-changing POST from a malicious page without Origin and pass.

#16 — CORS wildcard with credentials
The CORS middleware already correctly avoids setting Access-Control-Allow-Credentials when origin is * or empty, so credentialed cross-origin requests aren't actually permitted in wildcard mode. Operators can still misread the default as "credentialed wildcard works" and rely on it.

Changes

• CSRF: require Origin OR Referer on every state-changing method. Reject with 403 Origin or Referer header is required if both are missing.
• New csrfOriginAllowed() validates the origin. When AllowedOrigins == ["*"], it falls back to same-origin enforcement (origin host must equal request host) — wildcard CORS does not mean wildcard CSRF. With an explicit allowlist it defers to IsValidOrigin.
• The custom-header check (application/json or X-Requested-With) is still required as a second layer.
• CORS: log a clear startup warning when AllowedOrigins contains * recommending an explicit allowlist for production.

Test plan

• go build ./...
• TEST_DBS=sqlite go test ./internal/integration_tests/
• Manual: POST without Origin/Referer is rejected
• Manual: POST with Origin matching Host (wildcard mode) is accepted
• Manual: POST with foreign Origin (wildcard mode) is rejected