1

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.

Saul
  • 11
  • 2
  • 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 Mar 16 '20 at 06:45
  • I've updated it. Yes, my concern is purely people hammering the public endpoint. – Saul Mar 16 '20 at 10:56

2 Answers2

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'.

roy.stultiens
  • 138
  • 8
  • 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 Mar 16 '20 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 May 10 '21 at 23:14
0

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.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142