Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce rate limit for REST api #3288

Open
de-jcup opened this issue Jul 9, 2024 · 3 comments
Open

Introduce rate limit for REST api #3288

de-jcup opened this issue Jul 9, 2024 · 3 comments

Comments

@de-jcup
Copy link
Member

de-jcup commented Jul 9, 2024

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

@de-jcup
Copy link
Member Author

de-jcup commented Jul 9, 2024

We will close #2845 in favor of this one.

@de-jcup
Copy link
Member Author

de-jcup commented Jul 9, 2024

We close #2843 in favor of this one

@hamidonos
Copy link
Collaborator

hamidonos commented Jul 9, 2024

Bucket4J is a good solution for rate limiting.

We should also keep in mind:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants