TL;DR
An HTTPS site is vulnerable to attacks originating from an HTTP page within the same browser session if proper security measures aren’t in place. This guide explains how this can happen and provides steps to mitigate the risk.
Understanding the Problem
When a user navigates from an insecure (HTTP) page to a secure (HTTPS) page, the browser doesn’t automatically reset all security contexts. Information like cookies, local storage data, and potentially session tokens can persist from the HTTP context, creating opportunities for malicious attacks.
Steps to Mitigate Attacks
- Implement Strict Transport Security (HSTS): HSTS forces browsers to always use HTTPS when communicating with your site. This prevents initial connections via HTTP.
- Add the following header to your web server configuration:
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" - Important: Ensure all subdomains are also served over HTTPS before enabling
includeSubDomains. Consider using an HSTS preloader list (hstspreload.org) for wider browser support.
- Add the following header to your web server configuration:
- Use Secure Cookies: Configure cookies with the following attributes:
- Secure: Ensures the cookie is only sent over HTTPS connections.
- HttpOnly: Prevents JavaScript from accessing the cookie, reducing XSS attack risks.
- SameSite: Controls how cookies are sent in cross-site requests. Set to
StrictorLaxfor better protection against CSRF attacks.Set-Cookie: sessionid=value; Secure; HttpOnly; SameSite=Strict
- Session Management Best Practices:
- Regenerate Session IDs on Protocol Change: When a user switches from HTTP to HTTPS, invalidate the old session ID and create a new one. This prevents attackers from using an existing session ID obtained over HTTP.
// Example in PHP: if ($_SERVER['HTTPS'] != 'on') { session_regenerate_id(true); } - Short Session Timeout: Reduce the duration of session cookies to minimize the window of opportunity for attackers.
- Avoid Storing Sensitive Data in Cookies: If possible, store sensitive data on the server-side and use a secure session ID to identify the user.
- Regenerate Session IDs on Protocol Change: When a user switches from HTTP to HTTPS, invalidate the old session ID and create a new one. This prevents attackers from using an existing session ID obtained over HTTP.
- Content Security Policy (CSP): CSP helps prevent XSS attacks by controlling which resources the browser is allowed to load.
- Configure your web server to send a CSP header:
Header set Content-Security-Policy "default-src 'self'" - Adjust the policy based on your application’s needs. A stricter policy provides better security but may require more configuration.
- Configure your web server to send a CSP header:
- Cross-Origin Resource Sharing (CORS): Properly configure CORS to restrict which origins can access your resources. This prevents malicious scripts from making unauthorized requests.
- Ensure that only trusted origins are allowed in the CORS policy.
- Regular Security Audits and Penetration Testing: Regularly scan your website for vulnerabilities and conduct penetration testing to identify potential weaknesses.
Important Considerations
Always keep your web server software, frameworks, and libraries up-to-date with the latest security patches. Educate developers about common web security threats and best practices.

