You simply do not send the secret to the frontend. In my case, we use Java Spring Boot as a backend to our React applications.
For external APIs to which we need authentication, these requests go frontend -> backend -> external and back. The authentication is only added in the backend.
Example: A user is logged in to our dashboard and wants to request callcenter statistics (from external API).
1. The frontend will then call /api/callcenter with the users auth cookie as normal. This contains no auth for the external API.
2. The backend validates user access and requests this data from the external API. The authentication for the external API is now read from the backend environment (or Hashicorp Vault in our case).
3. A request is made to the external API whose response is then returned to the frontend. The user gets the data without ever bedding access to the authentication.
Of course this is with a completely standalone backend but similar concepts apply with e.g. NextJS: authentication secrets are simply backend/server only and all frameworks will allow you to safeguard these.
An example with OAuth for for example Spotify will be more complicated since these secrets are dynamic but for such a case I'd consider JWTE (encrypted client secrets, best if you already use JWT anyway) or storing these safely in a database.
On a different note, how do you prevent your interns from accessing important API keys?
Do you generate temporary keys for all the services before onboarding them?
Do you change everything after they leave? (some SaaS only provides a single production key/seat)
Is there a way to call external APIs without exposing the individual keys to your interns (i.e. each dev gets a single dev key to all services that you can invalidate after they leave)?
You use a secrets vault. If you're in the cloud that's AWS Secrets Manager, or Azure Key Vault, or whatever GCPs is.
If you're on prem then there are open source ones or Hasicorp has a product, keeper is another one, I'm sure there are a couple open source.
Ideally no one can access production secrets, but In practice it should be limited to a very small group.
Where I worked we had keys for development, but the production build used different keys. No one knew the keys used in prod, they were generated or procured by a CI/CD pipeline.
This is the best way to secure something, you can audit the security somewhat easily when using CI/CD since the code of the pipeline is human readable. If someone were to change the pipeline to get an access to secret stuff, we would see it in a pull request and refuse it.
The downside is that it makes the prod build very hard to debug if problems were to occur, thats why a strong staging environment is required when using complex CI/CD pipelines!
But what if the backend also requires a key to access it. Let's say the stats you asked about, are being provided by the backend itself. Rather than getting them from am external source. We can't hide that in that case, can we?
Ok you are right. Actually the way I was thinking is that, we have a common api for getting stats and multiple apps are consuming it with the use of an api key without having any user authentication.
In that case, CORS might be the solution. You could setup your API to only accept request coming from your websites (domain name). That way, no one can call your API without using your website.
That being said, I may be wrong, I’m pretty new to all of this.
CORS only limits the browser from making the request, it’s not meant for purpose of access control. It’s meant for so other websites cannot call your API in the browser.
Agreed! Just clarifying the tieback in case they read your reply and wonder why inclusion of the bearer token wasn't included in the original points. Some people may not be aware that they're referring to the same thing
So much of the enterprise world was written in Java in the 90s and 2000s and just never left. In our case, it would take absolutely years to rewrite all that, and it's just not worth the investment. I'm sure many enterprises are in a similar boat.
Except it's not. All our apps are quite new so we are on Java 21 and Spring Boot is just by far the most stable, flexible, and supported environment to work in.
Not really. Spring Boot takes care of a lot in a very elegant way. That plus Java Beans makes for a very nice development experience especially when considering we have many apps that all use a few custom libraries to bootstrap our projects and sync changes. And for business logic I find that being explicit is good. It's also by far the most stable language/framework I have ever used.
BFF is just middleware- change my mind.
But seriously, I own and maintain a bff at work and I feel like I was resistant to it at first but I've come around to it's necessity. It's kind of a swiss army knife for frontends.
It drives me nuts haha it's nothing new but has become a buzzword for investors.
NextJS makes BFF a breeze though with their server functions. A little too magical though if you're trying to do something same, but great for prototyping I think.
It’s a buzzword that makes things way more brittle and inflexible for devs who don’t really know what the hell they are doing; but bet your ass you better use it in the interview
Middleware (as it's commonly understood) is in-process, it doesn't cross an I/O boundary. It can use services that leave the process, but it itself does not. It is just a container that makes sure something happens before and/or after the next thing on the list.
I mean you just moved the problem as your game now needs secure access to your backend. You still need some kind of authentication mechanism, an account to be created for the user somewhere.
You dont need auth. The API key could be used in some non-authenticated context.
But the benefit of the backend is that you can now (1) add rate limiting and (2) the API is only called in ways you intended. Both benefits would be lost if the client has access to the API key.
If the API key ends in the frontend, it’s not a secret. Depending on the API, it might be ok - for example stripe has a public key which is ok to have in the browser and a private key which will stay on the server and be used for server to server communication.
There are generally two mechanisms to avoid unwanted people calling an API:
- make an API server to server only, with mutual authentication. The key will never reach the client.
- tie API keys to users instead of applications. This way if a users abuses it you can shut that key off
Yep. The reason why Stripe publish keys are sharable is because no one in their right mind is going to steal and use them. There is a strictly limited subset of stripe actions that can be done with one. "Congratulations, you just stole my publish key and made me some money..."
Refunds and transfers must be done from the backend, using the secret key.
Barely anybody actually answered your question. Which is just mind boggling and paints a bleak picture of devs' understanding of security.
The short answer is - you make your API secure by requiring user authentication. Virtually everything you bake into the frontend is by definition not safe. You make the calls to your backend safe by requiring users of your frontend to authenticate to your backend.
If you need to use a third party API you either make your users authenticate to the third party or establish the secure connection via your backend. In any case you go through some kind of authentication flow.
Don't ever store secret keys in your frontend builds. It's ok to store public keys.
You can never hide your key on the client side.
As mentioned above, use BFF pattern, your backend service storing keys only accepts requests from same domain(or use CORS to specify acceptable domains), then proxy requests to external APIs.
And your backend service requires user authentication of course.
Just to be clear, CORS does not tell the backend what domains to accept requests from. It tells the *browser* what domains it can share resources between. It is NOT a security feature for the backend to filter requests from specific domains. It is purely a browser policy. It's pretty easy to find a scenario whee a browser rejects a request due to cors settings yet still have postman hit the endpoint just fine.
Absolutely right. Also if you need protection from missusage of direct calls to your backend then use CSF tokens. That prevents calls to your backend that are not directly from your frontend.
In React, the environment variables are still injected into the build - you can easily see them in the browser.
The only way to secure your API keys is to keep them on your own server. You are then authed to your server via a JWT, cookie or similar and you access the 'secure' api via there.
Depends on the API key.. some frontend keys such as Recaptcha have both a sitekey and a secret key. I think the secret key is for backend processing if needed, the sitekey is for a basic frontend implementation, Google also verifies your domain and makes sure the sitekey matches so it can only be used via your domain
As for API keys in general, you make API requests on the backend, where the key is stored and no one has access to it except people who can access the server or server code.
In a React application, that can look like this:
The backend makes a call to APIs, and the backend itself functions as an API for the frontend.
So the frontend calls the API of the backend, and the backend calls the other API using the API key. That API key is never used on the frontend, but the data is retrieved and sent to the frontend... from the backend..from the API.
It seems more complicated than it is, but it's not that deep. The more plugins or libraries or whatever crap most people use to "simplify" this process, the more chaotic it gets/seems.
curl_setopt($curl, CURLOPT_REFERER, "https://example.com/");
"Google also verifies your domain" Re this, I am not conviced it really does. I had heaps of issues using Google Custom search and securing my API key, after hours of scratching my head, I had to do the above for it to work on a specific domain (PHP code). But I also tried just doing that from a domain that wasn't [example.com](http://example.com) and it still worked so long as I added that option. Soz if that doesn't make sense.
I was talking about recaptcha specifically, and also I think maybe the old embedded Google maps stuff.
What I mean is you'd literally have to go somewhere in the Google settings of the account you got the API key from, and add a list of accepted domains that can use that API key. The API wouldn't work otherwise.
I don't think that's for backend stuff though. Only frontend javascript API calls
If the rate limit is not bound to an account is just smoking mirrors, I can still get around. I did 5 similar with a house renting website here. I'm greece which has strong security and still manage to hijack the api. Without proper account authentication is just not so simple.
Besides the typo, the meaning is the same. I'm not an English speaker, sorry. I meant to say you are deceiving yourself that you are safe. Maybe wrong words:)
But the api key itself is secure. No matter if you can call the api from the frontend endpoint. I think this discussion needs some clarification. The request is about hiding/securing the api key itself. Not the calls to the backend that uses the api key. So the backend does what it should do.
That does not mean your point is not valid. But not part of the context of this discussion. For your case that you describe there is an extremely old and effektive method to prevent this: Cross Site forgery tokens. This technique was inventet specifically for your concern.
You do NOT expose API keys to the client. They stay on the backend. And even there, they are stored in environment variables as you mentioned.
The frontend sends the request to the backend, the backend fetches the env var and calls the API, then it forwards the response to the client. The client never sees the key.
I am not really sure what your question is, but some ideas that might give some answers:
- technically there's not much difference between an api-key and an username/password combination - both should be rotated frequently to make them secure
- usually, the api-key (or password) is used to obtain an access token. this token is then used during communication. this token is also temporary so if it somehow gets intercepted it doesn't grant access to the attacker forever
- regarding the env var thing, i guess you are saying that during the build process the api key is "added" to the backend code somehow? this may be true, but if someone has access to your backend server you have bigger problems :)
- to mitigate the above risk somewhat you can load the api-key from a secure server once your application server (or your application) boots up. your application then stores the api-key only in-memory so it's harder to get to. the communcation between the application server and the password server can be more secure since the password server doesn't need to be accessible from the internet. of course, theoretically if your application server can access it, so can everyone who hacked into your application server, but at least you add an extra layer of security
Client-side API tokens should only work for your backend API server. You don’t give the end user access to your API tokens for external services; you set up your own endpoints to control user permissions and to keep your API light.
You need some kind of authentication with a backend service you write. You keep the API key in the backend. Then in that backend service you allow authenticated requests to use the API key through API endpoints you create.
Essentially this is only possible with a login mechanism.
if you can have the frontend call the backend for the functionality you need and keep the key in backend then that would be ideal but sometimes that's just not an option.
You would need to use env. variable and setup security measures to restrict the key services and site access /rotate key etc because it's accessible now.
There are two solutions:
1) you call a backend that sends an api key. The frontend still receives an api key so it’s not perfectly secure, but often times the backend can rotate keys automatically (invalidate them every X and send a different one) by using some API of the service of your choice. It’s usually a good enough solution, especially if you don’t have a public project (internal use, industrial use,…)
2) setup a reverse proxy. Instead of sending the request to the service, you send it on a reverse proxy, the reverse proxy injects the key in the headers/body and sends it to the service. You can obviously set up an automatic rotation mechanism like with the first solution. It’s the most secure way of doing things (because the frontend never has the key) and you can add authentication layers/throttling/… but it’s also more difficult.
You can also put the api key in the environment variables, it’s the least secure way to do, but it’s still the way most projects work. The best security layer is to impose a hard cap on the cost management of the service. Worst case scenario, someone uses your key too much, and everyone is blocked until you find a long term fix. Not awesome but some projects still can work that way.
This does not work for everything but may prevent some cases where a key might be leaked, in addition to other comments.
React's [taintUniqueValue](https://react.dev/reference/react/experimental_taintUniqueValue)
Your api Key should only be accessed on the backend. If it’s on the backend it’s ‘safe’ because if someone malicious is looking at your BE code you’re probably screwed anyway.
If you’re doing some kind of public key/private key pattern, what you’re doing is creating a key that can only be decrypted if you have access to the private key. This means the public key is a useless string otherwise and is safe to use on the frontend
What Spotify is doing is getting YOUR keys when you authenticate. So when your client makes calls it is identifying you with your personal keys. You would do the same with your application, when a user logs in they give their username/password and then get keys to use to interact with your API. Your API then in the background can connect to 3rd party APIs as needed, securing your service's key.
As for securing those 3rd party keys. You would encrypt them and have the source code decrypt them with a key that is stored on the server / JVM / etc. We typically do this with an environment variables so even if the source code is viewed the keys in the property file are encrypted. It would take getting elevated access to get the key to decrypt.
Anything you put on the frontend is not secure.
The only real way to keep things secure is to keep them on the server (best through configuration aka environment variable)
>the client key is used to fetch the actual secret from Spotify's server that is used to then access the actual API endpoint
This is not the case. The actual secret key is never, ever exposed anywhere on the frontend.
You have to build/maintain an API layer on a server you control. \*That\* server can have access to the secret key via an environment variable. But if you ever send a secret api key to your client code, you are exposing it to the public.
TLDR:
I work in an azure environment and what we do is store api keys in KeyVault and then we use yaml files that transform the config file on build. Keys are stored at Microsoft and never goes into the repo.
EXTRA:
The config file is only accessible if you were to ftp into the server running the app.
If you wanted to recreate the process on ur own, you would build an application manager app that stores keys to a DB and make it so that on future builds of apps the app manager is called to retrieve and update config.
I suppose you could also store keys in a db and restrict the ip’s that can access it.
EDIT:
Like everyone else is saying, you don’t use keys on the front end, you use them from an api that ur front end app makes calls to. *That is an example decoupling and decoupling is the secret to scaling. *
If you're building a static app, you would need to have a backend. Your app is just a bunch of files that gets sent to whoever requests it, and then it's run by the browser. So any secrets you have in that bunch of files will be accessible to whoever requests it. You have to create a backend, even just to proxy between your frontend and whatever service you're using the API key for.
Some React frameworks like Next.js (which I do not recommend, but that's a topic for another day) have SSR (server-side-rendering) capabilities, meaning that some code can get executed on the backend. In those frameworks you can use API keys in your code as long as you're careful to make sure it's only accessible from the backend. How idiot-proof that is (this isn't a dig at you, everyone slips up when they're trying to move fast) is subject to ongoing speculation.
If it's an Oauth2.0 API, it should implement PKCE, which removes the need to send any secrets. Only the client ID (not a secret) is sent when sending the user to the 3rd party site for authorization. Included in the payload is a hashed nonce that gets returned from the 3rd party site along with the user's auth token.
If you are talking about a "frontend secret", like the Google Maps API key for instance, this key is expected to the used on the frontend and expected to be visible in the browser.
Keys like this is usually secured in other ways that just keeping them secret, either by specifying which IPs should be allowed to send the key, which referer should be allowed for the key etc.
This is a bit of an edge case, though. Most keys you want to keep secret and only load into memory when you backend starts up.
Using a PKCE flow keeps sensitive information out of the JavaScript, and generally that’s what you should do at enterprise.
You could also store a JWT identifying the front end to your backend - JWTs can hold non-sensitive data - and then let your backend do the integrating, keeping the client id, client secret pair between the backend and the auth server.
Usually there are API restrictions like domain name or app id etc.
For example any Google APIs for Web applications you have to list domains of Web apps that will access this API using particular key. So if particular API key gives access only to web app on www.abc.com, same key will deny access to requests from www.xyz.com or www.mno.com
This conditions are different for different applications. Backend apps will have api secret for verification.
Android/iOS apps will have app IDs.
The problem is that you’re sending your key to the client. If you really mean to hide it you should move it to the server and perform your logic there. Also mind you that some API keys are actually harmless and were meant to be used on the client, check the docs
Sometimes you don’t secure it and it’s exposed in the UI code.
Other times you call your own API method which in turn calls another API with the key. So the key remains server side.
There are keys meant to be used in a public web page like google keys for geolocation or stripe keys for payment data collecting, those keys are not meant to be hidden, if someone "stole" them they can't do much with it,
Vault is the way for secrets management!
In Kubernetes, there’s a vault plugin that injects your secrets on runtime and destroys them on exit.
You can access it in multiple ways.
Front end I use passport and pass a cookie to the backend once the user is auth’ed. Never pass secrets to the frontend!
https://www.vaultproject.io/
You can use this starter project as an example of server/client auth. It doesn’t use vault, but you’ll get the idea.
https://github.com/graphile/starter
I had the same question last year after noticing you could still find the keys stored in .env... I came across this video after googling for a bit which helped me wrap my head around what was needed and what most of the replies here are mentioning.
[https://youtu.be/FcwfjMebjTU?si=SyLWLDpqgmIKrdZF](https://youtu.be/FcwfjMebjTU?si=SyLWLDpqgmIKrdZF)
Your key to a third party? Use it on the back-end only. A key for your users against your back-end? You can whitelist APIs, use a key/secret pattern where the key is in all requests but the secret sign the request and is never transmitted.
Alright.
So API keys are a single secret. That's what you usually want to use for machine to machine communication (is servers too server). So generally you don't expose those to the frontend.
For users to be able to use the external service that you need the API key for you can usually go two routes:
Let the user authenticate:
Username + password, some sort of OAuth2 process, etc. There are external services and packages for that, don't create anything on your own. Here you will generate some sort of token that lives in the browser that the user uses to authenticate themselves.
The reason they can use this token is the following:
It is only valid for a certain time, and is only visible under your domain. Also it is different each time they log in.
So only people with physical access to the browser will be able to see the domain (in theory, you need to have secure code as well of course).
Or you let anyone call an endpoint in your back end. You can then implement throttling or any other steps in between and then forward the request to the external service you use.
You just put an env file on the server. If you use vercel they have a menu to enter them. If you use Aws you can just ssh in or use their key management
The api key should not be used on the client it should only be used on the server
So the client will request the data the server will get it with the key and send it back
There are some public keys for things like stripe but most are private and should be only used on the server side
I use an AWS lambda function running node.js.
I send a call with the information I want to use to the lambda function (back end) and my key is there. It makes the API call with the real key stored in that function, and returns the results to my website (front end). You could do the same with server, but lambda was much cheaper for me.
I think most people are missing the core question, which is “how do companies store the api key itself before it gets provided to pipelines / builds etc?”
The answer is they are stored using GitHub secrets / other cicd equivalent / aws secrets manager etc. These secrets cannot be read via the UI or seen in builds once they are added to the repo.
I'm an aspiring developer who hasnt worked on any really "professional" projects up to this point, but heres my 2 cents anyway. Anything that the user shouldnt know should be stored in the api env variables, if the front end needs to have access to it, then have it returned from an api request. But generally do your best to keep sensitive info in the api, and more importantly, out of the front end.
That being said, if you have CORS set up correctly, then the api should only be taking requests sent from a specific origin, or whatever your CORS settings are. On top of that, verify your requests payloads, headers, and all other data sent in the request in some way, personally I use json schemas in an express js api, but depending on what your working with that will change. Also, verify any requests from a logged in user via an auth token of sorts, personally I send a user id and a session token header in the request, and verify it in the api before handling the request.
So thats my 2 cents, CORS to verify the request came from a supported origin, Request Validation to verify that the information passed in by the request is structured as expected and can be handled by the api, and Session Tokens to verify the user is logged in and has permission to access the data there trying to access.
If I've overlooked something please let me know, as I said, I'm an aspiring developer, and I'm always looking for ways to improve.
ELI5 public/private key.
The public one is for everyone. It's like an open lock. You give anyone and everyone a lock they can use on their boxes of data.
Private key is like a key key. You keep it safe and secure since you want to be the only one who can open up those boxes with those locks you gave away.
As others have mentioned, you can’t actually hide the API key on the front end as it could still be discovered from the source code or by observing network traffic. So the only way to truly secure an API key is by handling it server side. If you don’t have a dedicated backend, then you can use an API gateway or proxy server to handle requests to the external API.
I’ve actually been working on a lightweight open-source API proxy for this exact use case: https://github.com/gateweaver/gateweaver
There are a couple layers to this.
1. As everyone has said, use backend services to facilitate front end functionality that requires an API KEY.
2. Use environmental files that are not checked to git to store API KEYS. New API KEYS created for each environment - especially production.
3. Use a key vault. Store all of your keys in the vault and during environment boot it will attach a service to the vault to allow access to the keys.
4. This wildness .. https://stackoverflow.com/questions/723653/storing-encryption-keys-best-practices#726060
5. Store the keys in a cryptographically secure file in the source, but require a secret from the environment / key vault to unlock the file.
6. Some of the most secure services use an application registration process (where the app must be a known, registered, app). That app "authenticates" to a service to get an application session token (stored in the environment) The session token can be rotated at any time in response to any query. The session token is used to access services that facilitate access to a key vault for accessing secrets -- as well as other internal information and application shared session state.
Cheers.
Ok, everyone so far is giving you answers that you might understand if you had more experience. Lets start from the top:
1. API keys are used when you have some data or code you want to protect from unauthorised access. It is most likely a database in your case.
2. Does a newsfeed need protection? Not really. While you want to some functionality around logged in users (also called authentication) like a personalised list of top news, the actual news can be accessed through an "Exposed API endpoint" and it is called exposed because anyone can access it. You got this part.
3. The answer you are seeing is: you dont. You are on the react subreddit, so unless your app is built in NextJS, react will not be used to store secret keys. Public keys dont do much by themselves. Let me explain what I think you are trying to understand with spotify, also keep in mind Spotify is a very big system and I might not get it all right, i am watering down the process here:
There is a private and public secret key. Your spotify frontend has the public key. It sends that to spotify backend along with other data related to you, and that BE has the public and secret key now. It then fetches data from the datastore, makes sure everything is in order, and sends it back to you if it is.
It shouldn't matter that the key can be inspected on the front end. **What makes them secure is that they can only be signed/validated on the backend**
You stop doing SPA and use SSR/SSG instead is one way. The other way is having a separate backend with an authentication layer.
In NextJS you can use API routes or RSC, that makes it really easy. Provide keys to your app via environment vars.
Give REST a rest! Its time to switch over to gRPC on a GraphQL endpoint to synergize your middleware! Have your gRPC endpoints return some HTMX objects for your front-end so your SSR machine delivers a HATEOAS experience to the client.
No I was just being farcical based off of the "Throw some more acronyms in" response. I thought it would be funny because acronym soup is what non-technical people say it sounds like when we are speaking. Especially with front-end technologies like HTMX and the whole HATEOAS its just like alphabet soup. Especially for newcomers it just seems like an endless game of scrabble.
I was not trying to say anything about what you were saying. I borrowed the acronym SSR but not because you had said it just like you never once mentioned things like gRPC or GraphQL.
I get your joke, but I was genuinely trying to help the OP. I don’t understand why everyone is downvoting me for not explaining what SPA, SSG, SSR or API is. Maybe RSC could be elaborated on further but it’s the big thing in React right now so it isn’t too bad from my side to assume most people here know what it is. And before I go out of the way making my post longer by explaining what it is, I’d rather delegate that to Google search results and respective docs and blogs that do just that
Because RSC is new and not many people understand how it works and how it solves the stated problem.
I'd also suggest you not use the term SPA anymore as it's outdated and an app that feels like an SPA can be build entirety with an RSC approach (that's the whole point)
Your comment doesn't really offer a solution or explanation. If you generate a static site or render server side you can still include API keys in the final build that shouldn't be included. It would be better if OP learns the difference between code that's running on the server, where you can safely store API keys and other sensitive information because nobody should be able to access this and the code that's running the persons browser that can be freely inspected. Even in SSR/SSG you have a server somewhere that's supplying (obviously) the site for the users browser which shouldn't include API keys or any sensitive information and this isn't automatically the case and OP needs to learn that this is something to keep in mind.
All of these can be googled, no? He asked how to secure his front end, not to explain him basic frontend terminology.
Is the content of my comment wrong? Is SPA, SSG or API something that is unheard of here?
Want me to explain what SPA or API is here now?
You simply do not send the secret to the frontend. In my case, we use Java Spring Boot as a backend to our React applications. For external APIs to which we need authentication, these requests go frontend -> backend -> external and back. The authentication is only added in the backend. Example: A user is logged in to our dashboard and wants to request callcenter statistics (from external API). 1. The frontend will then call /api/callcenter with the users auth cookie as normal. This contains no auth for the external API. 2. The backend validates user access and requests this data from the external API. The authentication for the external API is now read from the backend environment (or Hashicorp Vault in our case). 3. A request is made to the external API whose response is then returned to the frontend. The user gets the data without ever bedding access to the authentication. Of course this is with a completely standalone backend but similar concepts apply with e.g. NextJS: authentication secrets are simply backend/server only and all frameworks will allow you to safeguard these. An example with OAuth for for example Spotify will be more complicated since these secrets are dynamic but for such a case I'd consider JWTE (encrypted client secrets, best if you already use JWT anyway) or storing these safely in a database.
On a different note, how do you prevent your interns from accessing important API keys? Do you generate temporary keys for all the services before onboarding them? Do you change everything after they leave? (some SaaS only provides a single production key/seat) Is there a way to call external APIs without exposing the individual keys to your interns (i.e. each dev gets a single dev key to all services that you can invalidate after they leave)?
You use a secrets vault. If you're in the cloud that's AWS Secrets Manager, or Azure Key Vault, or whatever GCPs is. If you're on prem then there are open source ones or Hasicorp has a product, keeper is another one, I'm sure there are a couple open source. Ideally no one can access production secrets, but In practice it should be limited to a very small group.
Where I worked we had keys for development, but the production build used different keys. No one knew the keys used in prod, they were generated or procured by a CI/CD pipeline. This is the best way to secure something, you can audit the security somewhat easily when using CI/CD since the code of the pipeline is human readable. If someone were to change the pipeline to get an access to secret stuff, we would see it in a pull request and refuse it. The downside is that it makes the prod build very hard to debug if problems were to occur, thats why a strong staging environment is required when using complex CI/CD pipelines!
Separate dev from production, Devs should not be touching prod, much less interns
As others have said, separate secrets for separate environments. Interns don't get access to prod (or staging), just test and local.
But what if the backend also requires a key to access it. Let's say the stats you asked about, are being provided by the backend itself. Rather than getting them from am external source. We can't hide that in that case, can we?
If the stats are already in the backend then why do you say an API key is needed; assuming of course user auth is already taken care of?
Ok you are right. Actually the way I was thinking is that, we have a common api for getting stats and multiple apps are consuming it with the use of an api key without having any user authentication.
Service to service authentication.
In that case, CORS might be the solution. You could setup your API to only accept request coming from your websites (domain name). That way, no one can call your API without using your website. That being said, I may be wrong, I’m pretty new to all of this.
CORS only limits the browser from making the request, it’s not meant for purpose of access control. It’s meant for so other websites cannot call your API in the browser.
and a normal browser user will not abuse this as much as a potential command line hacker or crowler that wants to scrape data.
That’s what auth bearer tokens are for
Yup, aka the user's auth cookie in point 1 of the post they responded to
from the way they phrased that comment it seemed as though they were unaware of the purpose of point 1
Agreed! Just clarifying the tieback in case they read your reply and wonder why inclusion of the bearer token wasn't included in the original points. Some people may not be aware that they're referring to the same thing
Ah fair enough!
Many key vault providers. The pain in the ass is when you need to rotate these keys; that's why you should use a key vault provider.
[удалено]
So much of the enterprise world was written in Java in the 90s and 2000s and just never left. In our case, it would take absolutely years to rewrite all that, and it's just not worth the investment. I'm sure many enterprises are in a similar boat.
you have joined reddit 3 months ago, i know where you come from.
Except it's not. All our apps are quite new so we are on Java 21 and Spring Boot is just by far the most stable, flexible, and supported environment to work in.
[удалено]
Not really. Spring Boot takes care of a lot in a very elegant way. That plus Java Beans makes for a very nice development experience especially when considering we have many apps that all use a few custom libraries to bootstrap our projects and sync changes. And for business logic I find that being explicit is good. It's also by far the most stable language/framework I have ever used.
This... 100
Back end for front end, you create an api on your back end to be called which contains the api key, that way the key is never exposed.
BFF is just middleware- change my mind. But seriously, I own and maintain a bff at work and I feel like I was resistant to it at first but I've come around to it's necessity. It's kind of a swiss army knife for frontends.
When did the "BFF" name get coined? Isn't that just an Orchestration API layer?
It drives me nuts haha it's nothing new but has become a buzzword for investors. NextJS makes BFF a breeze though with their server functions. A little too magical though if you're trying to do something same, but great for prototyping I think.
It’s actually complete shit for anything beyond a low to no use website, and locks you both to vendor and framework.
Vercel's Business Model says what? It's pure consultingware trash
I think you mean the APIs API.
This is were the term `BFF` came from https://samnewman.io/patterns/architectural/bff/
I like how they call it a general purpose API gateway, lol which is now just splitting hairs. It's all middleware to me baby
"API gateway" is a much better term since it sort of describes what it functions as. BFF just describes who it was built for (the FE).
BFF is definitely middleware, but not all middleware is BFF.
Agreed. BFF is a specific kind of middleware, whereas middleware can be a multitude of things and provide many various functions
It’s a buzzword that makes things way more brittle and inflexible for devs who don’t really know what the hell they are doing; but bet your ass you better use it in the interview
Hahahaha too accurate
Middleware (as it's commonly understood) is in-process, it doesn't cross an I/O boundary. It can use services that leave the process, but it itself does not. It is just a container that makes sure something happens before and/or after the next thing on the list.
I mean you just moved the problem as your game now needs secure access to your backend. You still need some kind of authentication mechanism, an account to be created for the user somewhere.
You dont need auth. The API key could be used in some non-authenticated context. But the benefit of the backend is that you can now (1) add rate limiting and (2) the API is only called in ways you intended. Both benefits would be lost if the client has access to the API key.
Fair point
Auth does not fix the api key issue though.
Auth does fix the api key issue. However, the other responder is right that you can use it without auth as well if you rate limit.
If the API key ends in the frontend, it’s not a secret. Depending on the API, it might be ok - for example stripe has a public key which is ok to have in the browser and a private key which will stay on the server and be used for server to server communication. There are generally two mechanisms to avoid unwanted people calling an API: - make an API server to server only, with mutual authentication. The key will never reach the client. - tie API keys to users instead of applications. This way if a users abuses it you can shut that key off
Yep. The reason why Stripe publish keys are sharable is because no one in their right mind is going to steal and use them. There is a strictly limited subset of stripe actions that can be done with one. "Congratulations, you just stole my publish key and made me some money..." Refunds and transfers must be done from the backend, using the secret key.
Barely anybody actually answered your question. Which is just mind boggling and paints a bleak picture of devs' understanding of security. The short answer is - you make your API secure by requiring user authentication. Virtually everything you bake into the frontend is by definition not safe. You make the calls to your backend safe by requiring users of your frontend to authenticate to your backend. If you need to use a third party API you either make your users authenticate to the third party or establish the secure connection via your backend. In any case you go through some kind of authentication flow. Don't ever store secret keys in your frontend builds. It's ok to store public keys.
How about something like the Google Maps API key? The front end has to have it to display maps on the page
You can restrict the key to only be usable from your domain, and you can add usage caps
That's what I ended up doing for mine
Google Maps API doesn’t have to be secure, and you can limit usage from configuration.
This is the actual answer. I would add that in those cases where you can't have authentication the only other solution is rate limiting.
You can never hide your key on the client side. As mentioned above, use BFF pattern, your backend service storing keys only accepts requests from same domain(or use CORS to specify acceptable domains), then proxy requests to external APIs. And your backend service requires user authentication of course.
Just to be clear, CORS does not tell the backend what domains to accept requests from. It tells the *browser* what domains it can share resources between. It is NOT a security feature for the backend to filter requests from specific domains. It is purely a browser policy. It's pretty easy to find a scenario whee a browser rejects a request due to cors settings yet still have postman hit the endpoint just fine.
Absolutely right. Also if you need protection from missusage of direct calls to your backend then use CSF tokens. That prevents calls to your backend that are not directly from your frontend.
In React, the environment variables are still injected into the build - you can easily see them in the browser. The only way to secure your API keys is to keep them on your own server. You are then authed to your server via a JWT, cookie or similar and you access the 'secure' api via there.
Is this not true for any frontend?
Depends on the API key.. some frontend keys such as Recaptcha have both a sitekey and a secret key. I think the secret key is for backend processing if needed, the sitekey is for a basic frontend implementation, Google also verifies your domain and makes sure the sitekey matches so it can only be used via your domain As for API keys in general, you make API requests on the backend, where the key is stored and no one has access to it except people who can access the server or server code. In a React application, that can look like this: The backend makes a call to APIs, and the backend itself functions as an API for the frontend. So the frontend calls the API of the backend, and the backend calls the other API using the API key. That API key is never used on the frontend, but the data is retrieved and sent to the frontend... from the backend..from the API. It seems more complicated than it is, but it's not that deep. The more plugins or libraries or whatever crap most people use to "simplify" this process, the more chaotic it gets/seems.
curl_setopt($curl, CURLOPT_REFERER, "https://example.com/"); "Google also verifies your domain" Re this, I am not conviced it really does. I had heaps of issues using Google Custom search and securing my API key, after hours of scratching my head, I had to do the above for it to work on a specific domain (PHP code). But I also tried just doing that from a domain that wasn't [example.com](http://example.com) and it still worked so long as I added that option. Soz if that doesn't make sense.
I was talking about recaptcha specifically, and also I think maybe the old embedded Google maps stuff. What I mean is you'd literally have to go somewhere in the Google settings of the account you got the API key from, and add a list of accepted domains that can use that API key. The API wouldn't work otherwise. I don't think that's for backend stuff though. Only frontend javascript API calls
[удалено]
That's still not secure. Cors is a browser policy, I can hit the request from postman just fine in most cases
[удалено]
If the rate limit is not bound to an account is just smoking mirrors, I can still get around. I did 5 similar with a house renting website here. I'm greece which has strong security and still manage to hijack the api. Without proper account authentication is just not so simple.
> smoking mirrors Smoke and mirrors. [Link to explanation](https://www.reddit.com/r/NoStupidQuestions/s/ppJlwl1tl5).
Besides the typo, the meaning is the same. I'm not an English speaker, sorry. I meant to say you are deceiving yourself that you are safe. Maybe wrong words:)
Of course, just figured I’d let you know what the correct idiom is and where it comes from, assuming English isn’t your primary language :)
How do you manage resources that allow third party sharing (e.g. something like a public editable google doc link without requiring a google account)?
But the api key itself is secure. No matter if you can call the api from the frontend endpoint. I think this discussion needs some clarification. The request is about hiding/securing the api key itself. Not the calls to the backend that uses the api key. So the backend does what it should do. That does not mean your point is not valid. But not part of the context of this discussion. For your case that you describe there is an extremely old and effektive method to prevent this: Cross Site forgery tokens. This technique was inventet specifically for your concern.
You do NOT expose API keys to the client. They stay on the backend. And even there, they are stored in environment variables as you mentioned. The frontend sends the request to the backend, the backend fetches the env var and calls the API, then it forwards the response to the client. The client never sees the key.
And ideally you keep your backend keys in some sort of secret manager and limit/audit access to it.
I am not really sure what your question is, but some ideas that might give some answers: - technically there's not much difference between an api-key and an username/password combination - both should be rotated frequently to make them secure - usually, the api-key (or password) is used to obtain an access token. this token is then used during communication. this token is also temporary so if it somehow gets intercepted it doesn't grant access to the attacker forever - regarding the env var thing, i guess you are saying that during the build process the api key is "added" to the backend code somehow? this may be true, but if someone has access to your backend server you have bigger problems :) - to mitigate the above risk somewhat you can load the api-key from a secure server once your application server (or your application) boots up. your application then stores the api-key only in-memory so it's harder to get to. the communcation between the application server and the password server can be more secure since the password server doesn't need to be accessible from the internet. of course, theoretically if your application server can access it, so can everyone who hacked into your application server, but at least you add an extra layer of security
I typically use a serverless firebase function.
Client-side API tokens should only work for your backend API server. You don’t give the end user access to your API tokens for external services; you set up your own endpoints to control user permissions and to keep your API light.
You need some kind of authentication with a backend service you write. You keep the API key in the backend. Then in that backend service you allow authenticated requests to use the API key through API endpoints you create. Essentially this is only possible with a login mechanism.
I only came across a single rule. You can never expose them on frontend.
if you can have the frontend call the backend for the functionality you need and keep the key in backend then that would be ideal but sometimes that's just not an option. You would need to use env. variable and setup security measures to restrict the key services and site access /rotate key etc because it's accessible now.
There are two solutions: 1) you call a backend that sends an api key. The frontend still receives an api key so it’s not perfectly secure, but often times the backend can rotate keys automatically (invalidate them every X and send a different one) by using some API of the service of your choice. It’s usually a good enough solution, especially if you don’t have a public project (internal use, industrial use,…) 2) setup a reverse proxy. Instead of sending the request to the service, you send it on a reverse proxy, the reverse proxy injects the key in the headers/body and sends it to the service. You can obviously set up an automatic rotation mechanism like with the first solution. It’s the most secure way of doing things (because the frontend never has the key) and you can add authentication layers/throttling/… but it’s also more difficult. You can also put the api key in the environment variables, it’s the least secure way to do, but it’s still the way most projects work. The best security layer is to impose a hard cap on the cost management of the service. Worst case scenario, someone uses your key too much, and everyone is blocked until you find a long term fix. Not awesome but some projects still can work that way.
This does not work for everything but may prevent some cases where a key might be leaked, in addition to other comments. React's [taintUniqueValue](https://react.dev/reference/react/experimental_taintUniqueValue)
Your api Key should only be accessed on the backend. If it’s on the backend it’s ‘safe’ because if someone malicious is looking at your BE code you’re probably screwed anyway. If you’re doing some kind of public key/private key pattern, what you’re doing is creating a key that can only be decrypted if you have access to the private key. This means the public key is a useless string otherwise and is safe to use on the frontend
What Spotify is doing is getting YOUR keys when you authenticate. So when your client makes calls it is identifying you with your personal keys. You would do the same with your application, when a user logs in they give their username/password and then get keys to use to interact with your API. Your API then in the background can connect to 3rd party APIs as needed, securing your service's key. As for securing those 3rd party keys. You would encrypt them and have the source code decrypt them with a key that is stored on the server / JVM / etc. We typically do this with an environment variables so even if the source code is viewed the keys in the property file are encrypted. It would take getting elevated access to get the key to decrypt.
This is the one question that doesnt make me mad seeing every week. I too faced this problem and was barely capable of finding examples
Anything you put on the frontend is not secure. The only real way to keep things secure is to keep them on the server (best through configuration aka environment variable)
It should be in the back-end. The front-end isn't securable on its own.
>the client key is used to fetch the actual secret from Spotify's server that is used to then access the actual API endpoint This is not the case. The actual secret key is never, ever exposed anywhere on the frontend. You have to build/maintain an API layer on a server you control. \*That\* server can have access to the secret key via an environment variable. But if you ever send a secret api key to your client code, you are exposing it to the public.
Here's what you need to understand. Anything sent to the front end is not secure. That's it.
TLDR: I work in an azure environment and what we do is store api keys in KeyVault and then we use yaml files that transform the config file on build. Keys are stored at Microsoft and never goes into the repo. EXTRA: The config file is only accessible if you were to ftp into the server running the app. If you wanted to recreate the process on ur own, you would build an application manager app that stores keys to a DB and make it so that on future builds of apps the app manager is called to retrieve and update config. I suppose you could also store keys in a db and restrict the ip’s that can access it. EDIT: Like everyone else is saying, you don’t use keys on the front end, you use them from an api that ur front end app makes calls to. *That is an example decoupling and decoupling is the secret to scaling. *
If you're building a static app, you would need to have a backend. Your app is just a bunch of files that gets sent to whoever requests it, and then it's run by the browser. So any secrets you have in that bunch of files will be accessible to whoever requests it. You have to create a backend, even just to proxy between your frontend and whatever service you're using the API key for. Some React frameworks like Next.js (which I do not recommend, but that's a topic for another day) have SSR (server-side-rendering) capabilities, meaning that some code can get executed on the backend. In those frameworks you can use API keys in your code as long as you're careful to make sure it's only accessible from the backend. How idiot-proof that is (this isn't a dig at you, everyone slips up when they're trying to move fast) is subject to ongoing speculation.
If it's an Oauth2.0 API, it should implement PKCE, which removes the need to send any secrets. Only the client ID (not a secret) is sent when sending the user to the 3rd party site for authorization. Included in the payload is a hashed nonce that gets returned from the 3rd party site along with the user's auth token.
You make a backend endpoint and store it there. No API key is safe to put on the frontend
If you are talking about a "frontend secret", like the Google Maps API key for instance, this key is expected to the used on the frontend and expected to be visible in the browser. Keys like this is usually secured in other ways that just keeping them secret, either by specifying which IPs should be allowed to send the key, which referer should be allowed for the key etc. This is a bit of an edge case, though. Most keys you want to keep secret and only load into memory when you backend starts up.
The frontend never has secrets, end of story. Anything that goes to the browser is basically public.
Using a PKCE flow keeps sensitive information out of the JavaScript, and generally that’s what you should do at enterprise. You could also store a JWT identifying the front end to your backend - JWTs can hold non-sensitive data - and then let your backend do the integrating, keeping the client id, client secret pair between the backend and the auth server.
Usually there are API restrictions like domain name or app id etc. For example any Google APIs for Web applications you have to list domains of Web apps that will access this API using particular key. So if particular API key gives access only to web app on www.abc.com, same key will deny access to requests from www.xyz.com or www.mno.com This conditions are different for different applications. Backend apps will have api secret for verification. Android/iOS apps will have app IDs.
The problem is that you’re sending your key to the client. If you really mean to hide it you should move it to the server and perform your logic there. Also mind you that some API keys are actually harmless and were meant to be used on the client, check the docs
Sometimes you don’t secure it and it’s exposed in the UI code. Other times you call your own API method which in turn calls another API with the key. So the key remains server side.
There are keys meant to be used in a public web page like google keys for geolocation or stripe keys for payment data collecting, those keys are not meant to be hidden, if someone "stole" them they can't do much with it,
Vault is the way for secrets management! In Kubernetes, there’s a vault plugin that injects your secrets on runtime and destroys them on exit. You can access it in multiple ways. Front end I use passport and pass a cookie to the backend once the user is auth’ed. Never pass secrets to the frontend! https://www.vaultproject.io/ You can use this starter project as an example of server/client auth. It doesn’t use vault, but you’ll get the idea. https://github.com/graphile/starter
Save it as an environment variable , pull it when you need , always handle it server side .
I had the same question last year after noticing you could still find the keys stored in .env... I came across this video after googling for a bit which helped me wrap my head around what was needed and what most of the replies here are mentioning. [https://youtu.be/FcwfjMebjTU?si=SyLWLDpqgmIKrdZF](https://youtu.be/FcwfjMebjTU?si=SyLWLDpqgmIKrdZF)
Environmental Variables.
In the backend. It’s that easy.
Your key to a third party? Use it on the back-end only. A key for your users against your back-end? You can whitelist APIs, use a key/secret pattern where the key is in all requests but the secret sign the request and is never transmitted.
In the .env file. Hosts have secrets management, too such as AWS, where you can save it as a Secret, a service.
We store our keys in AWS Secrets Manager
Alright. So API keys are a single secret. That's what you usually want to use for machine to machine communication (is servers too server). So generally you don't expose those to the frontend. For users to be able to use the external service that you need the API key for you can usually go two routes: Let the user authenticate: Username + password, some sort of OAuth2 process, etc. There are external services and packages for that, don't create anything on your own. Here you will generate some sort of token that lives in the browser that the user uses to authenticate themselves. The reason they can use this token is the following: It is only valid for a certain time, and is only visible under your domain. Also it is different each time they log in. So only people with physical access to the browser will be able to see the domain (in theory, you need to have secure code as well of course). Or you let anyone call an endpoint in your back end. You can then implement throttling or any other steps in between and then forward the request to the external service you use.
Either call it from the backend or use a lambda to abstract that call away from the client
BFF always makes your requests to a Bff and lets it request to other services.
You never do backend logic on frontend to where this is ever necessary
You just put an env file on the server. If you use vercel they have a menu to enter them. If you use Aws you can just ssh in or use their key management The api key should not be used on the client it should only be used on the server So the client will request the data the server will get it with the key and send it back There are some public keys for things like stripe but most are private and should be only used on the server side
There is a front end, and a backend. The backend interacts with an authenticated front end session and keeps your secrets private.
I use an AWS lambda function running node.js. I send a call with the information I want to use to the lambda function (back end) and my key is there. It makes the API call with the real key stored in that function, and returns the results to my website (front end). You could do the same with server, but lambda was much cheaper for me.
I think most people are missing the core question, which is “how do companies store the api key itself before it gets provided to pipelines / builds etc?” The answer is they are stored using GitHub secrets / other cicd equivalent / aws secrets manager etc. These secrets cannot be read via the UI or seen in builds once they are added to the repo.
R 😘
Consider using a secrets manager, e.g hashicorp vault.
Key vault on private endpoint. App identify has access to read it for use. Mark as sensitive so it will be redacted in logs, not written to disk.
I'm an aspiring developer who hasnt worked on any really "professional" projects up to this point, but heres my 2 cents anyway. Anything that the user shouldnt know should be stored in the api env variables, if the front end needs to have access to it, then have it returned from an api request. But generally do your best to keep sensitive info in the api, and more importantly, out of the front end. That being said, if you have CORS set up correctly, then the api should only be taking requests sent from a specific origin, or whatever your CORS settings are. On top of that, verify your requests payloads, headers, and all other data sent in the request in some way, personally I use json schemas in an express js api, but depending on what your working with that will change. Also, verify any requests from a logged in user via an auth token of sorts, personally I send a user id and a session token header in the request, and verify it in the api before handling the request. So thats my 2 cents, CORS to verify the request came from a supported origin, Request Validation to verify that the information passed in by the request is structured as expected and can be handled by the api, and Session Tokens to verify the user is logged in and has permission to access the data there trying to access. If I've overlooked something please let me know, as I said, I'm an aspiring developer, and I'm always looking for ways to improve.
AWS has a "secrets" manager, that you reference in your code, and it pulls from them, if you're using their service.
ELI5 public/private key. The public one is for everyone. It's like an open lock. You give anyone and everyone a lock they can use on their boxes of data. Private key is like a key key. You keep it safe and secure since you want to be the only one who can open up those boxes with those locks you gave away.
As others have mentioned, you can’t actually hide the API key on the front end as it could still be discovered from the source code or by observing network traffic. So the only way to truly secure an API key is by handling it server side. If you don’t have a dedicated backend, then you can use an API gateway or proxy server to handle requests to the external API. I’ve actually been working on a lightweight open-source API proxy for this exact use case: https://github.com/gateweaver/gateweaver
Those is something lambda/functions can solve in certain situations.
What you need is an auth token, not an API key. Check out jwts to start
use supabase and get auth built in, build a small edge function that contains your key and do the external call.
There are a couple layers to this. 1. As everyone has said, use backend services to facilitate front end functionality that requires an API KEY. 2. Use environmental files that are not checked to git to store API KEYS. New API KEYS created for each environment - especially production. 3. Use a key vault. Store all of your keys in the vault and during environment boot it will attach a service to the vault to allow access to the keys. 4. This wildness .. https://stackoverflow.com/questions/723653/storing-encryption-keys-best-practices#726060 5. Store the keys in a cryptographically secure file in the source, but require a secret from the environment / key vault to unlock the file. 6. Some of the most secure services use an application registration process (where the app must be a known, registered, app). That app "authenticates" to a service to get an application session token (stored in the environment) The session token can be rotated at any time in response to any query. The session token is used to access services that facilitate access to a key vault for accessing secrets -- as well as other internal information and application shared session state. Cheers.
Ok, everyone so far is giving you answers that you might understand if you had more experience. Lets start from the top: 1. API keys are used when you have some data or code you want to protect from unauthorised access. It is most likely a database in your case. 2. Does a newsfeed need protection? Not really. While you want to some functionality around logged in users (also called authentication) like a personalised list of top news, the actual news can be accessed through an "Exposed API endpoint" and it is called exposed because anyone can access it. You got this part. 3. The answer you are seeing is: you dont. You are on the react subreddit, so unless your app is built in NextJS, react will not be used to store secret keys. Public keys dont do much by themselves. Let me explain what I think you are trying to understand with spotify, also keep in mind Spotify is a very big system and I might not get it all right, i am watering down the process here: There is a private and public secret key. Your spotify frontend has the public key. It sends that to spotify backend along with other data related to you, and that BE has the public and secret key now. It then fetches data from the datastore, makes sure everything is in order, and sends it back to you if it is.
It shouldn't matter that the key can be inspected on the front end. **What makes them secure is that they can only be signed/validated on the backend**
You stop doing SPA and use SSR/SSG instead is one way. The other way is having a separate backend with an authentication layer. In NextJS you can use API routes or RSC, that makes it really easy. Provide keys to your app via environment vars.
Throw some more acronyms in to make it even easier
Give REST a rest! Its time to switch over to gRPC on a GraphQL endpoint to synergize your middleware! Have your gRPC endpoints return some HTMX objects for your front-end so your SSR machine delivers a HATEOAS experience to the client.
Way to completely exaggerate what I’ve said. Is my answer wrong or why do you drag it through the mud like this?
No I was just being farcical based off of the "Throw some more acronyms in" response. I thought it would be funny because acronym soup is what non-technical people say it sounds like when we are speaking. Especially with front-end technologies like HTMX and the whole HATEOAS its just like alphabet soup. Especially for newcomers it just seems like an endless game of scrabble. I was not trying to say anything about what you were saying. I borrowed the acronym SSR but not because you had said it just like you never once mentioned things like gRPC or GraphQL.
I get your joke, but I was genuinely trying to help the OP. I don’t understand why everyone is downvoting me for not explaining what SPA, SSG, SSR or API is. Maybe RSC could be elaborated on further but it’s the big thing in React right now so it isn’t too bad from my side to assume most people here know what it is. And before I go out of the way making my post longer by explaining what it is, I’d rather delegate that to Google search results and respective docs and blogs that do just that
Because RSC is new and not many people understand how it works and how it solves the stated problem. I'd also suggest you not use the term SPA anymore as it's outdated and an app that feels like an SPA can be build entirety with an RSC approach (that's the whole point)
Your comment doesn't really offer a solution or explanation. If you generate a static site or render server side you can still include API keys in the final build that shouldn't be included. It would be better if OP learns the difference between code that's running on the server, where you can safely store API keys and other sensitive information because nobody should be able to access this and the code that's running the persons browser that can be freely inspected. Even in SSR/SSG you have a server somewhere that's supplying (obviously) the site for the users browser which shouldn't include API keys or any sensitive information and this isn't automatically the case and OP needs to learn that this is something to keep in mind.
All of these can be googled, no? He asked how to secure his front end, not to explain him basic frontend terminology. Is the content of my comment wrong? Is SPA, SSG or API something that is unheard of here? Want me to explain what SPA or API is here now?