[BUG] HTTPS redirect setting ignored for copied service configurations

[MB-Finski]

What happened?

If a previously existing service configuration is copied using the UI, the http -> https redirection setting is not respected even though the UI still shows the redirection setting as enabled. I'd consider this as a security issue since sensitive traffic may be unencrypted despite the UI showing otherwise.

How to reproduce?

1. Create a service configuration with the "Redirect HTTP to HTTPS" setting enabled.
2. Copy said service configuration using the UI copy button and enter a different host/domain.
3. The new service can now be accessed over http with no 301 redirect response.
4. The UI still shows the redirect option as enabled for both services.

If the redirect setting is disabled and then re-enabled while saving the config in between then the http traffic is redirected to https as expected.

I'm not aware, as of yet, if this bug applies to more settings besides just the http to https redirect.

Configuration file(s) (yaml or .env)

N/A

Relevant log output

N/A

BunkerWeb version

1.5.12

What integration are you using?

Linux

Linux distribution (if applicable)

Debian 12

Removed private data

• I have removed all private data from the configuration file and the logs

Code of Conduct

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

[TheophileDiot]

Hi @MB-Finski, thank you for opening this issue. I have multiple questions:

• Is the cloned service using HTTPS at all ?
• Was it auto redirect HTTP to HTTPS or the manual redirection ?

[MB-Finski]

Thanks for the reply.

• Yes, it is possible to connect to the cloned service using https, too.
• Manual redirection (both options, i.e. manual/auto, are checked, in fact)

[TheophileDiot]

I can confirm that this behavior isn't present in the 1.6.0-beta release

[MB-Finski]

Just noticed a separate but loosely related bug: whitelisting the client also completely disables the redirect regardless of any redirect settings. This, however, is not the cause of the original bug in this issue (it occurs even when the whitelist is empty).