Your contact form is a way in: how to secure it

A form is the one place on your website where anyone can type whatever they like and the site has to accept it. Usually it is a customer asking about a price or a date. Sometimes it is a bot that fills in forms on one site after another, all day long. And sometimes it is a person testing what the form will swallow without complaint.

That is why contact forms, order forms and appointment forms are among the first things an attacker looks at. Below are the risks, how to recognise them and what to ask the person who looks after your site.

A spam flood is more than a messy inbox

The most common problem is also the least dangerous, at least at first sight. Bots send hundreds of messages full of adverts and links through your form. The inbox fills up, and a genuine enquiry from a customer gets lost somewhere in the middle.

It gets worse when the form sends a confirmation or a copy of the message to whatever address was typed in. The bot then types in strangers' addresses, and your server sends them email from your domain. That quickly damages your domain's reputation: mail providers start treating it as a source of spam, and your real emails, invoices included, end up in your customers' spam folders. Your host may also block sending from the whole account.

If your form has a "send me a copy" option, ask whether you really need it.

Three attacks, one sentence each

The names sound alarming, but the principle is simple. Each of these works because the form trusts whatever someone typed.

Email header injection: someone types line breaks and extra addresses into the email or subject field, and a badly written form then sends messages from your server to any addresses they like.

SQL injection: someone types a fragment of a database command into a field, and a form that passes the text straight to the database runs it, which can reveal or change the data stored there.

Cross-site scripting (XSS): someone types a piece of script instead of their name, and when you open that submission in the admin panel, the script runs in your browser with your administrator rights.

Your developer protects you from all three: input is checked and filtered before it reaches an email or the database, and it is displayed in the admin panel in a way that cannot run. Popular, up-to-date plugins do this by default. The bigger risk is a hand-written form from a few years ago that nobody has looked at since. So ask directly whether your form comes from a plugin or was written from scratch, and if it was written from scratch, who last reviewed it and when.

Files from customers

Many forms let people attach a file: a CV, a photo of damage, a scanned document, a drawing for a quote. It is convenient, and it is also the riskiest part of a form.

The biggest danger is a file that pretends to be a picture but is really a program, for example one called invoice.jpg.php. If the server accepts it and lets it run, the attacker gets control of the site. So ask your developer to confirm that:

• the form accepts only specific file types, such as PDF, JPG and PNG, and checks what is inside the file, not just the end of its name,
• there is a file size limit,
• uploaded files go into a folder where the server runs nothing, ideally outside the public part of the site,
• saved files get new, random names.

What stays on your side is care when opening them. A Word document that asks you to enable macros as soon as you open it is a classic way to infect a computer. Remember too that CVs and photos sent to a clinic are personal data, sometimes sensitive, so do not keep them longer than you need to.

Captcha, honeypot and rate limiting

There are three ways to deal with bots, and they work best together.

A honeypot is an extra field in the form that people cannot see. Bots fill in every field, so if that one has something in it, the form quietly discards the message. Customers notice nothing, and the simplest bots are gone.

A captcha tells people and bots apart. Newer ones, such as Google reCAPTCHA v3, Cloudflare Turnstile or hCaptcha, mostly work in the background, without retyping letters or clicking on pictures of traffic lights. Keep in mind that they pass information about your visitors to another company, so your privacy policy should mention them.

Rate limiting caps how many messages can be sent from one address in a short time. Real customers are very unlikely to notice it, but it stops floods of spam and automated testing of the form. It is set up on the server or in a firewall service such as Cloudflare.

A honeypot plus rate limiting is usually enough to start with. Add a captcha if spam still gets through.

Where submissions end up and who can read them

A message from your form can end up in two places: an email inbox and the website's database. Some plugins only send an email. Others also save every submission in the admin panel, usually under a menu item called something like "Entries" or "Submissions". Log in and see which one applies to you.

Then answer a few questions for yourself:

1. Who has access to the inbox that receives the messages? Did anyone forward it to a personal Gmail account before they left?
2. Who has an administrator account in the panel? Every one of them can read every saved submission.
3. How long are submissions kept? Some plugins let you delete older entries automatically.
4. Does the page with the form run on HTTPS, with the padlock in place?

Every submission with a name, email address and phone number is personal data you are responsible for. There is more on what that means under GDPR in the article on GDPR and website security.

An up-to-date plugin, and one instead of three

Form plugins are among the most widely installed plugins there are, so attackers pay them close attention. Security holes are found and patched in them regularly, which is why an update to your form plugin should not sit in the queue for weeks.

While you are at it, check how many form plugins you have installed. Sometimes it turns out to be three: one from the first version of the site, one from the redesign and one that is actually in use. Delete the ones you do not use, rather than just deactivating them, because their files are still on the server.

And one habit that costs nothing: once a month, send a test message through your own form. Forms can stop working without any warning, and then the customer thinks you are ignoring them while you do not even know they wrote.