The attack nobody sees arrives through your site's contact form

Everyone protects the login. Nobody looks at the contact form. And yet it accepts input from anyone, with no authentication, no friction, often not even a cap on submissions.

That's the asymmetry an attacker hunts for. A text box that talks to your email server, your database, or an internal webhook. You see a "message" field. They see a command line.

Why this target is so tempting

A contact form gathers three rare properties in one place. It accepts untrusted input. It runs logic on the server. And it's almost never audited. The developer tested that the message reaches the inbox. They stopped there.

The trouble is that "the message reaches the inbox" hides an entire path. The user's text gets assembled inside an SMTP header, concatenated into a query, or forwarded to a third-party service. Every one of those boundaries is a chance to inject.

Email header injection

The classic case is email header injection. If you take the "subject" or "sender" field and paste it straight into the message header, an attacker writes a line break and adds their own headers. A Bcc to a thousand addresses, say.

Suddenly your server is sending spam. Not in your name by coincidence, but literally through your infrastructure, with your IP and your domain. The outcome is predictable: the big providers flag your domain as a spam source and your business email stops reaching anyone at all.

Text that turns into code

Then there are the worse scenarios. If you store the message in a database without parameterising the query, you open the door to SQL injection. If you show the message in an admin panel without escaping the HTML, the attacker plants a script that runs in your team's browser when they open the lead. That's stored XSS, and it's one of the most underrated vectors around.

Notice the pattern. In none of these cases did the attacker "break in" to anything. They used the form exactly as it was designed to be used. The vulnerability isn't some exotic flaw. It's the absence of one simple rule: never trust what comes in.

What to do, in order of priority

You don't need a WAF or a security consultant to close 90% of this. You need discipline on four points.

• Validate on the server, never only in the browser. Front-end validation is a comfort for the user, not security. The attacker doesn't use your form, they POST straight to the endpoint.
• Escape on output, always. When writing to a database, use parameterised queries. When displaying in a panel, escape the HTML. Treat every message as hostile until proven otherwise.
• Reject line breaks in header fields. Subject, name and email have no reason to contain \r or \n. Filter them out before touching SMTP.
• Rate-limit submissions and add an invisible challenge. Per-IP rate limiting and a honeypot or hCaptcha stop automated bots without ruining the experience for real humans.

And the side almost everyone forgets

A contact form collects personal data. Name, email, often phone number and the content of the message. That puts you inside the GDPR, whether you like it or not. You need a lawful basis to process that data, and consent has to be informed.

In practice that means three concrete things. A clear privacy notice linked to the form. A defined lawful basis, typically the legitimate interest of Article 6 or explicit consent. And a retention policy, because keeping leads forever isn't a strategy, it's accumulated liability. If someone steals your lead database, the problem stops being technical and becomes regulatory.

Form security isn't an expensive firewall. It's refusing to trust the text a stranger wrote.— Krivar Diário

The moral is dull, and that's why it works. The attack nobody sees arrives through the door nobody watches. Treat your contact form with the same respect you give the login, and most of these problems never happen at all.