I’ll get to work on that :)

@@JamesQQuick YAY!! Thank you!

I used a server side rendered http only secure cookie over SSL (HTTPS) connections. With each request from a browser, the cookie is sent along with encoded information that is bound to user bound session data that automatically invalidates itself without user interaction. Here's the full story, it's REALLY long: In this cookie I store information that is encoded/encrypted by the server so its hard for normal people to read it (security by obscurity step). I bind user information to the cookie, so that the value cannot be used to impersonate another user (security by isolation). A session is instantiated by the server with an guaranteed unused session id. The session contains one encryption key, and one validation key. The validation key is part of the encrypted payload. The session id is also stored in the cookie, but not encrypted and serves as a way to bind a user and session together using a cookie. Each time the cookie is sent to the server, it can quickly lookup the associated session, decrypt the payload using the random generated encryption key, and validate the cookie stored validation key with the session stored validation key. If I'm sure I'm only going to use short living sessions, I also encode IP information into the session and compare it when the cookie is send. If any of the data does not match up, the cookie is tampered with and the session and cookie van be invalidated. This is a simple way to force The Union Router (TOR) users to login again when their IP changed without them realizing, and thus preventing compromising their session. It also prevents networking traffic inside a user network from being rerouted to a different internet exit point, as the user device will access the server with a new IP by then. The session automatically invalidates after some time of no activity. If the cookie is using a session that no longer exists, the server will try to recover it from archiving, or create a new session and update the cookie. It can be a heavy feature to browse through a database full of archived session data.This process is intentionally made relatively slow but steady with a limited resource pool, to prevent DDOS from bringing this feature down. Its very possible the server denies creating a new session unless the user supplies login credentials again or enough resources become available for processing. The bound information also includes a date of expiration, so that if a cookie's expiration date is tampered with, we can invalidate it and block user access. PS: I often also add a random generated string to a long-term stored user account, and use that code to encode random values. This makes it harder to further analyze random generated patterns unless you know about the encoding happening And even then you have to break into the server-side storage to get the user-stored random string. This is how I do it, may sound convoluted but every step is crafted in a way to prevent any form of corruption on server side (for example, due the server being DDOS'ed) with minimal performance hit, but with maximum security I could envision. The server uses atomic operations to operate on all the values, which allows the greatest guarantee to prevent corruption by computer instructions going bad. I thought of different methods such as using no sessions, using simpler data, not using as much random strings but I found ways to corrupt the system without them. Besides, using sessions allows me to store dynamic session data and check permissions on the server side easily, which is useful for having stateful applications such as frontend editors with caching and stream support. I wanted to be sure that people could relatively stream data safely and that the server could process it fully in parallel and asynchronously, sacrificing a fraction of speed for stability and security. This approach is something I concocted that can be made to work in a distributed computation network such as server parks using only simple synchronization techniques (like using TCP and just send over formatted data). I use sessions to store information about how the user data is distributed over the system. To pull off stealing someone's session with this approach, you'll have to do a man in the middle attack or hijack the internet exit point, hack into the browser of a user to get session bound data. Fabricating a cookie using random data is out of the question, because if any of the stored cookie data does not match up with the session, it is not deemed valid. At this point, the attack vector is people who can directly access your computer or people who have compromised browsers. There's nothing you can do against that. It may not be the answer you're looking for but I hope it was insightful nonetheless. Feel free to criticize my approach. I'm not a security specialist. Definitely tell me if you have more secure methods if you are a specialist!

@@msc8382 WOW, That was like reading a medium article. Thank you for taking the time to write this out. The IP address encoding you do along with the sent cookie is genius, i hadnt thought of that. especially for users on vpns or TOR. Up to now i had just be authing with credentials and a jwt cookie but without any of the extra data. This definitely gave me some ideas. will be saving this in my notes.

Most viewers would be interested on a proxy backend API endpoint demo with load limits. We don't need a production stable app, just an app that is safe regarding exposing our API key (mostly to avoid high bills).

That’s a great idea. Thanks for the feedback!

Up

Interesting take!

@@JamesQQuick I’m an optimist, if nothing else 😂

@@everyhandletaken Me too. You were absolutely right about encrypted and protected layer for this kind of authentication via API's. There must be a way to do this without exposing the secrets to the whole internet. I mean we are trying to reach Mars. Have a good time and thanks for your answer. I back this 100%.

