Using NGinx as an example:
if ($server_protocol != HTTP/2.0) { return 403 'Nope'; }
Using IPTables as an example:
/sbin/iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 420:16384 -j DROP
MSS issues attract me like a moth to flame [1], so let me ask some questions.
It looks like this is dropping syns with MSS over 16384??? That is indeed a pretty crazy high number. 9000ish seems reasonable for someone on a jumbo network without a mss clamping router, but above that is someone weird for sure.
Under 420 seems unlikely too, but technically acceptable, but sure, I'd drop it. In theory, a proper OS will send several SYNs with MSS, then assume your server doesn't support TCP options and send you a SYN with no options. Going to take a while, but if someone legitimately has a mss less than 536, their internet is probably pretty junky anyway, so ok, seems fine.
[1] I just built a browser based pmtud test site, http://pmtud.enslaves.us/
All of this said, I could set the range to 1:65536 and it would still drop most bots as they don't even bother to set MSS at all in their scans. I'm not sure which tool they are using.
Oddly enough most of the bots in Asia are exactly 1398 and most of the bots in Russia are 1424. I find that interesting.
It's an arms race/defense-in-depth situation. If someone truly wants to automate your site in a targeted fashion, and it's profitable for them to do so, you'll have to invest a lot more in stopping it (and decide how much of it is worth stopping).
My college English professor was so obsessed with beating cliff notes that all of tests were hyper focused on the most obscure details he could dream up. It was just impossible to maintain a full course load and memorize what was the 1st, 3rd, 5th, 7th , last, etc word on every page and which character spoke it. Did the sentence contain any commas? How many times was the nurse mentioned in chapter X, etc.
Google can always follow his lead and make their data impossible to access, but impossible doesn’t increase ad views, so they will never do it. People using ytdlp is just the cost of doing business.
As long as you're using a <label> or aria-label attribute, that shouldn't be an issue.
(Author here.) If I remember correctly, his browser of choice predates the Origin header.
In general though the whole tone of parent of “I am owed access to someone else’s computer system on my and my terms alone” just doesn’t jive with me. It’s also not remotely comparable to Cloudflare’s approach of sitting in the middle snd then appropriating end-user compute resources without their consent to fuel their business.
Lets read through that page for a second though:
Doesn't seem like that's going to cause much issue for any legitimate client from the past 10-20 years. He only recommends blocking HTTP 0.9/1.0, which fair enough Hah. Clever man. I don't see how this is going to stop any legitimate user from loading your website or submitting the form, but I can see how it might frustrate bots. This is just standard practice to mitigate CSRF. Yes. You should be doing that. Another CSRF trick. This one's a little user hostile to folks who use assistive devices like screen readers. But still won't prevent you from accessing the site in the first place. As noted by the author, might cause some issues but again, won't stop anyone from loading your website. Alright please just don't do this. UA blocking is gross and might prevent access through specialist software. But he also calls this out himself. All in all, with the exception of UA blocking I don't see how any of these mitigations would result in users not being able to access said website, or having their loading times drastically increased.