Web Application Firewall Integration

[blazinaj]

Is your feature request related to a problem? Please describe. We are trying to use an Amplify-CLI / Amplify-Console powered app in Production. A business (security) requirement is that we use a Web Application Firewall. Currently there is no way to implement that with the Amplify Console, so we will have to host our production app using a different service.

See: #8

We are a little sad about this, as the Amplify Console has 90% of the functionality needed for hosting a production level app, but "Only Basic Auth security" is a major deal breaker for us.

Describe the solution you'd like Allow us to create our own CloudFront distribution, with an associated WAF, and direct the Amplify Console Hosting through that domain, instead of the automatically generated "always public" domain (e.g. production.abcxyz.amplifyapp.com)

[marco910]

Does anyone know any possible workaround for this integration between Amplify Hosting and WAF?

@rodrigomotta1 Maybe it would work to "wrap" the Amplify distribution with another CloudFront distribution and apply the WAF to that. I didn't test that and don't know how this would impact the performance, but maybe it works.

[Vlaaaaaaad]

Does anyone know any possible workaround for this integration between Amplify Hosting and WAF?

It's possible through manual work according to this blog post. I haven't tried it tho!

[rodrigomotta1]

@marco910 and @Vlaaaaaaad, thanks for the input! Unfortunately I decided to abandon Amplify Hosting and now I'm manually setting all up using CodePipeline, CodeBuild, CloudFront and WAF 😕 For those having the same problem, I think that doing this job manually is a great workaround because you'll have a lot more control of what is happening behind the scenes, but will require some experience with AWS (CloudFormation can help a lot in this manual process also). This reference helped me with the job.

Just for you to know, I'm setting up a CI/CD environment for a CRA React app, so if you're having issues like me, maybe this could work for you too! :)

[slikk66]

I posted about this in may '21 also..

I used Pulumi to setup my own cognito, cloudfront, s3 hosting, waf, appsync, dynamo, iam, lambdas, apigateway etc. I still use the amplify front end libraries, but had to ditch their infrastructure side 100%

[marco910]

@Vlaaaaaaad Thanks for that approach! Unfortunately, this is not working anymore when using the new platform for Next.js 13. The resources for those distributions are completely hidden in the AWS console.

@rodrigomotta1 Sounds really great, but unfortunately, I think this is only working for static sites like yours which is created with Create-React-App. I'm working most of the with Next.js apps which are hosted serverless because of their SSR functions. Do you know an approach, how this could work for Next.js apps?

@slikk66 So, are you still hosting on AWS or switched completely? What are you using now, if you switched?

[slikk66]

@marco910 still on AWS, but had lots of issues with Amplify infrastructure side. Just had too many bugs and issues that I ran into, this being one of them. I would deploy simple things with it and then see how they were configured, then copy that configuration to my own IaC tooling. So far has been working well.

[doguhanciftci]

Any updates?

[marco910]

@doguhanciftci Not from AWS, but I built a CI/CD workflow on my own now. Maybe you're interested in that setup: I'm using CodeBuild to build my Next.js site and then output the artifacts (build output) into a S3 bucket. After the build, a webhook on the VPS in triggered, which pulls the artifacts via AWS CLI from the bucket and deploys them locally on the instance. On top of the VPS, I'm running a CloudFront distribution with an additional WAF v2. This is a bit of setup work, but in the end it works very well.

[doguhanciftci]

@doguhanciftci No from AWS-side, but I built a CI/CD workflow on my own now. Maybe you're interested in that setup: I'm using CodeBuild to build my Next.js site and then output the artifacts (build output) into a S3 bucket. After the build, a webhook on the VPS in triggered, which pulls the artifacts via AWS CLI from the bucket and deploys them locally on the instance. On top of the VPS, I'm running a CloudFront distribution with an additional WAF v2. This is a bit of setup work, but in the end it works very well.

Thanks @marco910, since there is no hope on the Amplify side, I will implement a similar approach. Thanks for sharing your setup.

[amardesai1]

Any ETA for WAF or at least the ability to access the CloudFront Config for Amplify?

[costerman]

