Don't allow untrusted input to determine the bounds of recursion implicitly*.
And as usual, this is padded out with ill-fitting AI-generated stuff following textbook AI patterns. The only insight here is to add an explicit recursion depth guard - which follows automatically from an understanding of the issue. But the identified problem is crashing the process, which would be equally well dealt with by just handling the exception. (There's also a weird reference to the C++ API documentation despite that everything else shown is about Java.)
The overall structure is rigid, and yet the plot wanders. The introduction promises: "Read on to learn about how we discovered these issues and how to prevent them" - but nothing else in the article is actually about the discovery process (how did they develop and run the CodeQL query? How did they obtain data for it?); it just shows the general form of the vulernability, a single detailed case study and then one of the standard mitigations.
Oh, and of course: why on Earth would it be necessary to use a bullet-point list - consisting of two bullet points, where one of them is "audit your code" - to explain the fix?
This post wasn't written by AI (I didn't write it, but I know the people who did).
The reason it's so short is because it's just a summarization of a larger paper[1] and talk[2]. This is mentioned explicitly in the second paragraph of the post as well as at the end.
(You're right that there's nothing so special about adding a depth guard -- it's CS 101. It's not intended to be communicated as profound; the thing that's supposed to be interesting is that actual vulnerabilities still fall out of this, as the post is meant to tease.)
[1]: https://resources.trailofbits.com/input-driven-recursion-whi...
[2]: https://www.districtcon.org/bios-and-talks-2025/low-effort-d...
Since iteration is a special case of recurson, this also tells us not to let user input cause an infinite or too-long-running loop. Profound, eh?
This is a good point, but recursion and iteration have very different security implications in practice. Iterative functions are much harder to exploit.
It doesn't take many stack frames to overflow the stack. Java only handles ~10k frames by default. Most applications will have no problem with 10k loop iterations, and it might take millions to cause a notable slowdown. It is usually trivial to craft an input causing ~10k recursive calls, but an input causing millions of iterations is likely much harder. One example from the whitepaper that crashed a real application is a string repeated 20k times taking up ~200KB. To get to one million iterations the request would be ~20MB.
The failure modes also differ significantly. Recursion crashes the application with a stack overflow. Iteration just ties up a thread. Web frameworks often auto kill busy threads after timeout anyway.
You could argue that catching StackOverflow exceptions is a built in defense as well, but that only works for langauges that support catching such exceptions. Even among those languages, there are many DoS CVEs for crashes caused by stack overflows.