Find out whether your app exposes a secret key

Understand the secret before searching for it

Suppose your recipe app asks an AI service to rewrite cooking instructions. The API is the agreed way your app sends that request. A private API key tells the service which account is requesting it. If someone else obtains that credential, they may be able to use your allowance. Treat it like a password, not like the public address of your website.

The frontend runs in the visitor’s browser. Anything sent there can be inspected, even if no button displays it. The backend is the service your app controls away from the browser. A private key normally belongs there, in protected configuration. Some services also supply deliberately public identifiers; a variable containing the word “key” is therefore a clue to investigate, not proof of a leak. Secret handling involves storage, access and replacement as well as code. [1]

Ask Ruthless to draw the route in words

Before pasting code, replace every credential value with REDACTED. Keep harmless names such as AI_SERVICE_KEY and the surrounding lines that show where it is used. Remove customer information and private addresses too. If you do not know what is secret, ask your builder for a safe excerpt rather than uploading the whole configuration file.

Open GetRuthless, inspect Choose model and select an available model suited to explaining code. Paste this fictional example first. The aim is to learn which piece runs where. The model cannot inspect your browser or saved files merely because you name the app; it can only assess the supplied example and tell you what evidence is missing.

I built a recipe app and do not understand where keys belong. Safe example: browser component RecipeButton calls fetch("/api/rewrite"). A service file reads process.env.AI_SERVICE_KEY, whose value is REDACTED, and contacts the AI service. Explain which part the visitor receives and which part runs privately. Tell my builder how to check whether the actual private key reaches browser files, browser requests or saved project history. Do not ask for the value. Separate what this example suggests from what requires inspection.

Ask for evidence, not a reassuring variable name

A useful answer says the example appears to keep the credential in the service, but the delivered browser files still need inspection. Ask your builder to examine the files downloaded by a visitor’s browser and the requests shown in its Network panel, a developer-tools view of data sent and received. They should report where they looked and whether a private credential was present, without copying its value into chat.

Also ask about project history: saved previous versions can retain a secret after it disappears from the latest file. A file named .env is often used for configuration, but its name alone does not make it private. The builder must check what was published, committed or otherwise shared.

If a real private key was exposed, removing it from a page does not stop copies already taken. Ask the service account owner to revoke or replace that credential, update the app’s private configuration and inspect service usage for unexpected requests. Share only dates, amounts and redacted observations when asking Ruthless to help interpret the result.

Practise with names, never values

Make a small inventory containing a service name, credential name, purpose and location, with no values. For example: “AI rewrite service; AI_SERVICE_KEY; recipe rewrites; private server configuration.” Ask Ruthless what evidence would show that location is correct. Your exercise is complete when you can explain why a public website address may be shared while its private service credential may not.