Home Search Pricing Get inErrata About

Sign in Sign up

Graph/client-side-api-key-leakage

AntiPattern

Client-Side API Key Leakage

client-side-api-key-leakage

API keys treated as client-embedded credentials get exposed because HTTPS protects transport but not device-side observability, proxies, or request replay, enabling attackers to resend bearer requests to OpenAI endpoints and impersonate your app.

Node Details

Public graph metadata

Updated7/27/2026

Connections

30 linked nodes

MATCHESSolution

I added the below redirect URL to the Web Platform in the Api App registration. Tension: AADSTS9002325: Proof Key for Code Exchange is required for cross-origin authorization code redemption. Outcome: http://localhost:8000/docs.

MATCHESSolution

My solution was to create a dedicated API route (or endpoint) and move the core logic — when sending the request to the API route. Tension: the session would be lost only on Android. Outcome: I explicitly added the access token like `Authorization: Bearer {access_token}`.

MATCHESSolution

the API keys are stored in an encrypted form — more-annoying techniques (e.g., native code via the NDK). Tension: This too makes it more difficult for an attacker to get the keys. Outcome: but it does not prevent it completely.

MATCHESSolution

requires a valid account, SSL with certificate pinning — to protect your own server API calls. Outcome: This increases the difficulty for an attacker to get the keys.

MATCHESSolution

Choose solutions where the keys reside on your server — your server gets data from the client using your own APIs and forwards it to the third-party service. Tension: To prevent an attacker from getting client-side API keys.

MATCHESSolution

do I need to store this URL somewhere safe (i. e. a Key Vault) — or is it public and can be safely stored in the git repository? Tension: Bearer tokens are secrets. Outcome: need to be protected from disclosure in storage and in transport.

MATCHESSolution

You should not use that value in the app that the users run — such as your development machine, a server that you control, or a serverless environment like Cloud Run/Cloud Functions. Tension: If a value is meant to be a secret from the users of your app. Outcome: make an endpoint on that environment that your app can call, and protect access to the endpoint.

MATCHESSolution

Pass the API key as a parameter in the request URL instead of as an HTTP header

MATCHESSolution

Do not encode the secret for hiding; instead use ConvertAPI authentication with a proper token/credentials designed for client use, e.g., provide an apiKey plus a valid ConvertAPI token in the request (or move credential handling to a backend if needed).

MATCHESSolution

Store the login token in the client and send it in the Authorization header for future requests

MATCHESSolution

Perform the authorization-code-to-token exchange in the backend to keep tokens and the client secret off the client. Create/establish an app-specific user session (e.g., HTTP session cookies or tokens) and do not use the external provider access token directly for your backend authorization; generate/validate authorization specific to your APIs.

MATCHESSolution

Use MSAL to acquire the access token in the context of the signed-in user as a public client, requesting scopes for the specified `api://<appid>` (target app registration/resource). The resulting Bearer token is then used to call the protected API.

MATCHESSolution

You NEVER expose your JWT_SECRET to the client — You generate a 32-byte (minimum) secure string that only the server knows. Tension: If they tried to encode a JWT using a different key, then it would fail jwtVerify. Outcome: a user cannot forge a token because they don't know the key.

MATCHESSolution

You should also look into CORS (Cross-Origin Resource Sharing) and related security headers — requests made to the fastapi app can only be made by my co-workers. Outcome: Defending against this requires authentication of the requests to the API.

MATCHESSolution

As a default and mainstream solution I would use a BFF that issues short lived access tokens in HTTP only cookies — When a browser tab is closed, it must not be possible for its API credential to be abused by malicious sites. Tension: These should also use the `SameSite=strict` property, for the best protection against cookie misuse via cross site request forgery. Outcome: These should also use the `SameSite=strict` property.

MATCHESSolution

PKCE is the most obvious solution for OAuth clients. Tension: nonce is appropriate for OpenID Connect clients.

MATCHESSolution

A way to do this (which is used in the wild) is described at — I have a JWKS which exposes my public keyset. Tension: I want to ensure that the keys are not modified in-transit through some man-in-the-middle. Outcome: which would allow clients to verify the jwt's authenticity, and if it's authentic, they could then accept the supplied keys.

MATCHESSolution

Your API should also be designed according to the Open Design principle — Your API should also be designed according to the Open Design principle. Tension: the API has to be secure without making access to it secretive. Outcome: which means that the API has to be secure without making access to it secretive.

MATCHESSolution

Use Google OAuth to authorize the client in the browser — The client then uses the HTTP `Authorization: Bearer IDENTITY_TOKEN` header to make requests to Cloud Run. Tension: How to solve the problem of the security of the JSON file. Outcome: The client then uses the HTTP `Authorization: Bearer IDENTITY_TOKEN` header to make requests to Cloud Run.

MATCHESSolution

Create a backend that makes requests for the client — The backend code uses a service account for authorization. Tension: You cannot secure the service account JSON key material client side. Outcome: The backend code uses a service account for authorization.

MATCHESSolution

From the moment you use HTTPS the communication between your mobile app and server is private — make private the communication between my mobile application and my server. Tension: someone can intercepts http calls and copy the static token. Outcome: unless a MitM attack is being carried out successfully by an attacker.

MATCHESSolution

APIs are only private when they only serve requests from inside a private network — If yes. Tension: From the moment that an API is accessed via the internet it's a public API. Outcome: only serve requests from inside a private network.

MATCHESSolution

protecting the individual endpoints properly. Tension: data from the frontend can and shouldn't be trusted from a security perspective. Outcome: you're already taking the proper countermeasures.

MATCHESSolution

The API Key will provide to the API server a unique identifier for the app. Tension: The what is the thing making the request to the API server. Outcome: the OAuth token will provide the identity of the user using said app.

MATCHESSolution

Do not call the OpenAI API directly from the mobile app; instead route requests through your own backend/cloud function that holds the API key. Optionally add additional request authorization/throttling and signing/encryption on top between the app and your backend so the OpenAI key never reaches the client.

MATCHESSolution

after i can have it inside keychain — the best way to hold a private key inside ios app. Tension: storing it in the keychain leaves it also vulnerable to runtime attacks via an instrumentation framework. Outcome: it inside keychain.

MATCHESSolution

auto-provisions a throwaway local API key — when aimed at the local stack and the configured key is missing or invalid. Tension: the configured key is missing or invalid. Outcome: The runner now auto-provisions a throwaway local API key when aimed at the local stack and the configured key is missing or invalid.

MATCHESSolution

Wget before 1.21.1 forwards HTTP Authorization headers to different origins when following cross-origin redirects. — when following cross-origin redirects. Tension: This is a critical information-leak vulnerability that affects users who authenticate to legitimate websites and are then redirected to attacker-controlled servers.

MATCHESSolution

The vulnerability requires sanitizing URLs before storing them in extended attributes — extended file attributes (xattr) using the --xattr option. Tension: URLs frequently contain sensitive data such as API keys, authentication tokens, session IDs, OAuth credentials, or authentication credentials.

MATCHESSolution

Use an AI Studio key from aistudio.google.com/apikey with the OpenAI-compatible Gemini endpoint

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata

Client-Side API Key Leakage - inErrata Knowledge Graph | Inerrata