@swaminator - Loved the options you laid out a few years back in this issue thread (https://github.com/aws-amplify/amplify-hosting/issues/36#issuecomment-550449265)

Any update on option 2. We are leveraging Amplify hosting for our Next JS React app and I need to do some specific IP range blocking, geographic restriction, and pattern matching (but in my case blacklisting instead of whitelisting unfortunately).

[hisham]

+1. Blacklisting ip required at minimum. Something like Cloudlflare bot management that just works out of the box with 1 click would be ideal for us who don't want to wrangle with AWS too much. Thanks!

[salauddinn]

has anyone tried this approch https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/enable-aws-waf-for-web-applications-hosted-by-aws-amplify.html

[costerman]

@salauddinn I haven't, but thank you for sharing this. Will take a look and give it a try.

[srgustafson8]

has anyone tried this approch https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/enable-aws-waf-for-web-applications-hosted-by-aws-amplify.html

I have, but wrote it using terraform and slightly less complicated (no caching, no lambda for password retrieval). It does work provided you get the credentials correct!

[salauddinn]

@srgustafson8 I'm also planning to implement in Terraform. if possible share the repo that you implemented. it might be helpful for me to implement if not can you explain how are handling the aws amplify proection and caching if you not implemented lamdas

[srgustafson8]

@salauddinn can't share the repo yet, we're not quite set up to open source anything at this point.

tl;dr for the auth:

using the random provider to generate a random username and password, with a variable that lets you rotate the credentials:

resource "random_password" "username" {
...
  keepers          = { version = var.rotate_basic_creds }
}

resource "random_password" "password" {
...
  keepers          = { version = var.rotate_basic_creds }
}

then creating the base64 encoded result in a local var

locals {
  creds = base64encode("${random_password.username.result}:${random_password.password.result}") }
}

add these as the values for basic auth in amplify and custom header in cloudfront

resource "aws_cloudfront_distribution" "this" {
  web_acl_id = ...
...
  origin {
...
    custom_header {
      name  = "Authorization"
      value = sensitive("Basic ${local.creds}")
    }
  }
}

resource "aws_amplify_branch" "this" {
...
  enable_basic_auth      = true
  basic_auth_credentials = local.creds
}

And I just disabled caching on cloudfront entirely by adding the CachingDisabled cache policy. You could use a null resource doing a local exec to do the cache invalidation as the last step of the deployment pipeline which removes the need for a lambda to do it.

Hope this helps!

[salauddinn]

i will try it Thank you @srgustafson8

[swaminator]

@salauddinn @srgustafson8 @hisham @costerman @amardesai1 @doguhanciftci @slikk66 @justinwiley @tchalvak @emrul @blazinaj @marco910 @rodrigomotta1 @Vlaaaaaaad @royax88 @danfreid @brian-snyder @denonade

Amplify PM here - We are evaluating an approach that would connect a WAF resource in your account to the Amplify managed distribution. You will be able to use our console/API/CloudFormation to associate a WAF ACL (which you have configured in your account) with your Amplify app. However this approach has some near-term constraints around caching content and we want feedback if these constraints are acceptable:

1. Performance mode will not work
2. Cache-control headers set in custom headers would not be respected
3. Next.js ISR will not work
4. Next.js cache control settings would not work

Would love feedback on whether these constraints are acceptable as we decide whether we prioritize this project right now.

[amardesai1]

@salauddinn @srgustafson8 @hisham @costerman @amardesai1 @doguhanciftci @slikk66 @justinwiley @tchalvak @emrul @blazinaj @marco910 @rodrigomotta1 @Vlaaaaaaad @royax88 @danfreid @brian-snyder @denonade

Amplify PM here - We are evaluating an approach that would connect a WAF resource in your account to the Amplify managed distribution. You will be able to use our console/API/CloudFormation to associate a WAF ACL (which you have configured in your account) with your Amplify app. However this approach has some near-term constraints around caching content and we want feedback if these constraints are acceptable:

1. Performance mode will not work
2. Cache-control headers set in custom headers would not be respected
3. Next.js ISR will not work
4. Next.js cache control settings would not work

Would love feedback on whether these constraints are acceptable as we decide whether we prioritize this project right now.

My company's amplify application is a Vite SPA , that the default caching behaviour will work fine with.

We'd love to see this functionality, regardless of these constraints. Looking forward to hearing more.

[slikk66]

@salauddinn @srgustafson8 @hisham @costerman @amardesai1 @doguhanciftci @slikk66 @justinwiley @tchalvak @emrul @blazinaj @marco910 @rodrigomotta1 @Vlaaaaaaad @royax88 @danfreid @brian-snyder @denonade

