Keep secrets and configuration safe
Know which settings are public and which credentials must stay on the server.
By the end, you can spot a leaked secret and explain a safe replacement.
Step 1: Distinguish address from safe key
A visitor may know a shop’s address, but never its safe combination. Some app settings are deliberately public, such as a Supabase project URL and publishable key. Private provider credentials and Supabase service- keys must not be sent to visitors.
Step 2: Trace what the browser receives
An supplies configuration when an app builds or runs; being in .env does not make it secret. In Next.js, NEXT_PUBLIC_ values are bundled for the browser. Renaming, hiding, or encoding a private key does not protect it if the browser still receives the value.
Step 3: Keep privileged calls behind a data gate
The browser sends a limited to a trusted server function. That function verifies identity and permission, uses the private key, and returns only allowed fields. Database policies still need ordinary-account tests; a server or administrator account is not proof that users are isolated.
Step 4: Recover from exposure
If a private key was shipped, revoke or rotate it and inspect how its replacement is used. Remove exposed usage from code and deployments; deleting one current line does not recall earlier copies. Account recovery should use the provider’s short-lived, single-use flow; do not share reusable reset links or raw tokens in support chats.
List names and where their values are used without printing values. Identify intentionally public settings and private credentials. For any browser-exposed private key, propose rotation and a server-only call path. Verify ordinary-user data permissions and do not copy secrets into logs or screenshots. Illustrative before / after (behavior, not ready-to-run code): - Browser → private provider key → charge + Browser → verified server → provider; browser receives outcome only
A public identifier is not the same as a private credential. Appropriate permissions still matter even when the key is intended for the browser.
Picture it, then try it
Test the locker with ordinary keys
Each private note is a locker. An administrator's master key opening it says nothing about whether a visitor's key works correctly.
Private-note test Expected A reads A allowed A reads or edits B denied A assigns owner B denied Signed out reads notes denied
AI shows that is enabled and an administrator can read drafts. What evidence is missing?
Compare your reasoning with the worked answer
Test allowed and denied actions as ordinary A, B, and signed out using fictional . Check inserting a for another owner and changing ownership as well as reading. is the database row-access rule system; the switch alone does not establish correct policies. A page filter cannot protect records already downloaded.
Sources and further reading
The AI shipped a private payment-provider key in a NEXT_PUBLIC_ variable. What should you do?
Choose one answer.