Is your feature request related to a problem?
I would like Gokapi to optionally log failed password attempts for password-protected download links.
A useful log entry could look like this:
[download-auth] Invalid password attempt for file ID <file-id> by IP <client-ip>, Useragent <user-agent>
or similar.
The log entry should include:
- timestamp
- file ID
- optionally the file name
- client IP
- user agent
The submitted password itself should never be logged.
This would make it possible to monitor repeated password guessing attempts against protected public download links and integrate this with tools such as CrowdSec, fail2ban, SIEM systems or custom alerting.
Ideally, this could either be enabled by default as a normal security-relevant log event, or controlled through a configuration option such as:
LogFailedDownloadPasswordAttempts = true
The goal is to make failed download password attempts as visible as failed admin login attempts already are.
Describe the solution you'd like
I considered detecting this at the reverse proxy level, for example through Nginx Proxy Manager / Nginx access logs.
However, failed password attempts for protected download links appear to be difficult to identify reliably there. They may only show up as repeated POST requests to the download endpoint, often still returning HTTP 200. This makes it hard to distinguish wrong password attempts from normal application behavior without relying on fragile heuristics such as response length, request path patterns or timing.
I also considered using CrowdSec or fail2ban rules based on reverse proxy logs, but without a clear application-level log event, such rules would have a higher risk of false positives.
For this reason, an explicit Gokapi log entry for failed password attempts would be much cleaner, safer and easier to integrate with existing security tooling.
Describe alternatives you've considered
No response
Additional Context
No response
Impact
Is your feature request related to a problem?
I would like Gokapi to optionally log failed password attempts for password-protected download links.
A useful log entry could look like this:
or similar.
The log entry should include:
The submitted password itself should never be logged.
This would make it possible to monitor repeated password guessing attempts against protected public download links and integrate this with tools such as CrowdSec, fail2ban, SIEM systems or custom alerting.
Ideally, this could either be enabled by default as a normal security-relevant log event, or controlled through a configuration option such as:
The goal is to make failed download password attempts as visible as failed admin login attempts already are.
Describe the solution you'd like
I considered detecting this at the reverse proxy level, for example through Nginx Proxy Manager / Nginx access logs.
However, failed password attempts for protected download links appear to be difficult to identify reliably there. They may only show up as repeated
POSTrequests to the download endpoint, often still returning HTTP 200. This makes it hard to distinguish wrong password attempts from normal application behavior without relying on fragile heuristics such as response length, request path patterns or timing.I also considered using CrowdSec or fail2ban rules based on reverse proxy logs, but without a clear application-level log event, such rules would have a higher risk of false positives.
For this reason, an explicit Gokapi log entry for failed password attempts would be much cleaner, safer and easier to integrate with existing security tooling.
Describe alternatives you've considered
No response
Additional Context
No response
Impact