Amplify PM here - We are evaluating an approach that would connect a WAF resource in your account to the Amplify managed distribution. You will be able to use our console/API/CloudFormation to associate a WAF ACL (which you have configured in your account) with your Amplify app. However this approach has some near-term constraints around caching content and we want feedback if these constraints are acceptable:

1. Performance mode will not work
2. Cache-control headers set in custom headers would not be respected
3. Next.js ISR will not work
4. Next.js cache control settings would not work

Would love feedback on whether these constraints are acceptable as we decide whether we prioritize this project right now.

I'm not sure which "performance mode" you're referring to - but for the rest this would have worked for me. I've since deployed my own WAF/distros/backend with Pulumi and use the front end Amplify libraries only to connect to my infra, but none of these constraints seem like deal breakers to me. I think missing WAF ability for Amplify is a much bigger deal.. Amplify is meant to be used to build websites, yet lacks the ability to use native AWS tools to protect said websites.

[bsnyder74]

@swaminator Constraints seem reasonable to me. +1 for prioritizing this please!!

[Vlaaaaaaad]

Would love feedback on whether these constraints are acceptable as we decide whether we prioritize this project right now

@swaminator: yes, those are acceptable compromises for a faster launch. Launching something a bit more limited today and then iterating and eliminating the limitations is a good plan is this case!

That said, Amplify Hosting should have a default WAF included with the service. In my opinion, Amplify Hosting is a managed high-level service which means it should come with all batteries included (so with AWS Shield and AWS WAF configured and setup) but it should also support straightforward escape hatches (so allowing folks to use their own AWS WAF if they have custom or fancy requirements).

[frattaro]

@swaminator we have a public-facing app that it wouldn't be good for, a non-public one that it'd be beneficial to have that on. As long as it's configurable per-project there'd be interest

[srgustafson8]

Would love feedback on whether these constraints are acceptable as we decide whether we prioritize this project right now.

Thanks @swaminator for the reply and great to hear you're looking in to this. The only dealbreaker there is the Next.JS ISR for us, which is key for our implementation. However, as long as that's going to be resolved in the future, it sounds like a positive step forward and our workaround will hold until the full implementation is ready.

[tchalvak]

Two questions from the approach, @slikk66

Quote:

• Performance mode will not work
• Cache-control headers set in custom headers would not be respected
• Next.js ISR will not work
• Next.js cache control settings would not work

Endquote

First, I assume that the standard index.html “revalidate” is not handled via cache-control headers, so the approach above allows for the standard use case? Second, I think a common use case is creating alternate “dev” sites from “production” sites, for which the current basic auth approach - while feasible - is troublesome. Will the new approach allow for the full power of WAF to create whitelisting of devs based on different criteria?

[srgustafson8]

@tchalvak 's comment raised a point that I forgot - ideally we would want to be able to attach either an ACL for the whole app, or a different WAF ACL per branch - which would override the app one. Would that be possible as part of the planned implementation?

[thornyweb]

@swaminator was a decision made on this project progressing yet?

[swaminator]

Thank you everyone for your input. Given the feedback we got on the tradeoffs, we have unfortunately decided not to prioritize this feature this year. We understand that this may be disappointing to read, but we are going to spend some more time to deliver this feature right. We have prioritized two other top feature requests for delivery this year instead - #44 and #56. Thank you for your patience.

[thornyweb]

Thank you everyone for your input. Given the feedback we got on the tradeoffs, we have unfortunately decided not to prioritize this feature this year. We understand that this may be disappointing to read, but we are going to spend some more time to deliver this feature right. We have prioritized two other top feature requests for delivery this year instead - #44 and #56. Thank you for your patience.

Hi @swaminator thank you for the update and your transparency. Are you able to confirm when this feature will be delivered?

Based on this update we need to make a business decision about whether or not to continue using Amplify.

Thanks.

[srgustafson8]

@swaminator This is quite disappointing - both of those requests combined have less 'thumbs' than this single ticket has and provide 'nice to have' functionality. Being able to protect public web endpoints is basic security practice and should be a day 1 requirement on every service that can be public facing, especially as the cyber threat landscape continues to become more dangerous.

[marco910]

@thornyweb We often face the same situation. Can I ask what alternatives to Amplify you are considering?

[thornyweb]

@thornyweb We often face the same situation. Can I ask what alternatives to Amplify you are considering?

Within AWS it would be something containerized or just simple Node on an EC2 instance in a VPC with much better network configuration controls.

Extreme solution would be off of AWS entirely with a different provider.

