Three myths about rate limiting

The advice here is unglamorous, which is probably why it gets skipped. A few things about rate limiting that get repeated more often than they get checked.

The cheapest security work is the boring kind done on a schedule. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

“It only matters for big sites”

Unlimited endpoints get abused eventually. This is the sort of thing that compounds, quietly, in both directions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

“We can deal with it after launch”

Sometimes true, usually expensive. Small and consistent beats large and occasional here.

“Our platform handles it”

Return a clear response instead of failing silently. None of that requires a large budget, only a decision and someone to own it. The version that survives contact with a real deadline is the simple one.

What this looks like day to day

Security is a maintenance habit rather than a purchase, which is why it drifts. Three things worth confirming about rate limiting before you move on:

• Someone can say what the current setup is without going to look
• Limit by account and by address — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.