Implement the rate limiter as HandlerInterceptor (decouple business logic from rate limiting)
Use the clients ip for rate limiting, not the SecHub job id. Someone could just generate a new job id with every request and bypass the rate limiter.
Define a meaningful rate limit strategy. Ideally we can also configure this through env variables on deployment.
Handle distributed rate limiting for multiple instances. This could be solved through a in-memory cache like Redis (cloud environment) or our Postgres database (no cloud). To keep things simple we should just use the database. There are JDBC extensions for bucket4j which allow easy integration with the data source in Spring.
The response code should be 429 Too Many Requests
Rate limiter should log blocked requests. What do we do with this information? Do we need to know if someone is trying to attack us? Keep in mind to not log sensitive client information like the ip address.
Situation
Currently we have no rate limit for SecHub API
Wanted
A configurable rate limit for REST api calls.
Solution
Spring way
Spring Boot seems to have an embedded support for token based quota. Maybe we should use this to restrict?
https://www.baeldung.com/spring-bucket4j#token-bucket