The worst possible advice for API key management
Description
This is an anime meme featuring the character Aqua from the series 'KonoSuba'. She is a blue-haired girl shown winking and confidently pointing her finger upwards, as if offering a clever tip. The overlaid white text, in a classic meme font, reads: 'YOU DON'T NEED ENVIRONMENT VARIABLES' at the top, and 'IF YOU USE YOUR API KEY IN THE FRONT END' at the bottom. The humor is derived from the dangerously terrible advice being presented with cheerful confidence. Storing API keys on the client-side (frontend) is a massive security vulnerability, as anyone can view the page source, steal the key, and abuse the associated service. The character Aqua is famously incompetent and foolish, so her image is perfectly suited for delivering this piece of catastrophic 'wisdom,' which resonates with experienced developers who have seen this mistake made by juniors
Comments
50Comment deleted
Sure, put the API key in the frontend. It's the fastest way to get your cloud provider to personally call you to ask why you're trying to mine bitcoin on their entire server fleet
Because nothing screams zero-trust architecture like committing your production Stripe key right next to App.jsx
The fastest way to turn your API rate limits into a distributed denial-of-wallet attack is to let Reddit find your keys in the minified bundle - at least the crypto miners will thank you for the free compute credits
Ah yes, the classic 'security through client-side obscurity' approach - because nothing says 'enterprise-grade architecture' like letting every script kiddie with F12 access your production API keys. Bonus points if you've also committed them to a public GitHub repo with 47 forks, ensuring your credentials have better distribution than most CDNs. At least when the bill for 10,000 unauthorized API calls arrives, you'll have a great story for your post-mortem about why environment variables and backend proxy patterns exist
Ship the key with the bundle; congrats - your CDN is now a planet-scale secret manager (aka NEXT_PUBLIC means EVERY_PUBLIC)
Frontend API keys: because nothing scales like accidentally funding your competitor's entire inference budget via public GitHub
Putting the API key in the browser isn’t configuration - it’s open-sourcing your credentials with minification; keep PagerDuty warmed up
Really I hate (as DevOps) see how a lot of devs put these ENV vars even on the repository because need a "static build" of the website and "nobody will search these keys inside my -obfuscated- javascript" 🔥 Comment deleted
Network Tab in Devtools:🗿 Comment deleted
In most cases you can't hide it Comment deleted
So it doesn’t matter much Comment deleted
also there are some frontenders which hate server actions in next.js, because you cannot make ssg(static build), thats also weird af, they dont understand client server concept Comment deleted
Me right there. Have never built an ssr app and have no interest in making one. Only made apis with node, then jumped into react csr (ssg at most) and never moved forward. Is it really worth it bloating server with frontend code (and making your team required to keep in mind 2 codebases envs), taking care of all possible hydration errors, having 2 separate state managers, one on the server and one for interactive client side, and finally simply bringing more libs to your project (react renderer and state managers at min, but most probably remix or next with hella deps in it) ? And you get what? You lose cdn benefits, unless you use special pre fetch services (good luck with cache invalidation tho). The always mentioned CEO DISCOVERY with pre-rendered html and custom og tags for each page? This is solvable by ssg unless you own a huge platform with several k+ of dynamic pages, which is a completely different story with own set of problems. Next cloud hosting vendor lock is also ridiculous. I don't get it how mixing front and back is ever a good decision for single dev and up to mid size company. It only might make sence if you are a big tech with goals and problems far beyond those we all usually have. Change my mind 🤢 Comment deleted
I used to have a website on nextjs with 100k+ pages (not far from 1M with all translations) Got rid of vercel in the first month and moved to dedicated server. One of key basic requirement there is a high single-thread performance and 1TB+ for data on nvme. Worked like a charm Comment deleted
I mentioned website https://t.me/devs_chat/148524 Sooo, I managed to almost fully resurrect it It's actually not ALL pages that were initially there, plus blog-related images are lost (kinda forever, except for previews for links in telegram, lol) But regarding amount of pages, you can get an idea about it from main sitemap which is used solely to refer to other sitemaps 🌚 https://new-world.guide/s/en-us/sitemap.xml p.s. it's actually well over 1M pages, there's just a lot of "service" pages that are excluded from indexing, eg on hover tooltips Comment deleted
I made the mistake of opening one of those sitemaps on mobile 😭 Comment deleted
Those are only for English domain tho 🌚 Comment deleted
Talking about just cool things, that will work well on mobile too, you can check 3D models extracted form game’s bundle https://new-world.guide/db/item/mediumhead_so_boss600_mutt5 Comment deleted
ye that loads fast 👌 what's the stack here? also bare next (how come we call next a bare setup, but whatever...) or some starter like t3? And what have you used for localized routing? I have done that in spa with react router and it was NOT fun (reflecting ui lang switch in url and vice-versa with no reload) Comment deleted
> And what have you used for localized routing next-translate It was all languages on the same website before but hey, it's so much more fun with dedicated seaparate domain for every language! Comment deleted
132G .next And this build/page caching have been running just for 7 hours 😂 Comment deleted
We are currently planning the stack for frontend at the startup, and a guy proposed Next because it was "fast" when he made a pet project using it. Unfortunately, no one has experience with it and we are used to csr react + Nest on backend (which will be replaced by whatever Next uses, I assume). So we'll probably stick with csr and try Next in some Theo/Remix/etc. wrapper for separate sections where indexing would be nice to have ☕️ Comment deleted
I didn't really get meaning of "fast" for next in that context Comment deleted
idk too, first load I guess Comment deleted
First load solely depends on how you pre-built page + what's your UI architecture, like, next's purpose is really different Comment deleted
What's the goal? Comment deleted
mainly an interactive app, additionally the blog and whatever Comment deleted
For now it's: vite, react-query, react-router, jotai, biome, shadcn + sass Last one is funny, we have no clue how to use tailwind, but need those components Comment deleted
lol you don’t even have to de obfuscate you can just check api request for headers Comment deleted
Naaaahhhh why yall wanna make me a weeb??! Comment deleted
i should make a crawler that detects common web frameworks, loads the page in selenium, clicks all buttons on the page, then observes network requests for free authentication headers Comment deleted
Question: If you have a php script in cpanel, is it possible to read it's contents? Since it's url will only run it and can only show the scripts output... Right? Comment deleted
Well yes php executes server side. Unless you didn't set up php it should not leave the server. But if there is a logic or sanitization error on your implementation and you leak the file as a resource then it could be available too Comment deleted
Poorly configured web servers can be made to leak PHP script contents Comment deleted
Your first mistake is tho choosing php /s Comment deleted
Well yes, everyone knows you should write your website code in C99 Comment deleted
No. C# Comment deleted
No sarcasm here Comment deleted
Assembly is the only way! Comment deleted
Brainfuck or gtfo Comment deleted
Which one? :) Comment deleted
x86 / x86-64, Intel syntax Comment deleted
ah, too bad I've got it self-hosted on my solar-powered rpi4b :) Comment deleted
You don't need a brain if you leave your API keys in frontend Comment deleted
I did try this once I can't stop laughing at myself Comment deleted
хочу розавую единарожку😅 Comment deleted
Please, only use English for chatting 🙏 Comment deleted
I want a pink unicorn😅 Comment deleted
What does it have to do with API Keys on fe though? 😄 Comment deleted
I don’t know, so fuck did you want to?😄 Comment deleted