Leanest way to prevent scripted abuse of a web app?

There is no way to achieve this with cookies, since a malicious script can just silently drop your cookie. Since you have to support the case where a user first visits (meaning without any cookies set), there is no way to distinguish between a genuine new user and a malicious script by only considering state stored on the client.

You will need to keep track of your users on the server-side to achieve your goals. This can be as simple as an IP-based filter that prevents fast posting by the same IP.

You should sit down and decide what exactly your "core" problems in the scenario of your app are, and who your likely users will be. That will help you guide the right solution.

In my experience, there are a lot of different problems and solutions in this subject - and none are a "one size fits all"

• If you have a problem with Anonymous users , you can try to migrate as much of the functionality behind an 'account wall' as possible.
• If you can't use an account wall, then you'll be better off with some IPbased tracking, along with some other headers/javascript stuff. Going by IP alone can be a disaster because of corporate proxies , home routers, etc. You'll run the risk of too many false positives. If you add in browser info, unsavory users can still fake it - but you'll penalize fewer real users.
• You might want an account wall to only serve as a way to enforce a cookie , or it might plug into the idea of having a site identity where experience earns privilege
• You might want an account that can map to another trusted site's account. For example, I generally trust a 3rd party account binding against Facebook - who are pretty decent at dealing with fake accounts. I don't trust a 3rd party account binding against Twitter - which is largely spam.
• You might only require site "registration" to need solving a captcha , or something else mildly inconvenient to weed out most unsavory visits. If the reward for bad behavior is high enough though, you won't solve anything.

I could talk about this all day. From my perspective, you have to solve the business logic and ux concepts first - and then a tech solution is much easier.

An extremely simple method that I have used before is to have an additional input in the registration form that is hidden using CSS (i.e. has display:none). Most form bots will fill this field in whereas humans will not (because it is not visible). In your server-side code you can then just reject any POST with the input populated.