redact-secret · Report

Project secret key

Project-scoped secret API key, prefixed sb_secret_.

Supabase
Detectors: supabase-token
Run 2026-10-07
Mode published · redact-secret 0.1.0-beta.14

Dossier verdictReady
Dossier evidence levelT1 · Provider-documented
Dossier researched2026-09-24

supabase-token's contract is T1 since #207 (research #231): Supabase's self-hosting page documents sb_secret_ + 22-character random part + _ + 8-character checksum and says hosted keys use the same format; the base64url alphabet and the sha256 checksum are provider code only. The older 40-alphanumeric detector-coverage positives predate that grammar and are retained as policy regressions.

New pipelineAuthority

Built from the new pipeline

The new pipeline is the authority for credential qualification. These numbers are read from the qualification view derived from the official credential-eval run of the public-evidence-snapshot population. The regression and policy populations keep their own counts on the qualification pages and are not added in here.

Authority: new
Population: public-evidence-snapshot
Engine: credential-eval 0.1.0-alpha.16
Evidence: snapshot-2026.10.06.4
Run: sha256:4bec6e539482…
Recorded: 2026-10-07
Authorised for: @redact-secret/core@0.1.0-beta.14

Maintainer-reviewed (independent review pending)

598 fixtures of the 7,041 in evidence release snapshot-2026.10.06.4 carry this label. They are counted in the numbers on this page.

Passed the project’s own verification (source evidence, automated checks, recorded counter-arguments); not yet independently reviewed.

OpenRedaction default (all patterns): not measured in this run (optional)

