Tag Info

New answers tagged


If in generating the page you add a hash token based on timestamp plus a secret then by including the timestamp and token in each request you can make it harder to craft attacks. The token can be checked without recourse to the database. Any request with a timestamp that is too old should also be rejected. If this is a one-page app or similar where the page ...


You cannot avoid the cost of a lookup: at one point, you will have to perform one if only to see if the sender is blacklisted or not. So, your best option is probably to make sure a token lookup is quick enough to handle the load. However, you should still keep a trace in your DB of invalid attempt with associated source. Such a trace should make it easy ...


Fail2ban is a nice option, but it will create some problems if a sizable part of your userbase is behind a proxy, and someone on that proxy abuses your service and locks out every single user of the proxy. You probably have a traditional database (MySQL, Postgres, Oracle, DB2) hosting your data, but the overhead of the tokens are too high for them. You ...


You might try to use fail2ban or similar software and implement a "request limit" rule. It will be based on the IP address but you will not need to have a check in your database for every request. Moreover, when an IP will be blacklisted, it will not reach your webservice anymore as the firewall will block the incoming request before.

Top 50 recent answers are included