[cbrnrd]

Adds Setting Up Sourcegraph Securely at /admin/security, a checklist of the settings that harden a Sourcegraph instance and what each one protects against. The page is linked from the Administration sidebar and the admin index.

Closes SEC-4425.

What the page covers

• Before exposing the instance: create the first admin right away (the first sign-up always becomes site admin), HTTPS only, and an https:// externalURL (it sets the session cookie's Secure flag).
• Sign-in: SSO, removing builtin or setting allowSignup: false, auth.accessRequest, organization invitations and organizationInvitations.signingKey, per-provider sign-up limits, OIDC requireEmailVerified (with the Microsoft Entra ID incompatibility), SCIM, auth.enableUsernameChanges, and password and lockout settings.
• Sessions and tokens: auth.sessionExpiry, auth.maxSessionIdleDuration, auth.accessTokens, srcCli.allowAccessTokenAuth, service accounts, and OAuth apps.
• Network: auth.allowedIpAddress (example config and caveats), corsOrigin, auth.allowEmbeddedAuth, outbound filtering, and tls.external.
• Code and data: authorization on every code host connection (a new connection enforces no repository permissions), authz.enforceForSiteAdmins, RBAC, encryption.keys, and agent context filters.
• Attack surface and monitoring: unused features and MCP, ENABLE_INJECT_HTML, lsifEnforceAuth, executors, Batch Changes, webhook secrets, audit and security event logs, and updates.

Where another page already covers a setting, this page links there instead of copying it, and it doesn't restate defaults.

How the claims were checked

The settings come from schema/site.schema.json and Deep Search on sourcegraph/sourcegraph. Each enforcement claim was checked against the code on main (f087f16d): the IP allowlist checker, session cookie flags, site init, access token config, the SCIP upload auth middleware, OIDC email verification, and org invitations.

Discrepancies found along the way (not fixed here)

• IP allowlist header: the schema says userIpRequestHeaders uses the right-most address, but checker.go takes the first (left-most), client-controlled one. If the proxy appends to X-Forwarded-For, the allowlist can be bypassed. The page describes the actual behavior and tells admins to have the proxy replace the header.
• Access token expiration: cli/how-tos/managing-access-tokens.mdx says allowNoExpiration defaults to false, but AccessTokensAllowNoExpiration() returns true when it's unset. The page tells admins to set it to false explicitly.
• Organization invitations: with no organizationInvitations.signingKey, invitation JWTs are signed with an empty HMAC key, and no setting turns invitations off.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
sourcegraph-docs	Ready	Preview	Nov 11, 2026 12:35pm UTC

[github-actions]

Open the Diff Tour for this PR in Sourcegraph

[github-actions]

Page	Before	After	Diff
/admin	prod	preview	+1
/admin/security 🆕	—	preview	+115

[andreeleuterio]

im pretty sure this happens automatically. For cloud instance creation you need to pass an admin's email and for on-prem, upon setup the first page points to creating an account before the instance being useful

[marcleblanc2]

Cloud yes, self-hosted no, however, the risk for self-hosted is if someone else grabs the initial admin account, the self-hosted admin can just delete the database, redeploy, and catch it faster next time.

[marcleblanc2]

Sign-in: SSO, removing builtin

We could have more in-product encouragement to configure a non-builtin auth provider, and disable builtin auth, as I don't believe we do things like rate limiting to slow down credential stuffing, and may not have consistent response times to prevent timing attacks, etc., on our builtin auth provider. We could also strengthen the builtin auth provider with MFA, passkeys, TOTP authenticator app codes, etc.

... especially for our Cloud customers whose builtin auth login page is open to the whole internet...

[cbrnrd]

Sign-in: SSO, removing builtin

We could have more in-product encouragement to configure a non-builtin auth provider, and disable builtin auth, as I don't believe we do things like rate limiting to slow down credential stuffing, and may not have consistent response times to prevent timing attacks, etc., on our builtin auth provider. We could also strengthen the builtin auth provider with MFA, passkeys, TOTP authenticator app codes, etc.

... especially for our Cloud customers whose builtin auth login page is open to the whole internet...

i agree! but that's way beyond the scope of this PR. Would be a good discussion in #discuss-services - you would definitely have my support.

[bobheadxi]

Curious - why does this need to be a separate "secure setup" page? Is there a reason we would want to recommend a non-secure setup? Should this just be incorporated into our default setup guidance paths?

cc @taras-yemets

[marcleblanc2]

Nits on phrasing:

or turn off self sign-up.
If you keep builtin, set allowSignup to false on it explicitly,

Self-registration (allowSignup) is default off for the builtin auth provider. To be added for followups: open PRs to add clearer warnings in the product and docs, and reconsider default values and "suggested" values (what pops up when someone adds the config to their site config). I can help with these.

so that no local passwords exist

They still exist, just can't be used to log in again until the builtin provider is later re-enabled (eg. break glass recovery when the SSO provider borks).

[marcleblanc2]

Curious - why does this need to be a separate "secure setup" page? Is there a reason we would want to recommend a non-secure setup? Should this just be incorporated into our default setup guidance paths?

@bobheadxi I do think this page is needed, it's questions our large enterprise customers have. The reality is, most software comes with middle-of-the-road / sensible / average defaults, including ours, but has knobs that security-sensitive customers need to know and use, so collecting them in a single link I can send to a customer is something I've asked for in the past.

If anything, I'd suggest the deployment / configuration security guidance page in the doc site should be the home for these facts, and other pages link to it.

We should also follow this up with some PRs to reconsider default values, "suggested" values (the first value which prefills when an admin adds the config to their site config), and provide sufficient warning and visibility when customers make compromising decisions.