Hasty Treat - Forms, Captchas, Honeypots, Dealing With Malicious Users and the Sad State of Contact Forms

Episode Summary

Executive Summary: The episode explores how to protect web forms from spam, bots, and abuse while preserving usability. Scott and Wes compare four main defenses—honeypots, IP throttling, blocking known ASNs, and CAPTCHAs—discussing when each works, where they fail, and why combining methods is often best. They also weigh privacy, accessibility, VPN friction, and the tradeoff between DIY solutions and paid services.

Main Topics: Why web forms need abuse protection: The hosts explain that contact forms, password resets, signups, and similar endpoints are easy targets for bots and malicious scripts if left unprotected, creating spam, user frustration, and transactional email abuse. Honeypot fields as a lightweight defense: They discuss hidden or non-obvious form fields intended to catch bots, noting that some developers find them effective while others see limited real-world protection, especially when bots become more sophisticated. IP throttling and rate limiting: The episode covers limiting repeated submissions from the same IP as a simple anti-abuse layer, with discussion of Cloudflare-style rules, replay delays, and limitations when legitimate users share an IP address. Blocking known ASNs and hosting providers: They describe how malicious traffic often comes from cloud/VPN infrastructure and how blocking or challenging traffic from known abused ASNs can reduce spam, though it risks false positives for legitimate VPN users. CAPTCHAs and their tradeoffs: The hosts compare soft captchas, Google reCAPTCHA, and hCaptcha, arguing that CAPTCHA is often the most effective but also the most annoying and privacy-intrusive option for users. Privacy, accessibility, and user experience concerns: They note that anti-bot systems can break accessibility, autofill, ad-blocked pages, and VPN use, and that integrating third-party services like Google can conflict with privacy-focused site philosophies. Build vs. buy for form handling: The discussion closes with a preference for teaching self-hosted solutions instead of outsourcing everything to services, to avoid long-term cost creep and platform dependence.

Key Arguments: Forms that send emails or trigger account actions cannot be treated as simple HTML inputs; they need anti-abuse controls from the start. Honeypots can stop some automated spam, but they are not universally reliable and may be bypassed by smarter bots. IP-based rate limiting is useful against unsophisticated attacks, but it can also block legitimate users on shared networks or universities. Blocking cloud/VPN ASNs can be effective because many bots run from hosting providers, but it can frustrate real users who rely on VPNs. CAPTCHA remains the strongest general-purpose defense, but it is the most disruptive to user experience and sometimes privacy. A layered approach is often better than relying on a single method, especially for valuable endpoints like password resets and signups. Using third-party form/security services can solve the problem quickly, but it adds ongoing cost and potential vendor lock-in.

Data Points: Course-related form handling: 1 contact/order form - Wes describes a Gatsby course example where a form sends an email and needs anti-spam protection. Twitter poll response: ~80% - Scott says about 80% of respondents said a honeypot is enough for most use cases. Rate limiting example: 2 submissions within 10 minutes - The hosts cite simple throttling rules that limit repeated sign-up attempts in a short window. Brute-force slowdown example: 6 hours - They mention systems that increase wait times after repeated failed attempts, similar to device unlock delays. VPN/CAPTCHA friction example: 800 photos - Scott exaggerates the volume of image selections sometimes required when CAPTCHA distrusts VPN traffic. Fraud/spam scale example: 1,000 a minute - Used to illustrate how badly a malicious actor could abuse password reset or form endpoints. Version reference: v2 and v3 - Google reCAPTCHA versions are discussed, including confusion over the differences between v2 and v3.

Pivotal Quotes: "The clear one is to put a captcha on it, but captcha suck." — Scott Tolinski: Scott opens the tradeoff discussion by admitting CAPTCHA is effective but unpleasant for users. "The unfortunate thing with web development is that the first 90% of it seems all easy, and then you have to get into this little weird area." — Scott Tolinski: He explains why forms become complex once abuse prevention is required. "The scammer's got to ruin everything for everybody, huh?" — Wes Bos: Wes reacts to how spam and abuse force restrictive measures that also inconvenience legitimate users.

Implications: Developers should assume forms will be abused and layer defenses instead of shipping naive endpoints. The best solution depends on risk, privacy goals, and user tolerance, but a balanced mix of honeypots, throttling, ASN filtering, and CAPTCHA is often necessary.