3

I have a simple static webpage that lets users sign-up for a newsletter. Once they enter their email address, it gets sent to a public endpoint (AWS Lambda). This lambda function forwards the email address to a subscription list manager endpoint (Mailchimp) along with the API key.

The connection between the AWS Lambda function and Mailchimp is secure as no one has the API key and can't hammer my Mailchimp account. But my concern is the connection between the static webpage and the AWS Lambda endpoint. This endpoint is public and unauthenticated and I'm worried about things like people flooding the endpoint with fake addresses.

How can I best secure this? The static page is a simple Gatsby bundle.

Improve this question
5
  • I'm not sure what you are asking. On the one hand you discuss securing the connections to protect the data in transit and point this out as your main concern. But then you suddenly switch to "worried about things like people flooding the endpoint with fake addresses" - which has nothing to do with securing the data in transit. Please focus on one point only, i.e. data in transit (TLS) or protection against misuse and DoS (rate limiting, captcha, ....).
    – Steffen Ullrich
    Commented Mar 16, 2020 at 6:45
  • I've updated it. Yes, my concern is purely people hammering the public endpoint.
    – Saul
    Commented Mar 16, 2020 at 10:56
  • I also hope you are using double opt-in? e.g. sending an email for them to confirm the subscription, otherwise someone can subscribe people who don't want to subscribe.
    – Dijkgraaf
    Commented Feb 26 at 2:23
  • See also security.stackexchange.com/questions/172947/…
    – Dijkgraaf
    Commented Feb 26 at 2:37
  • Also be worried about people flooding the endpoint with real addresses.
    – Michael come lately
    Commented Jun 25 at 17:54

3 Answers 3

Reset to default
1

You will need a server side script acting as a proxy to protect the endpoint. If the static page access the endpoint directly, the attacker can do the same.

A server side component will hide the endpoint, and you can easily implement captcha validation, rate-limiting and other protections. It needs just a few kb of storage, and low processor speeds, so it can be very, very cheap.

Improve this answer
1

Serverless with reCAPTCHA

To retain your current AWS architecture but still mitigate misuse of the AWS Lambda endpoint, you can add a CAPTCHA service such as reCAPTCHA to the form on your static page and verify the token within the Lambda function. Both the client (through the static site) and the lambda function will communicate to the reCAPTCHA service.

It's worth noting that in this scenario, because the Lambda function would have to run in order to validate the CAPTCHA, there would still be Lambda cost for any successful invocation of the Lambda function URL.

Alternative with AWS WAF CAPTCHA

You could alternatively add AWS WAF in front of both the static page and Lambda function. You can specify which URLs require the CAPTCHA, and can integrate it into the page. The CAPTCHA token retrieved from the form should also work for the request to Lambda. For the WAF ACL to work with Lambda you would need to either use function URLs behind a CloudFront distribution or use API Gateway (it will not work directly with Lambda Function URLs).

AWS WAF would also give you some additional controls over conditions for accessing the resources you are protecting.

Improve this answer
0

Does the Lambda endpoint have to be public? If your web application is running on AWS, perhaps you can route the traffic internally in a VPC and make the Lambda private / only accessible from the webserver.

Furthermore make sure that the you filter possible spam as much as possible at the webpage. Use honeypot field(s) and CAPTCHA if possible. This will be your 'first line of defense'.

Improve this answer
2
  • Your first suggestion just shuffles around the issue but doesn't fix anything. The registration page has to be public. As a result if you made the lambda endpoint private, the web application which calls the lambda endpoint would still have to be public, meaning that the whole thing is still public. Spam filtering and CAPTCHA are the answers here. Hiding the lambda will just make more work for no benefit.
    – Conor Mancone
    Commented Mar 16, 2020 at 14:10
  • @ConorMancone Well, putting protections (such as spam filtering and CAPTCHAs) on the registration page doesn't do anything if they can be bypassed by sending a request directly to the lambda. So either the lambda endpoint needs to be where the protections are implemented, or it needs to be private and only reachable through the server that serves the registration page (and implements protections).
    – CBHacking
    Commented May 10, 2021 at 23:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .