Serverless Contact Form

The portfolio is a static site: HTML, CSS and JavaScript in an S3 bucket, served through CloudFront. That architecture is fast, cheap and very hard to break. It also has no process running anywhere that can receive a POST, no runtime, and no way to hold a credential. A contact form on a site like that needs somewhere else to send its data.

Three approaches were considered. A mailto: link needs no infrastructure but depends on a configured desktop mail client; on a phone or in webmail it often does nothing, the visitor sees a broken link, and the site owner never learns anyone tried. A third-party form service is quick and usually well built, but it puts an outside company in the path of a core site function and routes visitor messages through it. A self-hosted serverless backend is more work up front, keeps the message path inside infrastructure I control, costs effectively nothing at portfolio volume, and teaches SES, Lambda, IAM and CORS in a place where mistakes are cheap.

I chose the third. All three are close to free at this volume, so cost did not decide it. Control and learning value did.

Requirements, fixed before any resource existed

• Deliver each message to a single inbox
• Accept submissions only from the portfolio's own origin
• Never silently lose a message
• Hold no credentials in client-side code, which is public by definition
• Be cheap enough to leave running indefinitely without thinking about it

Amazon SES provides a verified sending identity. A Lambda function receives the submission, validates it and calls SES. An IAM role grants that function exactly one permission. A Lambda Function URL exposes the function to the browser over HTTPS. Configuration lives entirely in environment variables, so the deployed code contains no addresses and no secrets.

Why the endpoint has no API Gateway

API Gateway is a genuinely capable front door: request validation, throttling, usage plans, custom domains, WAF integration and staged deployments. This endpoint needs none of that. A Function URL is an HTTPS endpoint with CORS configuration and very little else, which is an accurate match for the requirement — and removing a whole service from the design removes a whole service's worth of configuration that could drift.

The costs were accepted with eyes open rather than discovered later. Abuse protection has to come from reserved concurrency or logic inside the handler. And because the auth type is NONE, CORS becomes a browser-side convenience rather than a security boundary, which section 07 addresses directly.

Lambda creates an execution role automatically, and that role starts with the three CloudWatch Logs actions the function needs to write its own logs — and nothing more. Sending email needs an additional grant, and this is where convenience is most tempting. Attaching AmazonSESFullAccess would work immediately. It would also let the function delete identities, alter the suppression list and read sending statistics.

Instead, a hand-written inline policy grants exactly one action. If the function were ever compromised through a payload-handling bug, the attacker inherits the ability to send email and nothing else.

Tightening the resource is not cosmetic. Today a compromised function could send as any verified identity in the account. Scoped to one identity ARN with a From-address condition, it could send as one identity, from one address. The difference is small in policy JSON and large in an incident report.

A Lambda function that catches an SES exception and returns normally still produces an HTTP 200. A client that treats 200 as success will then tell the visitor their message was sent when it was not. The visitor closes the tab, and the message is gone — with nothing in the browser that looks like an error, because from the browser's point of view nothing failed.

The handler therefore reports its own outcome in a success field inside the response body, and the client checks that field rather than the status code. The two last steps of the request path look redundant. They are the difference between a form that is honest and a form that lies politely.

This is graceful degradation applied to a contact form. The failure mode was designed with the same care as the success path, on the reasoning that the failure path is the one a visitor meets on the system's worst day — and, as it turned out, on its first.

The browser console reported that the request had been blocked by CORS policy: the Access-Control-Allow-Origin header contained multiple values where only one is permitted. The network entry showed a 200 alongside a failed fetch — exactly the combination the response contract anticipated.

Root cause

CORS headers were being applied in two independent places. When Function URL CORS is enabled, the Lambda service attaches the appropriate headers as the response passes through. The handler was also constructing the header from ALLOWED_ORIGIN and returning it explicitly. The response reached the browser with the header twice, the specification requires a single origin value, and the browser rejected it — after the function had already run to completion.

Why it was easy to make

This class of bug is characteristic of platform features that overlap with application code. The Function URL's CORS panel presents itself as the way to configure CORS, and it is. The handler setting its own headers is also correct, and is what the code would need behind API Gateway or any other fronting service. Individually reasonable, jointly broken, and nothing in either interface warns about the other.

Resolution

CORS was disabled on the Function URL, leaving the handler as the single authority. Ownership in code was chosen for two reasons: the permitted origin stays with the rest of the configuration in environment variables, and the header logic travels with the code if the endpoint is ever moved behind API Gateway. The reverse — deleting the header code and relying on the platform — would have been equally valid. What matters is that exactly one layer owns the header.

What it cost

Nothing. It happened on a test submission, and the recovery path told the truth. Had the client trusted the 200, the same bug would have produced a form that appeared to work perfectly while discarding every message it received — the kind of defect discovered months later, by accident, when someone mentions they wrote and never heard back.

The single most important property of the design is that it holds no long-lived credentials. The function receives temporary credentials through its execution role, and that role can do one thing beyond writing its own logs. There is no access key in the client, the function source or the environment variables.

The endpoint itself is public. With auth type NONE, Lambda performs no authentication and the resource-based policy permits invocation by any principal. CORS restricts which origins a browser will allow to read the response; it does nothing whatsoever to stop a direct request from curl, a script or another server.

Abuse protection, in order of effort

• Set reserved concurrency on the function so a flood cannot scale without limit — a single setting that caps the worst-case bill
• Add a honeypot field that legitimate users never fill in
• Add a CAPTCHA or proof-of-work challenge to the form
• Apply simple per-IP rate limiting inside the handler

The SES verification emails were a smaller lesson in the same vein. Their confirmation links carried an access key identifier and a request signature as query parameters. They were single-use and long expired, but automated notification emails routinely carry credential material and deserve the same care as anything else when screenshotted.

AWS pricing changes and varies by region, so these figures are an indication of magnitude rather than a quotation. The conclusion that matters does not depend on them: the design has no idle cost, because no component runs between submissions.

The deployment loop

Deployment is manual and has three steps: edit the client script, upload it to the site bucket, and create a CloudFront invalidation across all paths. Skip the last step and visitors keep receiving the cached previous version of the script, which makes a correct fix look like a failed one. Manual is acceptable at this scale, and it is the obvious first candidate for automation.

The most consequential open issue

The FROM address belongs to a public mail provider whose domain the account does not control. SES cannot produce SPF or DKIM alignment for a domain it has no authority over, so outgoing mail fails DMARC alignment at the receiving end. The delivered message shows the symptom: recipients see it annotated as sent via the SES domain. Mail in that state is more likely to be filtered as spam, and strict recipients may reject it.

The fix is well understood. Verify the portfolio's own domain as an SES identity, publish the DKIM records SES provides, send from an address at that domain, and put the visitor's address in Reply-To so replies still reach them while the sender stays on a domain the account controls. The function's own source comments already describe this as the correct approach, which makes it a known shortcut rather than an unknown flaw.

One housekeeping item rounds out the list: the handler's header comment still describes an API Gateway deployment from an earlier plan. Stale comments are small, and they cost real time later.