1. Home
  2. Web App Vulnerabilities
  3. How to remediate – Basic Authentication Without HTTPS

How to remediate – Basic Authentication Without HTTPS

1. Introduction

Basic Authentication Without HTTPS occurs when a web server uses Basic authentication without encrypting the connection with HTTPS. This means usernames and passwords are sent in plain text, allowing attackers to intercept them if they monitor network traffic. Businesses face risks of data breaches, account compromise, and reputational damage. Systems commonly affected include web servers and applications using HTTP-based authentication. Confidentiality is at high risk, integrity is compromised due to potential manipulation of credentials, and availability may be impacted by service disruption following a breach.

2. Technical Explanation

The vulnerability stems from transmitting Basic authentication headers over an unencrypted channel (HTTP). An attacker can use network sniffing tools to capture the ‘Authorization’ header containing base64-encoded credentials. The preconditions for exploitation are simply that the web server accepts Basic authentication and traffic is not encrypted with HTTPS. A realistic example involves a user logging into a web application using HTTP; an attacker on the same network captures their username and password.

  • Root cause: Lack of encryption when transmitting sensitive credentials via HTTP Basic Authentication.
  • Exploit mechanism: An attacker intercepts the HTTP traffic containing the base64-encoded username and password, decodes it, and uses the credentials to gain unauthorized access.
  • Scope: Web servers and applications using HTTP Basic authentication without HTTPS.

3. Detection and Assessment

Confirming vulnerability involves checking if Basic authentication is used over HTTP. A quick check can be performed through browser developer tools, while a thorough method uses network analysis.

  • Quick checks: Inspect the request headers in your browser’s developer tools when logging into an affected application. Look for ‘Authorization: Basic …’.
  • Scanning: Nessus plugin ID 10384 can identify this vulnerability, but results should be verified manually.
  • Logs and evidence: Web server access logs may show authentication attempts over HTTP.
curl -v http://example.com/protected-resource

4. Solution / Remediation Steps

The solution is to enforce HTTPS for all traffic, including Basic authentication. This ensures credentials are encrypted in transit.

4.1 Preparation

  • Ensure SSL/TLS certificates are valid and correctly configured. A rollback plan involves reverting to the original HTTP configuration, but this leaves the vulnerability exposed.
  • A change window may be required for minimal downtime during certificate installation or configuration updates. Approval from security teams is recommended.

4.2 Implementation

  1. Step 1: Configure your web server to redirect all HTTP traffic to HTTPS.
  2. Step 2: Ensure Basic authentication only functions over HTTPS connections, disabling it for HTTP.
  3. Step 3: Restart the web service to apply changes.

4.3 Config or Code Example

Before

# Apache configuration - allowing HTTP Basic authentication without redirection
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /path/to/htpasswd
Require valid-user

After

# Apache configuration - redirecting all HTTP to HTTPS and enforcing Basic Authentication over HTTPS only
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /path/to/htpasswd
Require valid-user

4.4 Security Practices Relevant to This Vulnerability

Several security practices directly address this vulnerability type. Least privilege limits the impact of compromised credentials, while secure defaults ensure HTTPS is enabled by default. Patch cadence ensures timely updates to address known vulnerabilities in web server software.

  • Practice 1: Enforce least privilege for user accounts to minimize damage from credential compromise.
  • Practice 2: Implement secure defaults that require HTTPS for all sensitive communications.

4.5 Automation (Optional)

# Example Ansible task to redirect HTTP to HTTPS using a configuration file
- name: Redirect HTTP to HTTPS
  copy:
    src: /path/to/http_to_https.conf
    dest: /etc/apache2/sites-available/000-default.conf # Adjust path as needed
  notify: Restart Apache

5. Verification / Validation

Confirm the fix by verifying that Basic authentication only works over HTTPS and HTTP traffic is redirected. Use browser developer tools to check for HTTPS connections, and attempt to authenticate via HTTP to confirm redirection.

  • Post-fix check: Access the web application using HTTP; it should automatically redirect to HTTPS.
  • Re-test: Repeat the earlier detection method (curl -v) over HTTP; it should show a redirect response.
  • Monitoring: Monitor web server logs for any failed login attempts or unexpected HTTP traffic.
curl -v https://example.com/protected-resource

6. Preventive Measures and Monitoring

Update security baselines to require HTTPS, implement CI/CD pipeline checks to enforce secure configurations, and establish a regular patch review cycle. For example: CIS control 1.2 requires configuring web server settings for secure communication.

  • Baselines: Update your security baseline or policy to mandate HTTPS for all web applications.
  • Pipelines: Add checks in CI/CD pipelines to ensure that new deployments enforce HTTPS configurations.
  • Asset and patch process: Implement a regular patch review cycle (e.g., monthly) to address known vulnerabilities in web server software.

7. Risks, Side Effects, and Roll Back

Potential risks include service disruption during configuration changes or certificate issues. A roll back involves reverting the web server configuration to allow HTTP traffic again, but this reintroduces the vulnerability.

  • Risk or side effect 1: Incorrect SSL/TLS configuration can cause connection errors; verify certificates are valid and properly installed.
  • Risk or side effect 2: Redirect loops may occur if misconfigured; carefully review rewrite rules.
  • Roll back: Restore the original web server configuration file from backup, removing the HTTPS redirection rule. Restart the web service.

8. References and Resources

  • Vendor advisory or bulletin: OWASP Top Ten
  • NVD or CVE entry: N/A – this is a configuration issue, not a specific vulnerability with a CVE.
  • Product or platform documentation relevant to the fix: Apache Enable SSL
Updated on December 27, 2025

Was this article helpful?

Related Articles