Very good, you covered all the required bases. What you however should arguable always do, is put your APIs behind an API gateway (or reverse proxy) and let that throttle the responses. That way you don’t need to load your services with throttling code, which is not their primary function. You can declaratively manage the rates on a centralized point based on policies ranging from roles to ip networks. As you will not want to limit API speeds from your back office for example. Also an API gateway (reverse proxy) can be a termination point for TLS, although you should have imo always TLS also on your API as long as you automatically manage the certificates so that they are automatically refreshed when it’s time. And also your API should authenticate itself with service principle or manage identity. And in our industries we even do not allow interpreted languages because we want to be able to sign the runtime that is statically linked so nobody can sneakily change out the service or a library and exfiltrate data. Our custom API gateway actually checks the signature of the binary everything the API refreshes its access token or requests an access token. If it doesn’t match with what we told the api gateway it should be it won’t start. And those signatures we put in a keyvault that the API gateway may read.
@rembautimes880810 ай бұрын
@CallousCoder very good suggestion and value add to this excellent content . Hope there are more videos on this
@Casal0x Жыл бұрын
I great that you mention it, Errors is something no one makes tutorials or mention as something important.
@kiddasneve1677 Жыл бұрын
i also like to use an application token to my back-end systems, which i use to allow only my front-end client to access by registering the same application token on environment variables, then i pass this app token in request headers, this way only my applications can make requests on the server
@joshtriedcoding Жыл бұрын
Smart approach, respect if you came up w/ that yourself
@hago7568 Жыл бұрын
I have seen an api where they use a cookie they send down and a frequently changing not displayed html element to prevent spamming the api - at the end of the day - just use puppeteer and dom-parser and you can circumvent it all
@arden6725 Жыл бұрын
What's stopping a malicious user from harvesting the token from your frontend?
@kiddasneve1677 Жыл бұрын
@@arden6725 onboardbase can avoid this situation, which i personally use to store secret keys instead .env in production
@luigicorciulo81905 күн бұрын
@@kiddasneve1677 I don't think you got what he said, somebody can harvest the token from the frontend and use it to make requests using another software like postman for example, or something worse..
@smotch7533 Жыл бұрын
I like the bg change for every section, nice touch.
@joshtriedcoding Жыл бұрын
Thank you dude
@hayveno Жыл бұрын
Working on a backend project, and all checked ✅ Great video 👏🏾
@bilalbeny41724 күн бұрын
Thank you ❤. Additionally, the CSRF tokens are essential for enhancing security by preventing cross-site request forgery attacks. They help ensure that requests made to the server originate from authenticated users.
@pratikbankar4757 Жыл бұрын
I hope you make a complete tutorial on this steps.
@benjamingoller6267 Жыл бұрын
That wolle actually be great!
@owenwexler7214 Жыл бұрын
Big part of input validation that was left out of this is protecting against SQL injection if using a SQL db, which is likely. Always at the very least use something like Pg with parameterized queries if not using an ORM. Very good overview otherwise.
@skateboarderlucc Жыл бұрын
And for god sakes, if an npm package is being called as part of the middleware before the request is responded to, please verify if the package does not have any CVEs associated with it. The amount of compromised npm packages that receive thousands of downloads per week are numerous. just my 2 cents.
@DezZolation Жыл бұрын
Great stuff as always! Little take from me: I'm of the opinion that one should never deliberatly throw a 500. A 500 to me indicates an unhandled exception that a developer always needs to look at :) when it appears so it doesn't make sense to throw it if it can be helped. There are always 4xx alternatives.
@joshtriedcoding Жыл бұрын
Interesting take, thanks for sharing!
@mateja176 Жыл бұрын
In a theoretical situation where you don’t know whether the error is request related or an internal server error, it might make sense to throw a 500 error. In practice you should always be able to verify whether the request is malformed.
@JohnDoe-ji1zv Жыл бұрын
500 is thrown when UNEXPECTED error is happened. You are rethrowing the error yourself because there would be a log message and also you need to make sure that nothing is leaked when unexpected error happened. So it’s normal to do that
@klicer3068 Жыл бұрын
4xx for bad request, 5xx for server error where something went wrong
@ylaguardia Жыл бұрын
Great video, Josh! I do all of that, but for rate limiting I’ve never used Upstash. Do you have a video using that in one of your projects so I can check it out?
@soundsandstills Жыл бұрын
Great video. Could you do a video on really thorough error handling in typescript. It would be great to include a simple try catch, and something more complex where there are multiple async steps taking place. Perhaps even including utility functions and where you would put the try catch and why. I think this is a hard thing to do really well.
@ness-ee Жыл бұрын
What I do as a FED: If you have a function that makes the request you put the try catch in the function (might be a store action) that uses it. If you’ve made a factory to make your requests and store the results, then you put the try catch in that factory and use the catch block to call your error reducer/mutator in your store. Here you rely on store state to let your UI know there’s an error. Typically the store factory will put loading, response and error into the state for the UI to pick up. Where it can get complicated is when you need to bubble errors up to another try catch… and it’s only complicated because then you might lose track of errors. Let’s imagine that our factory also bubbles errors as well as calling the error reducer/mutator. In this case you need a try catch in your action. I’m trying to think of a use case for doing this but actually there isn’t one. You want your actions to be single responsibility. So, for example, if you wanted to add monitoring to your application and ping an endpoint on every api error from the FE, put a callback in your factory’s catch block and not in the action. It’s important to make it a callback to separate the concerns of the store factory and how the application uses it.
@59sharmanalin3 ай бұрын
You only talked about oauth2 oidc flows which is typically for sso or granting scopes/permissions to 3rd party with resource owner's consent but what about a simple 3rd party accessing your apis, in such cases you may share a key with 3rd party and have 3rd party generate and share in request something like a checksum Md5 of 'payload + secret key' validating which shall ensure the authenticity of your 3rd party which adds to the security of the api
@webber5629 Жыл бұрын
I would love to see a full video of protecting API as you said.
@codinginflow Жыл бұрын
Good summary. I'm doing all of the same things 👍
@kalpadhwaryu7929 Жыл бұрын
Do you mind making a video explaining these steps by creating an API?
@xdarrenx Жыл бұрын
I love token based rate limiting, because u can separate time from attempts. Example, loging route 3 tokens for 60 minutes to stop brute force, but for another end point, 50 tokens per minute, so that way legit users can do a big paginated request in high speed once, but not repeatedly to not overload
@skateboarderlucc Жыл бұрын
great approach imo. Attacks can take place in slow motion.
@luigicorciulo81905 күн бұрын
But this way if they attempt to saturate the rate limits you still hit the database with each request, it can become costly
@user-mm4kh6tg8u2 ай бұрын
junior dev here, i’m using HTTPs but whenever i open the network tab & copy a request as powershell, i still see the cookies and all my headers, is this normal/safe?
@Blast-Forward Жыл бұрын
Input validation is not only important for the sake of security but also for not breaking your app in development. It might always happen that accidentally malformed or erroneous data ends up in your database in the worst case taking down the whole app, so you waste time finding that data. If you do it properly right from the start you are protected against that _plus_ against malicious requests.
@ekchills6948 Жыл бұрын
Hi Josh! Please I'm confused about the session token and jwt can you please shed more light. The whole Auth stuff confuses me
@joaomaia9140 Жыл бұрын
Congratulations on the video ! Can you do a tutorial on this topic?
@Wakkyguy Жыл бұрын
Please make a video on "How to securely handle environment variables in frontend?"
@frankdavidaddae8397 Жыл бұрын
Hi @joshtriedcoding, thanks for the insight. I really appreciate. I have a little request, are you able to make a video where you build a demo API that show case the things you’ve talked about here. I would really love to get a bit more clarity on that. Thanks in advance.
@danielgruner Жыл бұрын
I really like this video and also the discussion in the comments as it goes far beyond the typical videos on APIs. They’re mostly about how to develop but not how to secure APIs. One question about input validation. I validate user input with zod but strings mostly only with z.string(). I don’t use any further regex validation or so. I use prisma as an ORM and I currently “trust” Prisma to handle input strings in a secure manner. I haven’t found any information if Prisma does so or not and I am a little bit lost. 😅 Should I validate my input strings even more (e.g using regex?) or should I trust Prisma ORM? 🎉
@user-gm3lg8gp3m Жыл бұрын
This is very useful. Thanks.
@rogueturnip Жыл бұрын
What sort of performance impact does the API get by adding a call out to do the rate limiting checks? If you are checking tokens, a session cookie and rate limit could that impact the API performance enough that it's noticeable?
@7thAttempt Жыл бұрын
That entirely depends on the logic that's implementing the rate limiting checks ... It's the cost of doing business. If you removed all 5 suggestions your API would be as fast as possible, but at what cost. Implement best practices, draw a line under it, make them non-negotiable. Move on.
@x_Saad10 ай бұрын
What if my Frontend website doesn't require the user to login
@luigicorciulo81905 күн бұрын
Everything is the same except you don't need to handle authentication and authorization
@n2-yt Жыл бұрын
To secure your API just follow the best practices and standard approach. Most of the modern API frameworks follow those, sometimes you just need to configure them.
@aymenbachiri-yh2hd5 ай бұрын
Thank you so much josh
@gr8tbigtreehugger Жыл бұрын
Many thanks for these tips! Wondering how this works in nextjs? Also an idea for a vid: arm wrestling dates and timezones due to passing dates between client and server components. My data is in UTC in my db but stuff like 'Today" for the client means something different for db calls than on the server. Love your channel!
@lifesexpression5168 Жыл бұрын
I love your videos nice work, however, your error handling does not look so great. How do you handle uncaught exceptions and unhandled rejections in one go? Those can be handled using middleware which you can only call once throughout the server.
@leandroloriato Жыл бұрын
Hi Josh, nice video! Love your channel, always bring relevant content! Could you please expand a little more on some of the steps, specially auth/authorization and rate limiting? It would be very nice if you brought some example code in github, good patterns, useful libraries, caveats, etc. Thank you so much for your work!
@vinaymama Жыл бұрын
Super useful... Thanku Josh
@joshtriedcoding Жыл бұрын
Youre welcome champ
@MDKhan-ww5tp Жыл бұрын
Can you make a video on you vscode setup
@joshtriedcoding Жыл бұрын
What would be interesting for you to be in that video? Like custom snippets, theme, ...?
@MDKhan-ww5tp Жыл бұрын
@@joshtriedcoding You are goat everything in your setup will be interesting
@reversetcp Жыл бұрын
except, error handling is a nightmare in nextjs... try/catch spam and copy paste catch block on every route u create
@joshtriedcoding Жыл бұрын
How do other languages / frameworks handle that better?
@elab4d140 Жыл бұрын
@@joshtriedcoding in express, there is a package named express-async-errors which let you remove that try/catch spam and let you handle all the errors in the error handler middleware.
@reversetcp Жыл бұрын
@@joshtriedcoding You can write a custom function in express that can wrap your route in.
@reversetcp Жыл бұрын
Had to come back to this. Almost forgot: Bad middlewares. You can not use Prisma in middleware; for me that means I can not auth in middleware and the every API route has to be spammed with a auth check before I can actually start writing logic. ExpressJS' approach to middleware is so much more flexible and flawless imo.
@kobiowuquadri94588 ай бұрын
Thank you, josh
@siya.abc123 Жыл бұрын
Another awesome video man, thanks! I was hoping you would touch on CSRF too
@joshtriedcoding Жыл бұрын
I decided to not touch on specific vulnerabilities because they are so dependent on your use case. If I touched on CSRF, why not SSFR, various injections, and so on, y'know. A separate video on those would be cool tho!
@siya.abc123 Жыл бұрын
@@joshtriedcoding gotcha!
@AdamGweleg Жыл бұрын
Love ur videos ❤
@joshtriedcoding Жыл бұрын
Cheers man!
@omarkraidie Жыл бұрын
if i have two functions in pages/api/posts/index.ts which function gets invoked when making an api request? also how can I define the method for said functions in next js api routes?
@omarkraidie Жыл бұрын
I think its something like this "if (req.method === 'POST')" // handle post "if (req.method === 'DELETE')" // handle delete? Thanks alot man nextjs 13 is exciting but its hard at first!
@joshtriedcoding Жыл бұрын
@@omarkraidie Oh yeah it is. For the pages router I used to write a custom middleware that you could just wrap your entire API endpoint in to automatically send back a 405 status code for unspecified methods. It's far more intuitive in the new app router though
@Adrian_Galilea Жыл бұрын
Please do a practical example in the new app router :)
@omarkraidie Жыл бұрын
@@Adrian_Galilea also maybe prisma and MongoDb? 🤍
@CaleMcCollough Жыл бұрын
HTTPS won't stop a man-in-the-middle attack. If someone is snooping when you pass off encryption keys, it's not longer encrypted.
@tusharsnx4 ай бұрын
Yes, it only saves you from MITM in your network.
@luisfelipemurguiaramos659 Жыл бұрын
Make a video to log data. If a error happens send to a server the error or logs
@BeyondLegendary Жыл бұрын
Impressive, very nice. Let's see Paul Allen's api security.
@joshtriedcoding Жыл бұрын
It even has a tasteful THICCness to it. Oh my god.
@CodeZakk Жыл бұрын
also you should also secure for xss attacks!!
@AlecMaly Жыл бұрын
In addition to other injection attacks (sqli, command injection, host header injection, etc.), mass assignments, 4xx bypasses, directory traversal, SSRF, web cache poisoning, logic errors, race conditions, IDORs, unicode normalization, information disclosure, etc. etc. etc. I'm glad to see someone talking about security. I don't see this often enough from non-security focused developer channels imo. Nice video!
@joshtriedcoding Жыл бұрын
@@AlecMaly There was a reaaaally good website I once found explaining each of these in great detail, listing how to mitigate them and providing interactive examples. Can't remember the name right now. Most of these are heavily use case dependent, some you don't need to worry about at all depending on your deployment/tech stack. Nevertheless, these are very interesting to get into. Maybe one of y'all remembers that site it's definitely worth checking out
@crizuka Жыл бұрын
@@joshtriedcoding maybe the website was hacksplaining? there is a lessons tab where they give a good explanation on those topics
@a.perkemantus Жыл бұрын
Great video!
@joshtriedcoding Жыл бұрын
Appreciate you man
@محمدرواس-ص9غ Жыл бұрын
Can you make a series of building full stack websites whenever you have a time
@AngelEduardoLopezZambrano Жыл бұрын
Csfr?
@buddhaFC Жыл бұрын
Awesome 👍
@jjrise Жыл бұрын
Awesome video
@saidurrahmansiam Жыл бұрын
An extra additional step that I follow is generating the current time in milis and then making it a signed token which will be in the "key" parameter in the API link. Then when the API is hit it first verifies the key value token and then compares it with the current time of the API server and if the time passes more than 10 seconds API responds with a 401 not authorised response. because both times come from the same server it never gets the wrong time in milis. Even though if the request server and API server are different milis would be the same for any timezone of the world.
@joshtriedcoding Жыл бұрын
Honestly sounds kinda cool but I must admit I actually have no idea what you mean
@saidurrahmansiam Жыл бұрын
@@joshtriedcoding XD... I guess I meesed up on explaining...so here it is in the API calling function I get the current second using (Date.now()/1000) then add 10 to that variable which makes the variable 10 seconds ahead of its time like we do in generating cookies. then wrap that variable using signed jwt and store that signed jwt to a variable named key. then in the fetcher I add the variable as key param like this `/api/get-user-data?&key=${key}`. finally in the API route I check the condition if the URL has key param.if so then I take the key param value(signed jwt) and validate that and store the validate data in a variable otherwise return 401. lastly I check the decoded jwt data or you can say the second is near the time by simply subtracting like this const difference= decodedKey - (Date.now/1000); then wrap with condition (difference > 0 && difference < 12). this makes the API link only available for 10 seconds otherwise link will always return 401. even if someone understand how it works they can't bypass the jwt validation. so this adds another layer of security to the API
@soumyasagar2305 Жыл бұрын
Summary 1- Use https 2- Authorize user in API 3- Rate limiting the API 4- Validation of data passed in API 5- Error handling
@RootEntry Жыл бұрын
yk the summary is in the descriptionright
@soumyasagar2305 Жыл бұрын
@@RootEntry oops didn't have a look 💀
@filip_wojda9 ай бұрын
great video
@EdgarR-x5e Жыл бұрын
Another one is "Versioning" extremely necessary for update and patches
@thefuntech2810 Жыл бұрын
Bro you missed the one of the most secure section and that was ACID. Transaction How to revert those transactions which executed but they failed at the end At that time our data will get corrupted Hope you explain me or make video on this Thanking you in advance
@emrebabur8236 Жыл бұрын
👏
@samislam274611 ай бұрын
I think error handling is off-topic
@AidanCanavan-v5i Жыл бұрын
Timing errors!!
@beancoffee Жыл бұрын
Just leaving it here,for when I come back to the video in the future... 1. HTTPS 2. Auth 3. Rate Limiting 4. Input Validation 5. Error Handling
@krish3d3852 ай бұрын
I find this basic.
@mehmatrix Жыл бұрын
Great video. I would say there is a very important 6th step. Maybe more important than the 5th one. Monitoring. We would like to know if our Server is being attacked, down or returning errors etc. So we can take action towards it. Thanks for the curation tho 🙏🏻👍🏻🫶🏻