It happens that in your organisation the very first React application is built with months of dedication, great developers coding with ridiculous d...
For further actions, you may consider blocking this person and/or reporting abuse
In section 2, I'm not sure I'm understanding. Steps 1 & 2 seem to be about changing the behaviour of React as a client. Rate-limiting your app's calls to the server does not prevent a DDOS attack, it's just ensuring many of your legitimate clients have a more even experience when a server takes too long to honour requests. I would only use a client-side rate limiter as a temporary fix for any network traffic issue, you need to look to more fundamental issues with your server code and infrastructure, don't treat your own customers as attackers! And DDoS' by definition don't come from the same IP, and won't bother using your React client to do it. It's also not really a React-specific issue, React is client-side, it's more like an issue for neXt, express, koa or whatever you're running on the server.
I don't understand what 3 means, would you be able to write a little more to clarify?
And 4 seems to be related to the next section on XSS attacks.
Hey Jodi!
To some extent, I do agree with you that rate limiting isn't a permanent fix. The rate-limiting is applied so that only a specific number of requests would be accepted by the server. It should reject the attacker's request when it comes. And yes, this is the case when you use Express/Node for the backend. Of course, not all API stuff can be done solely on client-side when you want to secure your app.
I got to know about point #3 from this article by Philippe. It has details of what you're asking.
Point #4 is about CSRF and NOT XSS.
Thanks!
Oh, I think I'm starting to understand your point of view, DDoS' from your React app because it's been subverted. It's just a little odd because I don't see points 2-4 from that section being anything to do with DDoS'ing.
Am I correct in thinking that point #3 you mean URLs that the client can call should originate from the server and not be dynamically-generated in the client? This is to avoid things like erroneous values causing ReDoS'.
It also occurred to me that you don't mention CSP, which would be a very good technique for reducing the chance of invasive XSS via external script calls.
I don't know much about ReDoS and same for the CSP that's why I didn't write about these. But thanks for your information, people will definitely learn something cool!
ReDos is where you exploit a regex (and these are often used for validation, which can be worrying when it's cited as a way of preventing attacks!) that causes an exponential processing loop that slows the server down (mitigating that with rate limiting makes sense).
CSP is where you add headers from the server to indicate to the browser what kind and from where resources are allowed to be loaded onto the page. Content from any places not explicitly mentioned are blocked. Helps with things like defacing too.
Thanks for writing about this anyway, more awareness of security issues is always good, and it's not an easy topic to write about.
Ah, I see. Will look into these two in future. Thanks for writing about this :)
And yes, it's quite challenging... 🥴
**Sent **to the server, surely? The web application just makes requests over HTTP. Axios can limit for flood protection and better user experience for non-malicious users, but if someone was going to DDOS you they would intercept the API call and just replay that repeatedly, that sort of security should never be done in Javascript!
Unless you are using a JS backend too, I guess.
The only real way to prevent DDOS is a security layer at server level. Anything client side can be overridden. The golden rule of security is you never trust the web client!
Even the first suggestion can be dangerous, since cookies are not safe by default. You need to make sure to use
SameSite=Strict, and not every browser current supports that flag.Additionally, there are some problems with even doing that though, because it means you can't actually use the token to do anything valuable by interacting with other domains. For instance, let's say you want to take your access token and use it to access other services which also support OIDC JWT complaint access tokens. Your app needs to have access to them. Which means cookies won't work because they won't send them cross domain. Take Authress for example which handles user permissions. You can take the access token from the UI and send it to Authress, and where the token will be verified for authenticity before granting permissions. While you can store it in cookies, doing so without protections is both unsafe and feature limiting.
Hi Warren, thanks for the insight! I just started with security, hence don't know much in detail. I just shared what I learned (till now). I've added your comment in the article so that others can check.
Insightful piece! Thanks 😄
Thanks for reading!
Really interesting thanks for the suggestions! I'm still relatively new to the field but migrating from a django+jquery to a django+react frontend for my virtual car show platform and definitely need some work to be done on the security side of React. I didn't realize how easy django made everything for me!! Thankfully it's not like I'm handling super secure data or information but obviously you want to build with the intention of having the highest possible security.
I agree! I've used Django in the past and it's one of the best Python frameworks to build a full-stack web app 🔥. I didn't do complex security stuff as it was just a demo app but yes, I do see a great deal of community support/resources for Django in security too.
Good luck migrating your platform. 😁
This is exactly what I was looking for, thanks a lot!
Interesting. Good read.
Thank you! :)