✦ Independent web developer/designer/blogger
✦ Lead Framer Developer at Framerly
✦ Framer Expert & Partner | Advocate at 10x Designers
✦ Hire me on Contra👇
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.
True full stack in #fintech. Analysis, solutionizing, developing and delivering.
Mostly working in dotnet and javascript, with a passion for process optimising!
only a specific number of requests would be accepted by the server. It should reject the attacker's request when it comes
**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!
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.
✦ Independent web developer/designer/blogger
✦ Lead Framer Developer at Framerly
✦ Framer Expert & Partner | Advocate at 10x Designers
✦ Hire me on Contra👇
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.
✦ Independent web developer/designer/blogger
✦ Lead Framer Developer at Framerly
✦ Framer Expert & Partner | Advocate at 10x Designers
✦ Hire me on Contra👇
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!
**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!
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... 🥴