starred/karakeep

Fork 0

mirror of https://github.com/karakeep-app/karakeep.git synced 2026-04-25 16:06:04 +03:00

[GH-ISSUE #2173] Karakeep triggers Crowdsec ban due to large amount of http requests #1333

New issue

Closed

opened 2026-03-02 11:56:35 +03:00 by kerem · 2 comments

kerem commented

2026-03-02 11:56:35 +03:00

Owner

Originally created by @narbux on GitHub (Nov 26, 2025).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/2173

Describe the Bug

As a start: this bug is probably not a bug in Karakeep, but a negative side effect of the design of Karakeep. I did think it would be good to mention it here in a bug report to see if the design of Karakeep could be adapted in the future. Or maybe this should be added to the FAQ / Troubleshooting / Security considerations page on the site of Karakeep.

My Karakeep instance runs on a VPS that has Crowdsec enabled on the reverse proxy to filter (potential) malicious requests. One thing Crowdsec does is banning ip's which it thinks are overloading the server, so filtering for (D)DOS attacks.

When loading the frontend/homepage of Karakeep with more than a couple of dozen of bookmark, each bookmark in view dynamically triggers two http-requests: one for the image and one for the data. On my screen 9-15 bookmarks are in view and it seems there are couple more below the direct view are loaded.

Add that to all JS and CSS file loads and this adds up to a lot: a fresh reload of the homepage triggers 92 http requests. Scrolling down a couple of times easily brings this up to more than 250.

As this all happens in milliseconds, Crowdsec thinks the user is starting a Denial of Service attack and blocks the ip-address.

Steps to Reproduce

Have Karakeep behind a reverse proxy that is monitored by Crowdsec
Have dozens of bookmarks
Load the homepage
See that Crowdsec bans the user IP

Expected Behaviour

I expect loading of all page assets be a bit less fanatic in the amount of requests.

A workaround I've implementend right now is the whitelisting of my home ip in Crowdsec (which was a good idea anyway). But this does mean I can't use Karakeep away from home. (or at least I can load the homepage and make a new bookmark, but scrolling down the homepage isn't possible)

Screenshots or Additional Context

Device Details

No response

Exact Karakeep Version

v0.28.0

Have you checked the troubleshooting guide?

I have checked the troubleshooting guide and I haven't found a solution to my problem

Originally created by @narbux on GitHub (Nov 26, 2025). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/2173 ### Describe the Bug As a start: this bug is probably not a bug in Karakeep, but a negative side effect of the design of Karakeep. I did think it would be good to mention it here in a bug report to see if the design of Karakeep could be adapted in the future. Or maybe this should be added to the FAQ / Troubleshooting / Security considerations page on the site of Karakeep. My Karakeep instance runs on a VPS that has [Crowdsec](https://www.crowdsec.net/) enabled on the reverse proxy to filter (potential) malicious requests. One thing Crowdsec does is banning ip's which it thinks are overloading the server, so filtering for (D)DOS attacks. When loading the frontend/homepage of Karakeep with more than a couple of dozen of bookmark, each bookmark in view dynamically triggers two http-requests: one for the image and one for the data. On my screen 9-15 bookmarks are in view and it seems there are couple more below the direct view are loaded. Add that to all JS and CSS file loads and this adds up to a lot: a fresh reload of the homepage triggers 92 http requests. Scrolling down a couple of times easily brings this up to more than 250. As this all happens in milliseconds, Crowdsec thinks the user is starting a Denial of Service attack and blocks the ip-address. ### Steps to Reproduce - Have Karakeep behind a reverse proxy that is monitored by Crowdsec - Have dozens of bookmarks - Load the homepage - See that Crowdsec bans the user IP ### Expected Behaviour I expect loading of all page assets be a bit less fanatic in the amount of requests. A workaround I've implementend right now is the whitelisting of my home ip in Crowdsec (which was a good idea anyway). But this does mean I can't use Karakeep away from home. (or at least I can load the homepage and make a new bookmark, but scrolling down the homepage isn't possible) ### Screenshots or Additional Context <img width="124" height="31" alt="Image" src="https://github.com/user-attachments/assets/7001514d-bbb7-49cd-9c2c-87cc9d4b334f" /> ### Device Details _No response_ ### Exact Karakeep Version v0.28.0 ### Have you checked the troubleshooting guide? - [x] I have checked the troubleshooting guide and I haven't found a solution to my problem

kerem

2026-03-02 11:56:35 +03:00

closed this issue
added the
bug

status/untriaged
labels

kerem commented

2026-03-02 11:56:36 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Nov 29, 2025):

The main reason this is happening is because of nextjs actually (the framework that we're using). nextjs by default preloads every single visible URL in the page such that when you click on it, you rarely see any spinners. I do agree that for some URLs maybe it doesn't make sense to preload (like the tags because there's usually a lot of them). However, at the same time, I don't think crowdsec's approach is the correct one (or maybe the limits are just too low). If you open Amazon's homepage, for example, you will see that just from a fresh refresh there is 400+ requests. So my recommendation here would be instead to consider having a more relaxed ratelimiting window in crowdsec.

@MohamedBassem commented on GitHub (Nov 29, 2025): The main reason this is happening is because of nextjs actually (the framework that we're using). nextjs by default preloads every single visible URL in the page such that when you click on it, you rarely see any spinners. I do agree that for some URLs maybe it doesn't make sense to preload (like the tags because there's usually a lot of them). However, at the same time, I don't think crowdsec's approach is the correct one (or maybe the limits are just too low). If you open Amazon's homepage, for example, you will see that just from a fresh refresh there is 400+ requests. So my recommendation here would be instead to consider having a more relaxed ratelimiting window in crowdsec.

kerem commented

2026-03-02 11:56:36 +03:00

Author

Owner

@kazoob commented on GitHub (Jan 2, 2026):

To help anyone else, the Crowdsec parser whitelist to mitigate this is the following:

/etc/crowdsec/parsers/s02-enrich/karakeep-whitelist.yaml

name: local/karakeep-whitelist
description: "Karakeep Whitelist"
filter: "evt.Meta.target_fqdn == 'karakeep.example.com' && evt.Meta.service == 'http' && evt.Meta.log_type in ['http_access-log', 'http_error-log']"
whitelist:
  reason: "Karakeep Whitelist"
  expression:
    - evt.Meta.http_verb == 'GET' && evt.Meta.http_status == '200' && evt.Parsed.request contains '/dashboard/preview'
    - evt.Meta.http_verb == 'GET' && evt.Meta.http_status == '200' && evt.Parsed.request contains '/dashboard/tags'

@kazoob commented on GitHub (Jan 2, 2026): To help anyone else, the Crowdsec parser whitelist to mitigate this is the following: `/etc/crowdsec/parsers/s02-enrich/karakeep-whitelist.yaml` ``` name: local/karakeep-whitelist description: "Karakeep Whitelist" filter: "evt.Meta.target_fqdn == 'karakeep.example.com' && evt.Meta.service == 'http' && evt.Meta.log_type in ['http_access-log', 'http_error-log']" whitelist: reason: "Karakeep Whitelist" expression: - evt.Meta.http_verb == 'GET' && evt.Meta.http_status == '200' && evt.Parsed.request contains '/dashboard/preview' - evt.Meta.http_verb == 'GET' && evt.Meta.http_status == '200' && evt.Parsed.request contains '/dashboard/tags' ```

kerem referenced this issue

2026-03-02 11:59:21 +03:00

[PR #1436] [MERGED] doc: document how to upgrade meilisearch / migrate meilisearch db #1825

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/karakeep#1333

No description provided.

Rows
Columns