Which keys are safe to ship, which must stay on the server, and the mistakes that leak data or run up bills for every API, client platform, and runtime we support.
Try a different search or filter.
Airtable personal access tokens and OAuth tokens are server-only credentials. Scope each token to the specific bases and scopes it needs, call Airtable from a server or edge proxy, and cache reads because the API allows only 5 requests per second per base.
Algolia search-only API keys are safe in clients, and secured API keys add per-user filters on top. The Admin API key and any key with write ACLs must stay on the server, because they can modify or delete indices.
Anthropic API keys (sk-ant-) are server-only. The SDK only allows browser calls when you opt in with a dangerous direct browser access flag, which exposes the key to visitors. Route Claude calls through a server or edge proxy with workspace spend limits.
Clerk publishable keys (pk_) are meant for frontends, while secret keys (sk_) call the Backend API and must stay server-side. Verify session tokens on the server, and authorize from public or private metadata only, because unsafeMetadata can be edited by the user.
Your Cloudinary cloud name and API key appear in URLs and are not secret, but the API secret signs uploads and admin calls and must stay server-side. Prefer signed uploads generated by your server over open unsigned presets.
Contentful Content Delivery API tokens only read published entries and are lower risk, but Content Preview tokens expose unpublished drafts and Content Management tokens can edit or delete content. Keep preview and management tokens on a server or edge proxy only.
The Firebase web config (including apiKey) is a public identifier, not a secret. Data is protected by Firestore, Realtime Database, and Storage Security Rules plus App Check. Admin SDK service account JSON bypasses rules and must only exist on servers.
GitHub personal access tokens, OAuth tokens, and GitHub App private keys are server-only. Prefer fine-grained tokens or GitHub Apps scoped to specific repositories, and cache responses because unauthenticated requests are limited to 60 per hour.
Google Maps JavaScript and mobile SDK keys must ship to clients, so they are only safe when restricted by HTTP referrer or app signature and limited to specific APIs. Web service calls like Geocoding and Places should use a separate server key behind a proxy.
HubSpot private app access tokens and OAuth tokens are server-only credentials. Grant only the CRM scopes the integration needs, call HubSpot from a server or edge proxy, and validate the X-HubSpot-Signature-v3 header on webhooks.
Intercom access tokens are server-only. The Messenger app ID is public, but without identity verification anyone can claim another user identity. Sign user IDs on your server with the identity verification secret and call the REST API only from trusted code.
Linear personal API keys act as your user across every team and are server-only. Prefer OAuth applications with read-only scopes for integrations, and verify the Linear-Signature header on webhooks before acting on issue events.
Mailchimp Marketing API keys grant access to the whole account and are server-only. Call Mailchimp from a server or edge proxy, use OAuth for apps that connect other users accounts, and return only the subscriber fields your UI needs.
Notion internal integration secrets and OAuth tokens are server-only. An integration can only see pages explicitly shared with it, so share the minimum set, call Notion from a server or edge proxy, and cache responses because the API averages about 3 requests per second.
OpenAI API keys are server-only. Any key shipped in a browser or app can be extracted and used to run up your bill. Call OpenAI from a server or edge proxy, use project-scoped keys with spending limits, and enforce model and token caps on the server.
OpenWeather appid keys are server-only because anyone holding one can consume your call quota. Weather data updates on a schedule of minutes, so proxy requests through a server or edge cache keyed by location instead of calling from every client.
Paddle client-side tokens are built for Paddle.js in the browser, while Paddle API keys and webhook secret keys are server-only. Provision access only after a verified webhook, never from a checkout completion event fired in the browser.
Plaid client IDs, secrets, and item access tokens are server-only. Your server creates a short-lived link_token for Plaid Link, the client returns a public_token, and the server exchanges it for an access_token that is stored encrypted and never sent back to the app.
The PostHog project API key (phc_) is public and can only ingest events. Personal API keys (phx_) can query all analytics data and manage the project, so they are server-only. Avoid sending personal data in event properties.
Resend API keys (re_) are server-only. Create keys with sending access restricted to a single verified domain, send from server or edge code, and verify webhook signatures before trusting delivery events.
For any REST API or internal microservice, credentials belong on a server or edge proxy, not in clients. Use timeouts and retries with backoff, validate any user input that ends up in upstream URLs to prevent SSRF, and return only the fields the client needs.
Salesforce connected app consumer secrets, private keys, and OAuth refresh tokens are server-only. Use a dedicated least-privilege integration user with the OAuth JWT bearer flow for server-to-server calls, and expose only the fields each client actually needs.
SendGrid API keys are server-only. Create restricted keys limited to Mail Send, authenticate your sending domain, and never expose an endpoint that lets callers choose arbitrary recipients or message bodies.
Shopify Storefront API public access tokens are designed for clients and only expose storefront data. Admin API access tokens (shpat_) and app client secrets are server-only. Verify the X-Shopify-Hmac-Sha256 header on every webhook before trusting it.
Only Stripe publishable keys (pk_) may ship to browsers or mobile apps. Secret keys (sk_), restricted keys (rk_), and webhook signing secrets (whsec_) must stay on a server or edge proxy. Amounts, prices, and fulfillment decisions belong on the server, driven by verified webhooks.
The Supabase anon (publishable) key is safe in clients only when Row Level Security is enabled on every exposed table. The service_role (secret) key bypasses RLS entirely and must stay on a server or edge proxy, never in a mobile app, FlutterFlow project, or browser bundle.
Twilio Account SIDs with Auth Tokens or API key secrets are server-only. Client SDKs should receive short-lived Access Tokens minted by your server. Validate X-Twilio-Signature on webhooks and rate limit any endpoint that sends SMS or places calls.
Zendesk API tokens act with full agent permissions and are server-only. Prefer scoped OAuth clients, call Zendesk from a server or edge proxy, and filter out private comments and internal fields before returning tickets to customer portals.
Appsmith datasources keep credentials on the Appsmith server, while JS objects and widget bindings run in the browser. Configure secrets in datasources, never in JS code, and use least-privilege accounts for each connected database or API.
Astro renders on the server or at build time, so secrets are safe in frontmatter and server endpoints, but PUBLIC_ variables and anything passed to hydrated islands reach the browser. Use astro:env secret fields and avoid set:html on untrusted content.
Bubble API Connector fields marked Private are kept on Bubble servers, but unmarked values can reach the browser. Set privacy rules on every data type, require authentication on backend workflow endpoints, and proxy calls that need complex secret handling.
FlutterFlow API calls run inside the compiled app by default, so headers and keys in API call definitions ship to every device. Mark sensitive calls private so they run on a backend, or call an edge proxy, and use Supabase or Firebase only with row-level rules.
Framer code components and overrides are compiled into the published site and run in visitors browsers. Any key in that code is public. Fetch dynamic data from an edge proxy that injects secrets and caches results.
Static Jamstack sites have no server at request time, so any key referenced in their JavaScript is public. Fetch secret data at build time or through an edge function or proxy, and configure CORS on the endpoint rather than relying on the browser.
iOS and Android binaries can be decompiled and their traffic inspected, so any API secret inside an app should be considered public. Store only user session tokens on device in Keychain or Keystore, and route private API calls through a server or edge proxy.
In Next.js, any variable prefixed NEXT_PUBLIC_ is inlined into the client bundle. Secrets are safe only in Server Components, Route Handlers, and Server Actions, and every Server Action is a public endpoint that must authenticate and authorize its caller.
Client-side React apps run entirely in the browser, and build-time variables such as VITE_ and REACT_APP_ are inlined into the bundle. Keep secret API keys out of React code entirely and fetch private data through a server or edge proxy.
React Native JavaScript bundles ship inside the app and can be extracted, and Expo inlines EXPO_PUBLIC_ variables into that bundle. Keep secret keys off the device, store session tokens with SecureStore or Keychain, and proxy private API calls.
Retool resources store credentials on the Retool backend, so queries against them do not expose secrets. JavaScript queries, transformers, and temporary state run in the browser, so keys placed there are visible to every user of the app.
Vue single-page apps run in the browser and Vite inlines every VITE_ variable into the bundle. Keep secret keys out of Vue code, avoid v-html on untrusted content, and call private APIs through a server or edge proxy.
Anything shipped to a browser, including environment variables inlined at build time, is readable by every visitor. Web frontends should hold only publishable keys and short-lived user or client tokens, and call private APIs through a server or edge proxy.
Webflow custom code and embed elements are published as public HTML and JavaScript. Any API key placed there is visible to visitors. Fetch dynamic data from an edge proxy that holds secrets, and keep Webflow site tokens for server-side CMS automation only.
Cloudflare Workers should read credentials from secret bindings set with wrangler secret put, never from plaintext vars in wrangler config. Keep handlers stateless between requests, use the Web Crypto API, and use ctx.waitUntil for background work.
Drizzle parameterizes values in its query builder and sql template tag, which prevents SQL injection. The risks come from sql.raw with user input and from pushing schema changes straight to production. Generate migration files, review them, and apply them deliberately.
Neon connection strings contain credentials and are server-only. Use pooled connection URLs or the serverless driver from edge and serverless code, give each application a least-privilege role, and use branches to keep development off production data.