Security Issue: Basic Auth allows plaintext password submission over HTTPS when internal IP is allowed via Access List (satisfy any)

[robeston]

Description:
I have identified a significant security flaw when using the Nginx Proxy Manager (NPM) in a Docker environment (specifically tested on OMV7) with both SSL/TLS enforcement and Access Lists (Basic Auth + IP Whitelisting) enabled.
The Issue:
When configuring a Proxy Host with:
SSL/TLS Enabled (Force SSL/TLS is checked, a valid internal domain certificate is used).
An Access List that uses Satisfy: Any (Basic Auth username/password AND an internal IP range like 192.168.1.0/24 are allowed).
The browser initiates a HTTPS connection to the correct domain name. The Basic Auth prompt appears as expected. However, the browser warns that the passwords could be stolen, and the padlock icon indicates an insecure connection during the login phase. The password is being sent in plaintext or over an unauthenticated HTTPS channel.
The SSL certificate seems to only fully activate after successful authentication and redirection to the destination website.
Analysis of the Root Cause:
It appears the Nginx configuration logic prioritizes the satisfy any directive in a way that the internal IP whitelisting condition is met before the full SSL handshake or certificate validation is enforced during the Basic Auth prompt. The Nginx server seems to accept the request based on the source IP (which originates from the Docker internal network or the local client IP), bypasses the strict SSL requirement for the authentication prompt itself, and only applies full security after the request is processed and forwarded to the backend.
Expected Behavior:
The Nginx server should enforce a fully secure, authenticated HTTPS connection (verified certificate) before the Basic Auth prompt is displayed. The password should only ever be transmitted over a fully encrypted, secure channel.
Current Workaround (Confirms the issue):
The only way to achieve a secure login is by manually using the "Custom Nginx Configuration" tab to explicitly enforce the auth_basic directive and the if ($scheme = http) { return 301 https://$host$request_uri; } logic, overriding the default Access List behavior.
Request:
This behavior is a security vulnerability by default. The NPM Access List logic should ensure that HTTPS security is fully established and verified before authentication attempts are processed, regardless of the satisfy any or IP whitelist rules. This should be fixed in the core application logic.