Skip to content

Web Application Exposure

2 automated security scanners


Purpose: The HTTPS Redirection Enforcement Scanner validates that HTTP requests are properly redirected to HTTPS, ensuring all traffic uses encrypted connections and preventing exposure of sensitive data over unencrypted HTTP.

What It Detects:

  • HTTP to HTTPS Redirect Detection
    • Makes an HTTP request to the domain (port 80) and checks for a 301/302 redirect status.
    • Verifies that the redirect target is an HTTPS URL.
    • Flags domains where redirects are missing or do not use HTTPS.
  • Redirect Chain Analysis
    • Follows the chain of redirects to the final destination, counting the number of hops.
    • Flags excessive chains (> 2 hops) and detects potential loops in the redirection process.
  • Redirect Configuration Quality
    • Ensures that the redirect status code is either 301 (permanent) or 302 (temporary), with a preference for 301.
    • Checks if the redirect preserves both the path and query string, maintaining user context during navigation.
    • Validates the format of the Location header to ensure proper redirection.
  • Port 80 Response Behavior
    • Tests whether port 80 accepts connections and verifies that immediate redirects occur without serving any content.
    • Checks for potential information disclosure or unintended data exposure through HTTP.
  • HTTPS Accessibility
    • Verifies that the HTTPS URL is accessible, confirming SSL/TLS certificate validity and successful page loading.
    • Flags broken configurations where HTTPS does not function as expected.

Inputs Required:

  • domain (string): Fully qualified domain name (e.g., google.com)

Business Impact: Ensuring that all traffic is redirected to HTTPS from HTTP significantly enhances security by preventing the exposure of credentials, session cookies, and other sensitive data in transit over insecure connections. This helps mitigate risks associated with man-in-the-middle attacks, eavesdropping on network traffic, and leaking form data before encryption through HTTPS upgrade.

Risk Levels:

  • Critical: If HTTP requests are not redirected to HTTPS, credentials transmitted via HTTP could be intercepted and used for unauthorized access. Session cookies exposed over unencrypted channels can also be sniffed by malicious actors.
  • High: Mixed content warnings may appear on browsers due to the presence of both secure (HTTPS) and insecure (HTTP) resources on a page. This can degrade user experience and potentially expose sensitive information prematurely.
  • Medium: While not as severe, inadequate redirection configuration might lead to suboptimal security practices that could be exploited by less sophisticated attackers.
  • Low: Minimal risk for informational findings unless the scanner identifies specific issues with redirect handling or HTTPS accessibility.
  • Info: These are typically non-critical observations about the overall setup but can still guide improvements in security posture.

Example Findings:

  • A website fails to redirect HTTP requests to HTTPS, potentially exposing user credentials and session cookies transmitted over unencrypted channels.
  • The redirection chain includes more than two hops, which could indicate misconfigurations or malicious redirects that might be exploited for attacks like phishing or data interception.


Purpose: The HSTS Header Presence Scanner is designed to validate the implementation of the HTTP Strict Transport Security (HSTS) header on web applications. This scanner ensures that browsers always use HTTPS connections, thereby preventing SSL stripping attacks and protecting against protocol downgrade vulnerabilities.

What It Detects:

  • HSTS Header Detection: The scanner makes an HTTPS request to a domain and checks for the presence of the Strict-Transport-Security header in the response. If the header is missing or improperly formatted, it flags this as a configuration issue.
  • Max-Age Validation: The scanner extracts the max-age directive value from the HSTS header and verifies that it meets the recommended minimum duration (31536000 seconds = 1 year). It also flags short durations (< 6 months) and unreasonably long durations.
  • IncludeSubDomains Directive: The scanner checks for the includeSubDomains directive to ensure subdomain protection is enabled, as omitting this can lead to vulnerabilities.
  • Preload Directive: The scanner verifies if the preload directive is present, assessing eligibility for inclusion in browser preload lists like Chrome and Firefox. It also flags if the site meets the requirements but has not been submitted to these lists.
  • HSTS Policy Strength: The scanner calculates an overall policy strength score based on the completeness of the directives included in the HSTS header. It compares this against best practices and flags configurations that are considered weak or lacking in coverage.

Inputs Required:

  • domain (string): Fully qualified domain name (e.g., google.com). This is essential for making HTTPS requests to validate HSTS header presence and configuration.

Business Impact: Ensuring the HTTP Strict Transport Security header is correctly configured is crucial for web security, as it directly impacts the encryption of data in transit and the overall protection against various attacks that exploit insecure connections. Misconfigured or missing HSTS headers can lead to significant vulnerabilities, including SSL stripping attacks, man-in-the-middle attacks on initial requests, cookie hijacking, protocol downgrade attacks, and user vulnerability during their first visit before HSTS is cached by the browser.

Risk Levels:

  • Critical: Missing or misconfigured HSTS headers that do not enforce HTTPS usage can lead to severe vulnerabilities directly impacting data security and user trust.
  • High: Short max-age values (< 6 months) or improper configuration of includeSubDomains and preload directives can expose subdomains and initial HTTP requests to significant risks, potentially leading to unauthorized access and data leakage.
  • Medium: Incomplete or improperly configured HSTS policies may not fully protect users against protocol downgrade attacks but still pose a risk compared to well-configured policies.
  • Low: While less severe, incomplete configurations can still be improved for enhanced security without immediate critical issues.
  • Info: Informal findings might include non-critical syntax errors or minor misconfigurations that do not significantly impact security but could benefit from optimization.

Example Findings:

  • A website has a missing HSTS header, which is highly critical as it exposes all communications to potential SSL stripping attacks and initial HTTP request hijacking.
  • An HSTS policy includesSubDomains directive is absent, increasing the risk of subdomain vulnerabilities significantly.
  • The max-age value in the HSTS header is set to only 30 days, which is considered a high severity issue as it fails to provide adequate protection against protocol downgrade attacks and user vulnerability on initial visits.