[frattaro]

If a WAF was required for us, the first thing I'd do is look at cloudflare: https://www.cloudflare.com/application-services/products/waf/

Pretty sure it relies on DNS redirection and it never seemed all that secure to me but I'm sure there'd be ways to restrict usage to the WAF channel.

[mswezey23]

+1 Would love to have this feature developed as we roll out our merchant-side product to all merchants.

[afern247]

This is a must have requirement, I have my app now getting attacked on the main public url while I have it fully protected using Cloudflare. In my case I'd like to redirect all traffic through my DND on Cloudflare and handle the security there.

Look at this, my app is fully integrated with Cloudflare DNS and no one in my team uses other than the main domain or local host and look how many requests I get daily to the main amplify domain:

Many of them go to specific locations trying to find vulnerabilities and creating loads on the server. If anyone wanted to lunch a DDoS attack they would break any amplify website, without this no amplify hosting service is prod ready. @swaminator do you still think security shouldn't be prioritized?

+1 for this feature, very needed, critical.

[afern247]

I've decided to move away from Amplify due to hosting security reasons, I'm mad at myself for taking so long to realize this critical vulnerability, the lack of prioritization for real needed features is embarrassing also. I recommend everyone else to go to CDK style for more control.

[joon623]

Still no plans to use vpc, ip-whitelist, waf?

[milind-daftari]

Is there a temporary fix or workaround for this for now?

[srgustafson8]

has anyone tried this approch https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/enable-aws-waf-for-web-applications-hosted-by-aws-amplify.html

@milind-daftari I followed this one that salauddin posted, it seems to work ok but not ideal

[em1l1000]

has anyone tried this approch https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/enable-aws-waf-for-web-applications-hosted-by-aws-amplify.html

@milind-daftari I followed this one that salauddin posted, it seems to work ok but not ideal

Would google still be able to crawl your website if you only allow one country in the allowed list?

[srgustafson8]

has anyone tried this approch https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/enable-aws-waf-for-web-applications-hosted-by-aws-amplify.html

@milind-daftari I followed this one that salauddin posted, it seems to work ok but not ideal

Would google still be able to crawl your website if you only allow one country in the allowed list?

Probably not the right place to ask this question, but that being said, unless that one country is USA I'd imagine no.

[jimmyn]

Is there any update on this? This is very much needed feature!

[sawravchy]

Any update on this issue? In terms of security, this is a very much needed feature.

[frattaro]

I'd check back in September, because the last update we got was "we decided not to prioritize this feature this year" -- so I imagine they pick features on an annual basis.

[mathewmcnaughtonmass]

This is an important feature, i hope we can get its priority increased

[tuxillo]

Any news on the WAF support for Amplify?

[ppuvan]

Hello any update on this? We are planning to use Amplify for a large scale application in the medical sector, but not having a solid WAF/VPC implementation for Amplify are making our decision makers turn away from Amplify. Currently we are using the CloudFront routing approach by using Auth header and making Amplify private, but as pointed out above if the URL were to be compromised (as it is extremely likely), then we are opening ourselves to DoS attacks. Please prioritize this above all other Code First updates, as it should be simple for the likes of your kind to implement, considering it is a critical security improvement.

[LarsPede]

Echo'ing all that is being said here about the critically of the feature. We are looking into doing the cloudfront routing approach but as @ppuvan is saying - the fact that the default url is always public is a major security concern for us... Since it sounds like you aren't prioritizing adding the full blown feature - is there then a middleway where we can make the url not publicly available by default? it would allow us to use the cloudfront work-around and still leave us somewhat protected by the fact that only something like a specific policy has access to the url?

Definitely keep up the good work in general! Amplify is an amazing tool for getting up and running! Just sad to see that we are still in a "non-prod" state in terms of security 😞

[mauerbac]

@LarsPede @ppuvan @tuxillo @mathewmcnaughtonmass @jimmyn @joon623 👋 Hello everyone -- we are in active development of this feature! Sorry for the lack of communication.

We are working through a few implementation decisions, and I'm curious to get a bit of feedback. We are exploring two approaches 1) An integration with the AWS WAF service 2) A more managed approach where you can easily accomplish IP allowlists, country block, enable Bot Protection/DDoS Protection.

Can you provide feedback on which approach would better suit your needs? I'm also available for a call if you can DM me on Twitter/X (@mauerbac) or email mauerbac@amazon.com to setup