Ah so cool! Glad it helped :)

Glad you enjoyed it. For the “accidentally pushed to GitHub” there’s not really a way to completely remove. You need to regenerate a new key. I’ll work on the extra video too :)

@@JamesQQuick Oh wow ok gotcha!! Thank you!

Came to see if someone had mentioned exactly that tip - possibly also *.env as well, as I have seen local.env, for example (not sure if it was with dotenv package, or something else)

Yep I do the same except when I have a .env.example file that I want to leave in for other users to get started

Haha Brad nailed it!

Then do : .env* !.env.local

It's a common thing to leave a .env.example file with the description of the vars on it. If you do that you won't be able to have that file.

CSRF Tokens can't defend against this. You can have a workflow using Postman/Insomnia/HttpClient to call the csrf token endpoint, extract the token from the response, inject to the next request. Security is a real challenge for frontend development.

CSRF token should only be provided to authenticated and authorized users who have a valid session. @@Subs-rj3zk

Thank you!

Looking into it :)

Hello DasDune Technologies. Thanks for the tip. Appreciate it. I will check that out for sure. Have a good time.

Yesss. :)

Thanks for this question, Daniel. This would be interesting to know for me too.

but then that function can be invoked by anyone. :D how do you protect that. Anything that has to be client side can simply not be hidden.

@@sayamqazi I meant the key will be hidden if you use serverless function, it does not mean you can prevent people from using it. What exactly do you mean by protection? What are you trying to keep hidden? A serverless function already hides that for you.

@@Notoriousjunior374 Oh got it. But what's the point of hiding key. if the attacker can just move his goal post now.

@@sayamqazi These answers can easily be found on the internet. It’s your choice whether or not you want to expose to the client. You can implement any features on your end. For example you may have an api key that has access to your crypto wallet and that you can perform trades with it. You’re planning to ask your fans to buy any shit coins for you but of course you’ll want to have some kind of limit that your fans will not be able to do. Hide that key from them and do write some custom functions to do whatever you want. It’s really that simple.

It sucks though cause how do you use a api key that is stored on vercel client side with out it being exposed to the client

So people won’t see the key

Your key would not be exposed since you did not upload it to the internet, but accordingly your app also could not read the key as it cannot access .env.

You can pass env: ./env and pass in .env file for environment variables

Not entirely sure I understand, but you can pass an env file to Docker container using arguments when you run the container, or in a docker-compose file & the env file is picked up from outside of the container. Not sure if this could be a remote path, but can be anywhere on the filesystem of the Docker host. I may be misunderstanding though, sorry.

Haha I’ll add him back!

It certainly does seem like a lot. The simple fact is if you expose your keys, they can be used by anyone to spam your content so you certainly don't want that espceially for paid products. To the question of, couldn't users spam your content anyways...yes, they could, but at least that way, they don't have direct access to the key AND you can throttle or even remove a user. You can also put general throttling logic in your application to help prevent it to start.

Midnight synth :)

Yes on the DEMO!

Haha totally understandable. The main thing is that those files get created one bit at a time. That’s whT comes with experience is being able to break down something big into smaller components

Well you also wouldn't include private credentials in a frontend vanilla JavaScript site

Yep that’s right

encrypted over https...

@@JamesQQuick it's in the url I can see. Any other user can see it too, duh =)

A problem with public-facing web pages.

** I think Supabase might do this also...?

All I know about Supabase is it does not have everything Firebase has yet.

The whole point is that you don't include the API key on the frontend because of that...

Hi Pavel. Thank you for your answer. I'm relatively new in this field. I started learning to code earlier this year, but I care a lot about security and I want to learn how to do things the right way. If I understand you right, then a good API specification is using API keys that are bound to a certain host and can only be used on this host but not from any other than this. This seems to make perfectly sense for me. You advise that we should better not use any API's that allow the use of API keys from a random host. Did I get this right? At this point I'm not dealing with securing one of my own applications, because I have not coded one. All I want to do now, is learning to consume API's with JavaScript's fetch or with curl. After seeing this video I almost think that there is no way to do that in a very secure way. To be honest, I will look for API's to learn with that do exactly what you described here. I want to find some good examples that use host bound API's. Thanks again and have a good time.