How to protect a feedback form from spam

Why feedback forms attract spam

A public feedback form is an open door. Anyone who finds the endpoint can post to it, and some of them post links, fake reviews or scripts that waste your time. The risk is not that spam breaks anything. The risk is that it fills the inbox until real customers get buried and your team stops reading.

Spam usually arrives in one of three ways: a bot that fills every input on a page, a script that calls the API directly from outside a browser, or a person who pastes the same text over and over. Each needs a different control, so one measure is rarely enough.

Use a honeypot field, not a puzzle

A honeypot is a form field that real people never see and never fill in. The Escuta Produto widget includes one. It is an input named website, positioned far off screen, with tabindex set to -1, aria-hidden set to true and autocomplete turned off. A visitor using a keyboard or a screen reader skips it, and a visitor who only sees the panel never fills it in.

Bots that fill every input they find will fill it in too. The widget sends its value with every submission, so any value there is a signal. That is the whole idea: the field costs real people nothing and gives automated submissions a place to reveal themselves.

Two limits apply. A honeypot does nothing against a script that calls your API directly and ignores the form. And a bot that is smart enough to skip hidden fields will get past it. The honeypot is one layer, not the defense.

If you build your own form instead of using the widget, copy the same pattern. Give the field a name that looks tempting, such as website or company, hide it with CSS rather than type="hidden", and reject any submission where it has a value.

Allowed origins and their limits

Each product in Escuta Produto has a list of allowed origins. Only these sites can submit feedback through the widget. If a submission arrives from a site that is not on the list, the API answers with a 403 and an origin-not-allowed error, and nothing is saved.

This check is useful because it stops casual abuse. Someone who copies your widget snippet to a site you do not own will be refused. But know its limit. The origin is a header that a browser sends. A script running outside a browser can set any origin it likes. Treat the allowed list as a filter for abuse that starts in a browser, not as proof that a submission came from a real visitor.

Keep the list accurate. Add every production domain and staging domain you use, and remove old ones. If the widget stops working after a domain change, the allowed list is the first place to look. Also check the widget docs for the exact origins to add, including any subdomains you use.

Rate limits and size limits

Escuta Produto limits each IP address to 10 requests per minute per product. A visitor who sends more gets a 429 response, which the widget shows as an error. A real visitor rarely sends ten messages in a minute, so the limit rarely touches real people, but it stops a loop from flooding the inbox.

Size limits protect the server and the inbox. The API refuses a request body over 16 KB with a 413 response. In the widget, the message box stops at 5,000 characters, and the email box stops at 254. A message that long is almost never feedback, and the cap keeps a single submission small.

Rate limits work per IP address, so a shared office network can hit the limit faster than a single home connection. If that happens, slow the flow down with clearer wording, not a looser limit.

Why CAPTCHAs cost more than they stop

A CAPTCHA is the usual first idea, and it is often the wrong one for feedback. A puzzle asks every visitor to do work before their message counts. People on phones, people with low vision, people who use assistive technology and people who are simply in a hurry all pay that cost. Someone who gives up after one failed puzzle is a customer you lost, and you never see them in the inbox.

CAPTCHAs also do not stop a determined spammer reliably. Solving services exist, and automated tools can work around many puzzles. So the trade is poor: real customers pay the cost of every puzzle, while a motivated spammer can still get through.

A practical rule: keep the form free of puzzles, use the honeypot, the origin list and the rate limit, then watch the inbox. Only add a CAPTCHA if a specific abuse pattern survives those controls, and only on the page where it happens.

How Escuta Produto handles spam

The widget does not include a CAPTCHA. It combines the controls described above: the honeypot in the form, the allowed origins per product, the rate limit per IP address and product, and the size limits on the message and the request body. Each product also has a key that can only create feedback, never read it, so a leaked key cannot expose your inbox. If a key is abused, rotate it in the product settings and update the snippet on your site.

For setup, the widget docs show the snippet and the allowed origins. The REST API docs list the status codes you should handle in your own form, including the 429 and 413 responses. For the message itself, read how to triage customer feedback, which covers closing spam with a short internal note so it stays closed. For how the widget handles visitor data, read feedback widgets, GDPR and LGPD.

Spam will still reach you sometimes. That is normal. Set a weekly routine that closes obvious spam, keeps the inbox short and leaves real messages for a proper read. The controls reduce the noise, and the routine keeps the rest manageable.