-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about Denial-of-Service (DoS) #75
Comments
Hi, thanks for raising the question. A Yes, the configuration of the API-Gateway with the route However the issue would still be present then, since the attack could be modified to target other parts of the cache-key from CloudFront. However CloudFront has several monitoring and security measurements built-in to mitigate DoS attacks and can be further secured with AWS WAF. So while I agree that we should restrict the path further in API Gateway, I would say that CloudFront is not an easy target for a massive DoS attack. |
Hi, thanks for the detailed explanation! Let's say that I'm in a situation where I want to restrict the api as much as I can before relying on AWS built in protection or WAF. If I understand correctly, here are the settings that compose the cache-key:
Values could be limited to the browsers default so that an attacker could not set random values.
I don't understand why the referer is part of the cache-key because I could use the same api on multiple next.js website.
Possible values are limited.
The value is reliable since url domain is white listed. But an attacker could add query params to that url. A solution for that case would be to only allow urls without query params. Sorry if it's beyond the scope of this library and if it's specific to my use case. Do you think that such restrictions would effectively protect the api and avoid useless costs ? |
No problem, the module is designed as an enterprise application and given that it currently has 1000+ weekly installs, improving security is a top priority for this project. Referer headerThe This was meant as an easy way to integrate, but we should change it in the following way:
Accept headerLimiting the header to default values is a risky take since this can change every time.
The advantage of using a CloudFront function for this is that it is relatively cheap ($0.10 per 1 million invocations) and the modified Header is used to serve the request from the cache instead of hitting the origin. url parameterThis is a tricky one since adding parameters to the the The only way to secure this would probably to introduce another S3 bucket instead of (or together with) CloudFront Origin Shield for the local caching. |
Thanks for the detailed explanation. I understand the solutions you describe and they seem really suitable. |
Absolutely would welcome a PR on this! My current plan is to start small and implement the changes to the |
Closing this for now since I've splitted the issue in smaller packages:
Thanks for the input! |
Hi 👋
First of all, thank you for this nice project. Code is very clean and inspiring.
I am considering using it in production and I have a question regarding DoS attack.
I think image optimization could be expensive if a bad person plays with the api endpoint.
My first question is: every time you get a
Miss from cloudfront
, the lambda is run and (costly) image optimization occurs?If it's the case, the api should be less permissive than it is. I noticed that with the api gateway configuration:
/_next/{proxy+}
, you just have to put random strings like/_next/blabla
to avoid cache (Miss) and generate a new image.What are your thoughts about this?
Thanks!
The text was updated successfully, but these errors were encountered: