Is a private repository enough to protect a frontend secret?

No. A private repository controls who can read the source before deployment, not what users receive after deployment. If a value is compiled into browser JavaScript or embedded in a mobile app, users can inspect the bundle, intercept requests, or extract constants. The trust boundary is about the runtime environment, not the repository visibility.

Can the client perform authorisation checks at all?

Yes, but only as a user experience optimisation. Hiding an admin button or route can make the interface clearer, but it does not enforce access. The server, backend policy engine, or managed database rules must repeat the check using trusted identity and trusted records before performing the action or returning sensitive data.

Are all API keys secrets?

No. Some keys are identifiers or publishable credentials intended to be visible, often limited to specific origins, projects, or operations. Others authorise privileged actions and must remain server-side. The practical test is what an attacker can do after copying the value. If copying it grants power you would not give any user, it belongs inside the trust boundary.

Trust Boundary

A trust boundary is the line between code and data an attacker can inspect or control, and code and data protected by your infrastructure. It decides where secrets, authorisation checks, and security assumptions are allowed to live: public clients sit outside it, trusted servers and managed backend policy engines sit inside it.

The boundary is necessary because deployed client software is not a sealed box. A browser user can inspect JavaScript, storage, requests, and responses. A mobile or desktop user can often decompile, patch, proxy, or debug the app. Anything sent to that environment should be treated as readable, and anything returned from it should be treated as chosen or modified by the user, not as evidence of truth.

Concretely, the client may hold public identifiers and short-lived values designed for exposure, but it must not hold secret keys, signing keys, database passwords, or final access decisions. A safer flow is client to backend to secret-bearing service. The backend reads the server-side secret, checks the authenticated user against server-side records, performs the privileged operation, and returns only the result the client is allowed to see.

The trade-off is extra indirection. You add backend code, policy rules, credential scoping, logging, and failure modes instead of calling every service directly from the client. The honest answer is often: it depends on what the value can do if copied. A publishable payment key is designed to cross the boundary; a secret key that can create charges, refunds, or subscriptions is not.

Engineers meet this constantly in frontend environment variables, API route design, cloud credentials, and third-party SDK setup. Next.js public variables are bundled into browser code, while server-only variables are not. Stripe separates publishable and secret keys. Firebase Security Rules enforce access on the backend. AWS IAM roles and temporary scoped credentials reduce blast radius when something inside the boundary is compromised.

Go deeper

DeploymentThe Trust BoundaryDraw the line between what the client may be trusted with and what it may not, and place your secrets on the right side of it.Open the lesson

Common questions

Is a private repository enough to protect a frontend secret?: No. A private repository controls who can read the source before deployment, not what users receive after deployment. If a value is compiled into browser JavaScript or embedded in a mobile app, users can inspect the bundle, intercept requests, or extract constants. The trust boundary is about the runtime environment, not the repository visibility.
Can the client perform authorisation checks at all?: Yes, but only as a user experience optimisation. Hiding an admin button or route can make the interface clearer, but it does not enforce access. The server, backend policy engine, or managed database rules must repeat the check using trusted identity and trusted records before performing the action or returning sensitive data.
Are all API keys secrets?: No. Some keys are identifiers or publishable credentials intended to be visible, often limited to specific origins, projects, or operations. Others authorise privileged actions and must remain server-side. The practical test is what an attacker can do after copying the value. If copying it grants power you would not give any user, it belongs inside the trust boundary.

Every term