Add a contact form to an Amazon S3 static website

An S3 website endpoint answers a form POST with 405 MethodNotAllowed, so point the form's action at your Ikiform endpoint instead. Because the endpoint is plain http:, a _redirect back to it is never followed; set Redirect after submit in the form's settings, or put CloudFront in front for https:. With CloudFront in front of the bucket's REST endpoint, redirect to a full file name such as thanks.html, because the default root object applies only to the root.

What's different on S3

A bucket configured for static website hosting gets its own website endpoint, such as http://www.example.com.s3-website-us-east-1.amazonaws.com. AWS documents that it supports only GET and HEAD requests on objects. A form post gets an HTML error page:

<html>
<head><title>405 Method Not Allowed</title></head>
<body>
<h1>405 Method Not Allowed</h1>
<ul>
<li>Code: MethodNotAllowed</li>
<li>Message: The specified method is not allowed against this resource.</li>
<li>Method: POST</li>
<li>ResourceType: OBJECT</li>

Three more S3 traits shape the contact form:

For an https: site, AWS recommends Amplify Hosting, which runs on CloudFront, or CloudFront in front of the bucket. The form works either way. What changes is where the visitor ends up after sending.

Which CloudFront origin

CloudFront can read from the bucket in two ways, and the choice decides how your thank-you URL must look:

A full file name works with both, which is why the samples use one. If you'd rather not run CloudFront yourself, Amplify Hosting can deploy from the bucket with https: and a managed CDN; the form needs no change there either.

The form

S3 sites are often company sites, so this form asks for a work email and the company name. Upload it as contact.html next to thanks.html:

<form action="https://ikiform.com/f/frm_xxxxxxxxxxxxxxxx" method="post">
  <label for="name">Name</label>
  <input id="name" name="name" autocomplete="name" required />

  <label for="email">Work email</label>
  <input id="email" name="email" type="email" autocomplete="email" required />

  <label for="company">Company</label>
  <input id="company" name="company" autocomplete="organization" />

  <label for="message">How can we help?</label>
  <textarea id="message" name="message" rows="6" minlength="10" required></textarea>

  <input type="hidden" name="_redirect" value="https://www.example.com/thanks.html" />
  <input name="_gotcha" type="text" tabindex="-1" autocomplete="off" hidden />
  <button type="submit">Send</button>
</form>

• The _redirect points at the CloudFront domain, with a file name. It's followed only when www.example.com or example.com is under Allowed domains.
• On the bare http: endpoint, remove the _redirect input and set Redirect after submit to the thank-you page instead. That setting accepts http: URLs, because only your team can change it.
• Keep email as the field name. Notification emails use it as the reply-to address.

On a company site, more than one person usually reads the contact inbox. Add up to 10 confirmed notification recipients to the form; each gets the message, and whoever presses Reply answers the sender directly. If messages should also reach a shared channel or a ticket queue, add a signed webhook and route it through Zapier or your own code. The company field arrives as plain text, so it's ready to filter on in either place.

Before you upload, test the page from a local server with localhost under Allowed domains. Posts from localhost count as tests, so you can get the form right before the bucket ever serves it.

Sync the folder to the bucket, and invalidate the pages in CloudFront so the new form is served right away:

aws s3 sync ./site s3://www.example.com --delete

aws cloudfront create-invalidation --distribution-id E1EXAMPLE --paths "/contact.html" "/thanks.html"

Allowed domains on AWS hosts

Never add amazonaws.com, a regional s3-website suffix or cloudfront.net on their own. Every bucket or distribution in the world would match. AWS registers the S3 website endpoint domains in the Public Suffix List for the same reason: each bucket is a separate site.

Headers through CloudFront

S3 object metadata can't set a Content-Security-Policy, so set it in a CloudFront response headers policy and attach it to the distribution's default cache behavior. The header value is limited to 1,783 characters:

{
  "Name": "site-csp",
  "SecurityHeadersConfig": {
    "ContentSecurityPolicy": {
      "Override": true,
      "ContentSecurityPolicy": "default-src 'self'; form-action 'self' https://ikiform.com; connect-src 'self' https://ikiform.com"
    }
  }
}

aws cloudfront create-response-headers-policy --response-headers-policy-config file://csp-policy.json

Check it works

1. Add the domains from the table above, plus localhost while you test.
2. Submit from your CloudFront domain. You should land on thanks.html on your own domain.
3. If you also keep the bare website endpoint public, submit from it and confirm you reach the page set in Redirect after submit.
4. Open Submissions in the dashboard. The new submission is there with every field you sent.
5. Check the inbox of each notification recipient. Each gets an email with the fields, and Reply goes to the submitter when the form has an email field.
6. Nothing arrived? Switch the dashboard's status filter to Spam. Spam gets the same success answer as a real submission.

Gotchas

Questions