We have a honeypot in place that limits form submissions based on several criteria. It's been in place for a couple of years now with no issues so our thinking is that we are covered in that aspect. |
Unless you can prove that the your server will never let more than 30 form posts in per minute, it isn't protecting you. 30/m is extremely easy to exceed if you have a popular send (or, for that matter, a very unpopular one that sends people screaming for the Unsubscribe form). And that's outside of malicious hits. Once a mildly skilled hacker hooks up an old 56K modem (just kidding, they would actually use multiple bots, but the fact is they could use a modem for a rate this low).
I hope your server bears in mind that IPs are shared (that is, your server can't simply allow post per IP per <unreasonably long period>). If that same popular send engages multiple people at the same company and location, chances are they're sharing the same IP. (Same reason that Marketo's limit is strict, but not unreasonably draconian, since they have to allow for a certain pace of legit posts from the same IP.)
In sum, unless I knew what rules you were following on the server I couldn't say one or the other. Certainly you could mirror Marketo's rule and limit to 30/m from the same remote IP.
I don't want anyone to throw their hands up and say whatever you dumb ***** want to do (lol) so if you feel strongly that this is a bad way to go, just say so. |
I do think it's a bad design: you must avoid rate limits if you want to claim to be resilient. Marketo's servers are designed for massive form traffic, so use them.
Such a trivial thing that could be solved by simply allowing id's to form elements... |
What exactly do you want a form's HTML fragment to look like? Surely this can be done with a touch of JS.
.png)