Credential and Environment Rules
Where each kind of secret may live, and what to do when one is exposed. These rules have no exceptions — the cost of exposure is asymmetric and you cannot tell the harmless cases from the catastrophic ones in advance.
Syntax
implementor-onboarding
THE TEST
Not "is this sensitive?" — you will talk yourself into an exception.
"If this string were printed on the tenant's homepage, what could
someone do with it?" Anything at all -> not client-side.Parameters
| Parameter | Type | Description |
|---|---|---|
| publishable / anon client key | client-exposed | Designed for the browser. Safe in a client-exposed variable. |
| service-role / admin key | server-side only | Never client-exposed, under any circumstances, including behind a login. |
| third-party API keys | server-side only | Payments, AI providers, mail. Server-side or edge function only. |
| database connection string | server-side only | Server-side only. |
| local | environment | Your machine. Disposable. The only place to experiment. |
| preview | environment | A running copy of a proposed change at its own URL. Isolated or scratch data — NEVER pointed at production. |
| production | environment | Real customers, real records. Isolation from the others is structural, not procedural. |
Example
implementor-onboarding
A client-exposed environment variable is COMPILED INTO THE BUNDLE
any visitor can read. It is not hidden, not obfuscated, and not
protected by the page requiring a login. It is a string in a public
file.
Access control check, on Postgres:
Row-level policies can be defined on a table that does NOT have
row-level security enabled. The policies are then inert, and the
policy list tells you nothing about enforcement.
Check the table's actual state. Then confirm behaviourally: read
it with a client key that should see nothing, and see nothing.