[FEATURE]Expose ModSecurity CRS URI Exclusions (MODSEC_CRS_EXCLUSION_URIS)

[malosaaa]

What's needed and why?

Feature Request: Expose ModSecurity CRS URI Exclusions (MODSEC_CRS_EXCLUSION_URIS) in Web UI or config file.

What's needed and why?*

We need the ability to configure MODSEC_CRS_EXCLUSION_URIS directly within the BunkerWeb Web UI.

Why this is needed:

Many modern web applications, particularly those acting as API endpoints or OpenID Connect (OIDC) providers (like Authelia), rely on machine-to-machine communication for their core functionality. When BunkerWeb's ModSecurity (Core Rule Set) is enabled, its generic WAF rules can inadvertently block or challenge these legitimate API requests.

This often leads to errors where the client (e.g., Headscale, another application) receives an HTML response (such as a CAPTCHA page, an error page, or a default "nothing to see here" page) instead of the expected JSON or API response. This breaks automated processes like OIDC discovery, token exchange, and session validation.

Currently, MODSEC_CRS_EXCLUSION_URIS exists as an environment variable (for Docker Compose deployments), but it is not accessible through the Web UI. This forces users who deploy BunkerWeb in environments where environment variables are not easily managed (e.g., direct installations in Proxmox LXCs, or those who prefer UI management) to:

1. Completely disable ModSecurity for the affected domain, sacrificing valuable Web Application Firewall (WAF) protection.
2. Adopt more complex deployment methods (like Docker Compose) solely to set this one crucial variable.

Exposing this setting in the Web UI would provide essential granular control, allowing users to apply robust WAF protection to human-facing interfaces (like login portals) while ensuring critical API-driven authentication and application flows remain uninterrupted. This is vital for maintaining both security and application functionality.

Implementations ideas (optional)

Implementations ideas (optional)

A straightforward implementation would be to add a new input field or a multi-line text area within the "ModSecurity" or "Security Tuning" section of the Web UI.

This field could be labeled something like:

• "ModSecurity CRS Excluded URIs"
• "Paths to Bypass ModSecurity CRS"
• "WAF Rule Exclusions (URI)"

Users would then input a space-separated (or comma-separated, or one-per-line) list of URI paths.

Example for Authelia OIDC Integration:
For an OIDC provider like Authelia, the following paths are frequently accessed by machines and should typically be excluded from ModSecurity CRS processing to ensure proper OIDC flow:

• /.well-known/openid-configuration
• /api/oidc/token
• /api/oidc/jwks
• /api/oidc/authorization
• /api/state
• /api/firstfactor
• /api/secondfactor
• /api/logout

Same for GRAFANA whats even worse, and keeps me banned all the time.

This feature would significantly enhance the usability and security posture of BunkerWeb for a wider range of application integrations without requiring advanced CLI or deployment knowledge.

Code of Conduct

• I agree to follow this project's Code of Conduct

[TheophileDiot]

Hi @malosaaa, there are no MODSEC_CRS_EXCLUSION_URIS setting that exists. If you want to write ModSecurity you can follow this guide: https://docs.bunkerweb.io/latest/advanced/#custom-configurations_1