The default (all-pattern) profile is slow and noisy for credential evaluation: personal data and resource identifiers dominate its findings, and its last official measurement took 7 minutes of scanner time on a population the credential profile scans in seconds (its methods run takes 40+ minutes), so it is a manual measurement and never blocks other scanners or core verification (#763). Its earlier results stay as history with their run identity; the credential profile is a separate scanner, never spliced with it.

Last measurement: policy-corpus@linux-x64 (configuration sha256:2451ce7bf380), public-evidence-snapshot+methods@linux-x64 (configuration sha256:d47d081ce5fb), public-evidence-snapshot@linux-x64 (configuration sha256:2451ce7bf380), regression-corpus@linux-x64 (configuration sha256:2451ce7bf380) · engine 0.1.0-alpha.5 · recorded 2026-10-05 · retained record, no longer listed by the run registry. It stays labelled with that run identity and is never combined with another profile or another run.

Open the qualification page for this pointer

OpenRedaction credential profile (33 types): not measured in an official run (local exploratory diagnostics only: see ADR)

The credential profile is the comparison profile chosen in docs/decisions/2026-10-06-choose-the-openredaction-credential-bearing-profile-as-the-comparison-scanner.md. It is optional in the official run class because no pinned engine configuration measures it yet: making it required would refuse every official view until the owner approves the one profile-only run. Its own history starts with that run; nothing of the default's is reused for it.

No earlier measurement of it is recorded. Nothing is shown in its place.

Official measurement: pending: requires owner approval (one profile-only run; see the decision).

Open the qualification page for this pointer

Every population and its qualification

Research record

From credential-evidence snapshot-2026.10.06.4 · records at 77ce761 · schema 1.8.0. It describes the research on the format, not what any scanner or the product does, and not a support status.

Review stateDraft, not reviewed
Format revision1 · current
ResearchResearched
Researched2026-09-24

4 events in the review history: 3 observed, 1 reviewed. Latest: observed on 2026-10-04 by automation, project maintainer. Project-maintained review is not independent validation. The family record at this release.

Format

Provider format research from credential-evidence snapshot-2026.10.06.4 · records at 77ce761 · schema 1.8.0.

What it looks like

Descriptive pattern: ^sb_secret_[A-Za-z0-9_-]{22}_[A-Za-z0-9_-]{8}$

Parts are shown as recorded. Evidence classes belong to the facts below; no class is assigned to a part.

Format facts

Provider documented · provider-source · current · observed 2026-09-24
opaque key: sb_secret_ + 22-character random part + _ + 8-character checksum: the self-hosting page states that opaque keys are sb_secret_<22-char-random>_<8-char-checksum> and "use the same format as the platform", and supabase.com/docs/guides/api/api-keys documents the sb_secret_ prefix and sb_publishable_ as "safe to expose online"; the base64url body alphabet and the sha256 checksum construction are provider code (supabase/supabase docker/utils/add-new-auth-keys.sh), not documentation, and the hosted checksum input is unconfirmed
- supabase.com/docs/guides/self-hosting/self-hosted-auth-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports the self-hosting page states that opaque keys are sb_secret_<22-char-random>_<8-char-checksum> and "use the same format as the platform", and supabase.com/docs/guides/api/api-keys documents the sb_secret_ prefix and sb_publishable_ as "safe to expose online"; the base64url body alphabet and the sha256 checksum construction are provider code (supabase/supabase docker/utils/add-new-auth-keys.sh), not documentation, and the hosted checksum input is unconfirmed
Provider documented · field-prefix · current · observed 2026-09-24
prefix: sb_secret_ (secret); sb_publishable_ is the documented public sibling, "safe to expose online"
- supabase.com/docs/guides/api/api-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports prefix: sb_secret_ (secret); sb_publishable_ is the documented public sibling, "safe to expose online"
Provider documented · field-segment-layout · current · observed 2026-09-24
segment layout: 22-character random part, a literal _, then an 8-character checksum (31-character body, 41 characters in total) (Hosted-platform scope rests on the self-hosting page's "same format as the platform" sentence; a hands-on hosted issuance (#231 checklist) is corroboration, not a blocker.)
- supabase.com/docs/guides/self-hosting/self-hosted-auth-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports States the layout for self-hosted keys and that they "use the same format as the platform"; the hosted-platform page states no body grammar.
Provider documented · field-body-alphabet · current · observed 2026-09-24
body alphabet: base64url [A-Za-z0-9_-] in both segments, so _ and - can occur inside the random and checksum parts; only the _ at body offset 22 is structural
- supabase/cli @ a09ff6cf59e89fae5c92458c7b838a09b9a9d777: apps/cli-go/pkg/config/apikeys.goprovider-sdk-source · last read 2026-10-04 · latest outcome unchanged · supports local-dev constants measured 22/_/8 (shape only, never used as a fixture)
- supabase/supabase @ master: docker/utils/add-new-auth-keys.shprovider-sdk-source · last read 2026-09-24 · latest outcome read · supports crypto.randomBytes(17).toString("base64url").slice(0,22)
Provider documented · field-checksum · current · observed 2026-09-24
checksum: first 8 base64url characters of sha256(<project ref> + "|" + prefix + random); the self-hosted gateway does not validate it (Fixtures compute it over a synthetic project ref; it is not part of the lexical pattern, so no checksum-only twin is scored.)
- supabase/supabase @ master: docker/utils/add-new-auth-keys.shprovider-sdk-source · last read 2026-09-24 · latest outcome read · supports checksum: first 8 base64url characters of sha256(<project ref> + "|" + prefix + random); the self-hosted gateway does not validate it
- supabase.com/docs/guides/self-hosting/self-hosted-auth-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Section 'Differences from the Supabase platform', item 'No checksum validation': the API gateway does not validate the checksum (self-hosted only).
Provider documented · field-selfhosted-checksum-not-validated · current · observed 2026-10-04
The self-hosted API gateway does not validate the embedded checksum: the self-hosting page states that the opaque keys use the same format as the platform (sb_publishable_<random>_<checksum>) but that the gateway does not validate the checksum and matches keys as opaque strings. The page says nothing about validation on the hosted platform.
- supabase.com/docs/guides/self-hosting/self-hosted-auth-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Section 'Differences from the Supabase platform', item 'No checksum validation': the opaque keys use the same format as the platform, but the API gateway does not validate the checksum; keys are matched as opaque strings.
Provider documented · field-platform-multiple-secret-keys · current · observed 2026-10-04
The hosted platform allows creating multiple sb_ keys per project, while self-hosted Supabase supports a single sb_secret and a single sb_publishable.
- supabase.com/docs/guides/self-hosting/self-hosted-auth-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Section 'Differences from the Supabase platform', item 'One key per role': self-hosted supports a single sb_publishable and a single sb_secret; the platform allows creating multiple sb_ keys per project.
Unresolved · field-hosted-checksum-input · current · observed 2026-09-24
hosted checksum input: whether hosted keys hash the real project ref, and whether the platform validates the checksum
- github.com/redact-secret/redact-secret-benchmarks/issues/231provider-sdk-source · last read 2026-09-24 · latest outcome read · supports hosted checksum input: whether hosted keys hash the real project ref, and whether the platform validates the checksum
Provider documented · field-cli-default-keys-hardcoded · current · observed 2026-10-04
The Supabase CLI source defines a default publishable key and a default secret key as constants in the opaque layout and assigns them, under the comment 'Set hardcoded opaque keys', when the project configuration supplies none; the CLI documentation states that supabase start prints a publishable key and a secret key for the local project. Neither source states whether these values are secrets.
- supabase/cli @ a09ff6cf59e89fae5c92458c7b838a09b9a9d777: apps/cli-go/pkg/config/apikeys.goprovider-sdk-source · last read 2026-10-04 · latest outcome unchanged · supports apps/cli-go/pkg/config/apikeys.go at the pinned commit: constants defaultPublishableKey and defaultSecretKey, assigned in generateAPIKeys under the comment 'Set hardcoded opaque keys' when the configured value is empty (values deliberately not copied).
- supabase.com/docs/guides/api/api-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Section 'Find your keys', Local stack: running supabase start prints a publishable key and a secret key for the local project; the local secret key takes the place of the local service_role key.
Unresolved · field-cli-local-dev-constants · current · observed 2026-09-24
CLI local-dev constants: the Supabase CLI prints publicly known, structurally valid local-dev sb_secret_/sb_publishable_ keys; whether they count as secrets is an open policy question, so no fixture uses them either way
- github.com/redact-secret/redact-secret-benchmarks/issues/231provider-sdk-source · last read 2026-09-24 · latest outcome read · supports CLI local-dev constants: the Supabase CLI prints publicly known, structurally valid local-dev sb_secret_/sb_publishable_ keys; whether they count as secrets is an open policy question, so no fixture uses them either way
Unresolved · listed-references · current · observed 2026-09-24
The legacy contract lists 2 references without stating which property each supports.
- supabase/supabase @ master: docker/utils/add-new-auth-keys.shprovider-sdk-source · last read 2026-09-24 · latest outcome read · supports Listed as a reference by the legacy contract
- supabase.com/docs/guides/api/api-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Listed as a reference by the legacy contract
Provider documented · dossier-research · current · observed 2026-09-24
Legacy dossier research (verdict ready, tier T1) cited 3 sources; the dossier does not attribute sources to individual properties.
- supabase/cli @ a09ff6cf59e89fae5c92458c7b838a09b9a9d777: apps/cli-go/pkg/config/apikeys.goprovider-sdk-source · last read 2026-10-04 · latest outcome unchanged · supports Cited by the legacy dossier research for this family
- supabase.com/docs/guides/api/api-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Cited by the legacy dossier research for this family
- supabase.com/docs/guides/self-hosting/self-hosted-auth-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Cited by the legacy dossier research for this family
Provider documented · taxonomy-sources · current · observed 2026-09-24
The legacy taxonomy lists 2 sources for this family. The taxonomy records no date; the dossier researchedAt is used as the observed-at date.
- supabase.com/docs/guides/api/api-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Listed as a source for this family in the legacy taxonomy
- supabase.com/docs/guides/self-hosting/self-hosted-auth-keysprovider-documentation · last read 2026-10-04 · latest outcome unchanged · supports Listed as a source for this family in the legacy taxonomy

Open questions

No open question is recorded for this revision.

Benchmark dossier notes

From the provider dossier, as written. The evidence level above says how well the format is backed; a fact the dossier does not record is not shown.

Shape: prefix sb_secret_, then a 22-character random part, _, and an 8-character checksum (31 characters after the prefix, 41 in total). The self-hosting page states this and says hosted keys use the same format. The base64url alphabet and a SHA-256 checksum construction come from provider code only (the self-hosting script and CLI defaults), so _ and - can appear inside the segments and only the underscore at body offset 22 is structural. The hosted checksum input is unresolved; the self-hosted gateway does not validate it.
Basis: T1 (provider documentation plus the CLI source at the permalink above, which yields local-dev sample keys with the 22/8 layout; those are public and are not to be reused as fixtures). Docs also state the secret is a short string, not a JWT, and can be revealed again through the Management API (reveal=true).
Issuance: not attempted. Multiple secret keys are allowed; the Management API prefix and hash field forms were not observed.
Contract in core: detector-families.md (T1 layout row, checked by position; the tightening followed #742).

In this benchmark

Fixture rows on the current run. Counts are for redact-secret in published · redact-secret 0.1.0-beta.14 mode.

Fixtures: 30
Left readable: 0
Redacted too much: 0
False alarms: 0

30 fixtures: 11 expect a redaction, 19 must stay quiet. See every row

redact-secret fixture counts by evidence level
Evidence level	Fixtures	Left readable	Too much	False alarms
T1Provider-documented	13	0	0	0
T2Tool-corroborated	10	0	0	0
T3Project policy	7	0	0	0

Every scanner on the same fixtures

In run order. Counts are what each scanner recorded on this family's fixtures, whichever rules it has; a scanner with no rule for the family has nothing to report on it.

Counts per scanner on this family's fixtures
Scanner	Fixtures	Left readable	False alarms
flare-redactRuntime library · 1.6.1 · Published npm package · secrets-only (pii, generic_assignment disabled) · JavaScript engineNo rule maps to it	30	11	0
gitleaksRepository scanner · 8.30.1 · Directory scan · default rulesNo rule maps to it	30	5	2
redact-secretProduct measured here · 0.1.0-beta.14 · Published npm package · default detectors1 detector mapped	30	0	0
trufflehogRepository scanner · 3.97.4 · Filesystem scan · verification disabledNo rule maps to it	30	11	0

Benchmark dossier questions

Things the sources do not settle. They are listed so nobody reads them as settled.

Open caveat: The 22 + _ + 8 layout is stated on the self-hosting page ("same format as the platform"); the hosted checksum algorithm and input are unresolved, so the checksum value is not asserted.

Looks like it, but isn't

Values the dossier records as resembling this credential without being one.

Collisions: sb_publishable_ keys are documented safe to expose and are the primary benign control. Legacy anon and service_role JWTs start eyJ; hosted ones carry iss supabase, the CLI's local ones supabase-demo. Earlier positives with 40 alphanumerics predate the grammar. Secrets are auto-revoked when pushed to public GitHub repositories (provider statement).

Scanner rules for this family

Mapped by hand (reviewed 2026-09-30) from each scanner's pinned rule file, never from what a scanner found on the fixtures.

No peer rule maps to this family

None of the reviewed peer scanners has a rule that can match a credential of this family.

None mapped

Find

Evidence level

Scanners

30 of 30 rows

Fixtures in this family

30 rows, redact-secret's outcome on each. Rows that need a look come first (0), then the rest in corpus order. Choose "Every scanner" to see each scanner's outcome for the same rows.

Fixtures in Project secret key
Fixture	Kind and evidence	redact-secret
`supabase-token-actions-env`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-apikey-header`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-create-client`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-edge-keys-json`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-env`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-long-checksum-twin`supabase · wrong-length	Must not flagT2 · Tool-corroborated · twin	Quiet
`supabase-token-publishable-key-public-id`supabase · public-identifier	Must not flagT2 · Tool-corroborated	Quiet
`supabase-token-self-hosted-compose`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-shape-1-bare`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-shape-1-quoted`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-shape-1-unicode-crlf`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-shell-export`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-status-env`supabase · documented-format-literal	Must redactT1 · Provider-documented	Redacted
`supabase-token-actions-secret-reference`supabase · templated-reference	Must not flagT3 · Project policy	Quiet
`supabase-token-dash-delimiter-twin`supabase · boundary-violation	Must not flagT2 · Tool-corroborated · twin	Quiet
`supabase-token-docs-ellipsis-placeholder`supabase · documentation-placeholder	Must not flagT3 · Project policy	Quiet
`supabase-token-key-hash-encoded-value`supabase · benign-encoded-value	Must not flagT2 · Tool-corroborated	Quiet
`supabase-token-label-prose`supabase · benign-lookalike	Must not flagT3 · Project policy	Quiet
`supabase-token-logged-six-characters-placeholder`supabase · documentation-placeholder	Must not flagT3 · Project policy	Quiet
`supabase-token-mask`supabase · benign-lookalike	Must not flagT3 · Project policy	Quiet
`supabase-token-plural-prefix-near-miss`supabase · format-near-miss	Must not flagT2 · Tool-corroborated	Quiet
`supabase-token-prefix-only`supabase · benign-lookalike	Must not flagT2 · Tool-corroborated	Quiet
`supabase-token-project-url-public-id`supabase · public-identifier	Must not flagT2 · Tool-corroborated	Quiet
`supabase-token-publishable-prefix-sdk-twin`supabase · public-sibling-prefix	Must not flagT1 · Provider-documented · twin	Quiet
`supabase-token-publishable-prefix-twin`supabase · public-sibling-prefix	Must not flagT1 · Provider-documented · twin	Quiet
`supabase-token-reference`supabase · benign-lookalike	Must not flagT3 · Project policy	Quiet
`supabase-token-rotation-note-prose`supabase · prose-mention	Must not flagT3 · Project policy	Quiet
`supabase-token-short-body`supabase · benign-lookalike	Must not flagT2 · Tool-corroborated	Quiet
`supabase-token-short-random-twin`supabase · wrong-length	Must not flagT2 · Tool-corroborated · twin	Quiet
`supabase-token-unprefixed-body-near-miss`supabase · format-near-miss	Must not flagT2 · Tool-corroborated	Quiet

Sources

Researched 2026-09-24.

Documentation and code

supabase.com/docs/guides/api/api-keys
supabase.com/docs/guides/self-hosting/self-hosted-auth-keys
github.com/supabase/cli/blob/a09ff6cf59e89fae5c92458c7b838a09b9a9d777/apps/cli-go/pkg/config/apikeys.go

Research log

redact-secret/redact-secret-benchmarks#231Research issue
redact-secret/redact-secret#742Research issue
redact-secret/redact-secret#515Research issue

Other Supabase families

Personal access token