Honeypot fields catch bots
Why it matters
Submission forms without honeypot fields let cheap bot scripts flood the platform with spam accounts, fake posts, comment payloads, and referral abuse at near-zero cost. That drives moderation backlog, pollutes search and recommendation surfaces, burns database rows and email quota, and erodes trust in user-generated content. Honeypots are a low-friction first filter that stops naive scrapers before they reach rate limiters or human moderators, complementing access-control defenses.
Severity rationale
Low because honeypots are a soft defense; missing them increases spam volume but does not directly breach accounts or data.
Remediation
Add a hidden decoy input to every public submission form with a plausible name like website_url or company, mark it aria-hidden="true" and tabindex="-1", and reject requests server-side whenever the field is non-empty. Enforce the check in the route handler, not in client JS, so headless bots cannot bypass it.
// src/app/api/posts/route.ts
export async function POST(req: Request) {
const body = await req.json();
if (body.website_url) {
return Response.json({ error: 'Spam detected' }, { status: 400 });
}
// ...continue processing
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Content Moderation & Safety Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- owasp:2021 · A04 — Insecure Design
Taxons
History
- 2026-04-18·v1.0.0·Initial import from community-moderation-safety·automated