Route Protection from DDoS
Unanswered
Japanese flying squid posted this in #help-forum
Japanese flying squidOP
I've API route /api/keepz/pay -which connects with external payment provider API.
And someone is spamming this request from my website, please tell me how can I control it. I will attack route handler in picture. This route is triggered on button press but someone is doing it programatically or something.
And someone is spamming this request from my website, please tell me how can I control it. I will attack route handler in picture. This route is triggered on button press but someone is doing it programatically or something.
25 Replies
Japanese flying squidOP
BTW. it would be great if I could make something work for every API reuqest, based on user
@Japanese flying squid BTW. it would be great if I could make something work for every API reuqest, based on user
you need to setup ratelimiting. https://upstash.com/blog/nextjs-ratelimiting
this is an older example using API routes but you can modify it for your current code
this is an older example using API routes but you can modify it for your current code
Japanese flying squidOP
I've set up IP based rate limiting, they can't send requests from same client mutliple time, only once in 30s. But someone is sending requesrs from multiple devices so IP is different, like in DDoS Attack. This route is public, can't restrict it with authorization or something
What If I make checkbox like "I am human" and if they check it, I will include JWT token for that request, and I will make it protected by token? They can spam my route but not the external payment API ( that's the whole reason to protect external API, not mine )
yea that will work
but
if your system calls it on a button press, you can surely add authorization
Japanese flying squidOP
Yes, but someone can just send API request from console and spam it
this is the only way to protect your route if u dont have authorization
literally everything else is bypassable
people can just change headers
so anybody can just randomize headers and spam your api, it will look like a ddos
and only cloudflare can also be bypassed easily, thats why cloudflare has also captcha solutions
use turnstile for captcha
recaptcha from google is easier to bypass
Japanese flying squidOP
Thank you so much
Japanese flying squidOP
@gin variables added in .env without NEXT_PUBLIC ( in production on Vercel environment), is there a chance somehow they can leak? I am using env variables inside server API routes only, only one of them have NEXT_PUBLIC
if u make sure those variables are not included somewhere in your client components or anywhere where it could leak its fine
Japanese flying squidOP
in client components variables without next_public, are accessible?
I have them in api routes only
I have them in api routes only
Japanese flying squidOP
thank you