To vet a form handler for a static site, confirm what data it receives, where that data is stored and for how long, how spam and abuse are controlled, who can read submissions, and how you would export and leave. Then test the endpoint like any other API before you publish the page.
A static page cannot process a form on its own, so most sites send submissions to a hosted handler or a serverless function. That handler becomes a data processor for anything visitors type.
The seven checks
- Data inventory. List every field. A "contact us" form that also asks for a phone number or a company size is collecting more than a message. Remove fields you do not need.
- Storage and retention. Find out where submissions live, how long they stay, and whether you can delete them. If the form collects personal data, your privacy notice and processor agreements should match what the handler really does.
- Transport and endpoint. The form action must be an HTTPS URL. Confirm the handler does not redirect submissions through other domains you did not expect.
- Spam and abuse controls. Look for rate limiting, a honeypot field or a challenge. Without them the endpoint will fill with junk, and notification emails can become a flood.
- Access to submissions. Who can log in, with what authentication, and can you require multi-factor sign-in? Submissions often hold names and email addresses that a breach would expose.
- Notification path. Many handlers email each submission. Email is not a secure channel for sensitive content, so do not collect sensitive content in the first place.
- Exit plan. Can you export all submissions in a standard format? Can you swap the endpoint in one place, such as a single configuration value?
Test the endpoint yourself
Treat the handler as an API you are about to depend on.
- Submit with an empty body, an oversized body and unexpected field names. Note the error responses. Verbose errors can reveal internals.
- Submit from a different origin than your site. See whether the handler accepts or rejects it, and read the response headers. MDN explains that cross-origin requests from a browser depend on the server's CORS response headers, so the handler's header choices decide which sites can post from a browser.
- Check that a successful response does not echo back other users' data.
Self-built handlers
If the handler is your own serverless function, apply the same checks, plus ordinary code hygiene: validate input on the server, keep the dependency list short, scan it, and store any API key for an email or storage service in the platform's secret settings rather than in the repository. See ten serverless security practices.
Decision table
| Situation | Reasonable choice |
|---|---|
| One simple contact form, low volume | Hosted handler, minimal fields, spam control on |
| Forms that collect personal or regulated data | Own function or a vetted processor with a signed agreement |
| Many forms and custom logic | Own function with a scanned dependency set |
Where Safeguard fits
If you write the handler yourself, Safeguard can scan its dependencies and add a policy gate on pull requests. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is a honeypot field enough to stop spam?
It stops simple bots. Add rate limiting if the form matters, because a determined sender can skip the honeypot.
Do I need a privacy notice for a basic contact form?
If you collect personal data such as a name and email, yes in most places. Ask your counsel for the rules that apply to you.
Sources
- MDN, Cross-Origin Resource Sharing (CORS): https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS
Last reviewed: 19 October 2026.
