Stopping Malicious Actors

Episode Summary

Executive Summary: The episode explains how developers can defend websites and APIs from malicious actors without overly disrupting legitimate users. The hosts cover practical defenses like rate limiting, cookie/IP-based controls, shadow banning, nonces/CSRF tokens, CAPTCHAs, DDoS protection, and ASN blocking, while emphasizing the tradeoff between security and user experience.

Main Topics: Threats from malicious actors: The hosts describe common abuse patterns: form spam, API scraping/reverse engineering, fake signups, resource exhaustion, comment spam, and script injection. Rate limiting strategies: They discuss limiting actions by IP, cookie, time window, and attempt count as a primary defense, including how legitimate users can be accidentally blocked. Shadow banning and account-based restrictions: A technique for disabling abusive users without notifying them, making their interface appear normal while preventing effective abuse. Nonces and CSRF protection: Tokens required to validate form submissions and prevent direct or cross-site request abuse of sensitive actions like account creation or payments. CAPTCHA and human verification: The episode compares CAPTCHA options, noting usability issues with reCAPTCHA and more user-friendly alternatives, while acknowledging bots are getting smarter. Infrastructure-level defenses: They discuss DDoS protection, Cloudflare-style edge filtering, and blocking ASNs from known-bad hosting providers.

Key Arguments: Malicious abuse is often automated at scale, so defenses must be proactive rather than reactive. Rate limiting is effective but can mistakenly block legitimate users sharing an IP, such as a classroom or office network. Shadow banning can frustrate abusers by making their actions appear successful while neutralizing their impact. Nonces and CSRF tokens protect endpoints by ensuring requests are authorized from a real page load or trusted flow. CAPTCHAs reduce abuse, but they trade security for friction and can become less effective as bots improve. Blocking known bad ASNs and using edge/serverless middleware can stop abuse before it reaches the core application.

Data Points: Rate limit example: 10 tries every 15 minutes - Wes describes an IP-based rate limit that accidentally affected a classroom signup flow. Class size affected by rate limiting: 100 students - A teacher’s class was blocked because all students shared a single IP address. DDoS illustration scale: 1,000 times per second - Used as an example of repeated page hits causing strain on a server. DDoS illustration scale: 100,000 times per minute - Used to emphasize how high-volume requests can take a site down. Support duration from sponsor offer: 2 months free - Mentioned for Sentry’s coupon code offer. Sponsor credit: $100 in free credit - Linode promotional offer for new users.

Pivotal Quotes: "I think of as a shadow ban. It's like basically you're removing their features, but to them, they don't see that as their features are removed necessarily." — Wes: Explaining how shadow banning can disable abusive users without alerting them. "You don't have any tickets, right?" — Scott: Analogizing nonces/tokens to needing a ticket before being allowed to perform an action. "It's not if somebody is going to do it, but when that type of things happen, and you don't want to have to be scrambling when that type of thing happens." — Wes: Arguing for proactive security measures like rate limiting and CAPTCHAs.

Implications: Listeners should assume abuse will happen and build layered defenses early. The broader lesson is to balance security, UX, and infrastructure controls so legitimate users stay unblocked while bots and attackers are slowed or hidden.