.jpeg){kind=small}
The Hypertext Transfer Protocol (HTTP) and the Hypertext Transfer Protocol Secure (HTTPS) are data communication protocols for the internet. HTTPS uses encryption algorithms for secure data transfer. Without encrypted communications, information transfer is not protected and sensitive data becomes vulnerable to attackers.
This article includes a brief overview of HTTPS, as well as actions you can take to ensure that you have set up HTTPS redirection for your website. Migrating your site to use HTTPS is a cybersecurity best practice.
What is the Hypertext Transfer Protocol Secure (HTTPS)?
HTTPS uses Transport Layer Security (TLS), formerly Secure Sockets Layer (SSL), for encryption and authentication between servers. Your website will need an SSL/TLS certificate to use HTTPS.
A uniform resource locator (URL) is the most common type of uniform resource identifier (URI). Websites URLs provide the domain name that corresponds to an IP address where the website is located. Users can then connect to that website because Domain Name System (DNS) provides the appropriate routing to your site. Websites can be accessed over HTTP or HTTPS, though the HTTPS protocol is recommended for security purposes.
Because HTTP traffic is not encrypted, any data being transferred is not secure. Malicious actors could then intercept sensitive data, such as user login credentials or eCommerce payment information, and misuse it for their own purposes. An organization's responsibility to users and customers necessitates that the organization take recommended steps to ensure a trusted user experience.
Requiring HTTPS and enforcing HTTPS Strict Transport Security (HSTS) protects your users' privacy and builds confidence that users can trust your organization's security policies to protect their data. Search engines will also assess HTTPS for your search engine optimization (SEO) ranking.
Most website owners will set up HTTPS for their site. When entering a website into your browser's search bar, most people typically don't supply the [.rt-script]https://[.rt-script] front matter, though many websites will load the secure HTTPS connection (which displays a padlock next to the URL). This padlock appears only if the site has been set up with HTTPS.
If a website does not have HTTPS enabled, most browsers will load a warning that the site is not secure. If you load a site that provides warnings about the lack of protection, you should proceed with caution before sending any information. Some sites will even be identified as unsafe or dangerous. When you receive a full-page warning, you should consider avoiding that site entirely. Chrome and Chromium-based browsers provide two separate warnings about the lack of security: an informational not secure versus a dangerous not secure.
If you can access your site over HTTP, then your users can likely do that as well. You should take action to ensure encrypted sessions over HTTPS.
Common HTTP and HTTPS Findings
When configuring your HTTPS policies for encrypted communications, you should also ensure that HTTP is not available for connections. Enforcing a strict HTTPS policy will ensure that your users are always connecting over HTTPS so that their credentials and other sensitive information remain encrypted.
It is possible, however, that you may forget to disallow HTTP connections and not notice it for some time. A continuous monitoring tool, such as UpGuard Breach Risk, can help you identify if your assets are using HTTPS or if they still allow traffic over HTTP.
UpGuard Breach Risk scans for a variety of HTTP/HTTPS risks and notifies users of any assets impacted by these common risk findings:
- HTTPS redirect not supported
- HTTP does not redirect to HTTPS
- HTTP Strict Transport Security (HSTS) not enforced
- HTTP port open
- HttpOnly cookies not used and Secure cookies not used
Without HTTPS redirection, users may be able to establish unencrypted connections and pass sensitive data in plain text. Ensure that HTTP redirects to HTTPS so that only encrypted connections are allowed, thus protecting users' data. If HTTP remains available on your website in any method, then even your existing HTTPS integrity could be undermined.
Sometimes called the HTTP Still Available check, a lack of HTTPS redirection means your web server will deliver a page accessed over the HTTP port ([.rt-script]80[.rt-script]). As a result, your server will fail this security check. A proper redirect response from the HTTP port to the HTTPS post ([.rt-script]443[.rt-script]) will pass this check.
If your site includes cookies for session management, user personalization, or analytical tracking, you may need to update your cookie headers to accommodate secure data transfer. Secure cookie configuration protects cookies in transit from being intercepted as plaintext.
You can also set up HTTP Strict Transport Security (HSTS) to require the use of HTTPS so that no HTTP connections are allowed from the server. UpGuard also scans for these HSTS findings:
- HTTP Strict Transport Security (HSTS) not enforced
- HSTS header does not contain include SubDomains
- Domain was not found on the HSTS preload list
The HSTS findings indicate if you need to update your configuration settings to enforce the redirection, specify subdomains of your domain, and adhere to the requirements of the HSTS Preload list.
Additionally, UpGuard scans for TLS/SSL findings, such as the SSL not available risk and risks related to SSL certificate expiration. Without a current SSL certificate, your users will be unable to authenticate over HTTPS connection.
How to Mitigate HTTP/HTTPS Risk Exposure
Once you understand the HTTP/HTTPS risk exposure in your external attack surface, you can take action to improve your encryption methods and protect your external attack surface.
Ensure that server-side policies are in place to reroute HTTP connections to their HTTPS counterpart. Different server setups and hosting platforms require different approaches to your configuration files. Some commonly-used setups include the following options:
- For some websites, the [.rt-script].htaccess[.rt-script] file can be modified to reroute requests to HTTPS. For a shared web hosting platform, you can update the [.rt-script].htaccess[.rt-script] file from your cPanel. Be sure to set the redirect conditions with a rewrite rule.
- If you use an Nginx web server, you may need to update the server block in your config files. Ensure that you set the [.rt-script]server_name[.rt-script] directive with your domain (such as [.rt-script]server_name domain.com www.domain.com[.rt-script], replacing "domain.com" with your domain).
- If you use an Apache web server, you can set up the redirect in the Virtual Host config file.
- For Microsoft Internet Information Services (IIS), the URL Rewrite module will allow you to redirect HTTP requests to HTTPS.
- You can use an available plugin for WordPress sites or manually update your site settings.
Enable HTTP Strict Transport Security (HSTS) to force HTTPS connections to an HTTPS version of your site and block all attempts at unencrypted communication. To set up HSTS, create a valid HSTS header with the following parameters:
[.rt-script]Strict-Transport-Security: max-age=63072000; includeSubDomains; preload[.rt-script]
Include the [.rt-script]Strict-Transport-Security[.rt-script] header for your system and specify the following informations:
- The [.rt-script]includeSubDomains[.rt-script] directive ensures that all subdomains on the system will use HTTPS.
- Include [.rt-script]preload[.rt-script] if you have submitted your domain to the Chromium HSTS preload service, which will automatically make connections using HTTPS for most browsers. Note that the HSTS preload list deployment docs recommend against including preload by default as it may impact subdomain access.
- Provide a [.rt-script]max-age[.rt-script] value that defines how long (in seconds) that a browser should remember to access the site exclusively over HTTPS. If you intend to submit your domain to the HSTS preload service, the [.rt-script]max-age[.rt-script] should be set to at least one year ([.rt-script]31536000[.rt-script] seconds), though two years ([.rt-script]36072000[.rt-script] seconds) is the value recommended by the HSTS preload service requirements.
If your application or web server distributes cookies, configure your settings to require the [.rt-script]Secure[.rt-script] and [.rt-script]HttpOnly[.rt-script] attributes and confirm that your SSL certificate is properly configured. The [.rt-script]Secure[.rt-script] attribute restricts authentication cookies to encrypted channels only. The [.rt-script]HttpOnly[.rt-script] attribute ensures that only the web browser can access cookies, which establishes a level of protection against cross-site scripting attacks (also known as XSS attacks). You can use the [.rt-script]Set-Cookie[.rt-script] HTTP response header syntax to specify attributes, as with the following code:
[.rt-script]Set-Cookie <name>=<value>; Domain=<domain-value>; Secure; HttpOnly[.rt-script]
Supply the cookie name, cookie value, and your domain value. You can optionally add expiration attributes, required paths, same-site or cross-site requests, and other attributes in your [.rt-script]Set-Cookie[.rt-script] header.
Once you have updated your HTTPS redirection, you can update your sitemap and provide the HTTPS URL to Google Analytics, AdSense, and Search Console. Providing the HTTPS URL update to analytics platforms will provide improved tracking for the HTTPS version of your site.
Additional auditing, such as penetration testing or regular analysis of network security logs, can uncover any additional HTTP (port [.rt-script]80[.rt-script]) connections being made.
How UpGuard Can Help
UpGuard Breach Risk scans for a variety of HTTP/HTTPS risks, including HTTP Still Available and HTTPS redirect not supported. If you receive any of these findings, our system identifies which of your domains and IP addresses are missing the redirect policy and still provide access through HTTP URLs. You can identify which domains or IP addresses are impacted and ensure that you update the configuration settings.
Current UpGuard users with the Breach Risk feature can log in and access their Risk Profile to search for these risks among their assets. You can reach out to our support team to investigate and verify any HTTP/HTTPS findings that have been identified for your assets.
