Separate public and private values
A few moving parts are involved here. The points below cover each of them, so you can see the full scope before deciding where to start.
- Public: project URL, publishable client key and non-sensitive feature flags.
- Private: service keys, email credentials, payment secrets and webhook signing keys.
- Server boundary: edge function or trusted backend that validates the caller and provider response.
With the boundary clear, connect the integration using the steps below.
- Define the exact data the client needs.
- Store private credentials in the platform secret manager.
- Create a function with input validation and an allowlisted operation.
- Return only the minimum response needed by the UI.
- Log failures without recording secrets or sensitive payloads.
- Rotate a key if it has ever been exposed in client code or version history.
Obfuscation is not security. If a browser can read a value, treat it as public.
Security review checklist
This comes down to a handful of concrete details. Work through the list below and flag the ones you have not covered yet.
- No private key appears in client-side bundles or version control history.
- Edge functions validate the caller before performing a privileged action.
- Rate limiting exists on functions that call paid or limited external APIs.
- Error responses do not leak provider error details to the client.
- Secrets are named clearly enough for another developer to understand their purpose.
When to rotate a key immediately
Use the list below as a working checklist. Each item is something you can verify or action directly on your own site.
- It was ever committed to a public or shared repository.
- It appeared in a client-side network request or console log.
- A team member with access has left or lost their device.