HTTPS and redirects make phishing harder to spot because they remove the visual cues many users still associate with unsafe sites and help attackers hide the final destination. Encryption does not make a site trustworthy. Security teams should focus on URL reputation, browser isolation, authentication strength, and user training that teaches people to verify the domain, not the padlock.
How HTTPS changes the phishing problem, not the trust problem
HTTPS helps phishers blend in because the browser indicators people still use as shortcuts, like the lock icon, no longer tell you whether the site is legitimate. The real control question is whether the domain, certificate chain, and destination reputation match the brand being impersonated. W3C browser standards exist to make transport secure, but transport security is not the same as site authenticity.
That is why modern anti-phishing programs should treat HTTPS as a baseline transport property, not a trust signal. Attackers can register lookalike domains, obtain valid certificates, and present a polished login page while still harvesting credentials or tokens. The better question is whether the site is expected, whether the domain is consistent, and whether the authentication step is resistant to replay or credential theft.
When users are trained to equate “https” with “safe,” phishing becomes easier to execute and harder to interrupt. The defensive shift is toward domain verification, browser-based isolation, and stronger authentication methods that reduce the value of whatever is captured on the fake page. NIST SP 800-63 Digital Identity Guidelines are useful here because phishing-resistant authenticators change what an attacker can do after a user lands on a convincing site.
Why redirects obscure the final destination and defeat casual inspection
Redirect chains are attractive to phishers because they decouple the visible link from the page that actually collects the credentials. A user may see a benign-looking domain, a shortened URL, or a compromised legitimate site first, then be forwarded to the phishing page after the click already feels safe. That makes static email filters and simple URL blocklists less reliable.
Redirects also complicate analysis for defenders. The initial URL may be low risk, but the final hop may be transient, region-specific, or only activated after a particular user agent or referrer is seen. This creates a moving target for reputation systems and gives attackers room to rotate infrastructure without changing the lure that users first inspect.
For that reason, anti-phishing tooling should inspect the full redirect chain, not just the first visible URL. Security teams get better results when they combine link expansion, reputation checks on every hop, and browser controls that stop the user from reaching the terminal page if the chain resolves into suspicious infrastructure. OWASP Cheat Sheet Series is a practical reference for the authentication and session handling side of that defense, while NIST Cybersecurity Framework 2.0 fits the broader detect and protect response model.
Risk and Threat Considerations
HTTPS and redirects do not create trust, they create camouflage. The risk is that users, filters, and even some security workflows over-weight surface signals, then miss a convincing impersonation site until credentials, tokens, or MFA challenges have already been exposed.
Failure mechanism: An attacker combines a valid certificate, a lookalike or redirected domain, and a familiar login flow so the browser looks normal while the destination is fraudulent. The redirect path can also be used to evade simple URL reputation checks by delaying the malicious hop until the user has already clicked through.
Impact: The result is higher phishing success, weaker user suspicion, and more opportunities for account takeover, session theft, or downstream access abuse even when the initial connection is encrypted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-7 — Identity Management, Authentication and Access Control | Phishing defense depends on strong authentication, not padlock cues. |
| DE.CM-8 — Monitoring for Unauthorized Activities | Redirect chains and fake login pages require detection across the full path. | |
| Recommendation — Use phishing-resistant authentication and enforce access decisions beyond URL appearance. Monitor web traffic and user activity for suspicious redirect chains and credential-harvest behavior. | ||
| CIS Controls v8 | 6.3 — Require MFA for Externally-Exposed Applications | Stronger auth reduces the value of credentials stolen from phishing pages. |
| 9.7 — Filter Network Traffic | Filtering and inspection help identify malicious destinations behind redirects. | |
| Recommendation — Require MFA on exposed access paths and prefer phishing-resistant factors where possible. Inspect and filter web traffic to block known malicious destinations and suspicious redirect behavior. | ||
| NIST SP 800-63 | 6 — Authentication and Lifecycle Management | Phishing-resistant authentication directly reduces the impact of lookalike HTTPS sites. |
| Recommendation — Adopt phishing-resistant authenticators and verify the authenticating domain before trusting the login flow. | ||
| MITRE ATT&CK | T1185 — Browser Session Hijacking | Phishing over HTTPS often aims to steal live sessions or tokens after trust is gained. |
| Recommendation — Detect browser-session theft and block reuse of stolen sessions after phishing. | ||
Practitioner Guidance
What to verify: Train users and analysts to verify the actual registrable domain, not the padlock or the first URL they see. If the destination changes during redirects, inspect the final landing page and the full chain before allowing access or trusting a screenshot.
Decision rule: If a phishing defense depends on users noticing an insecure connection, it is too weak. Prioritise controls that still work when the site is HTTPS-enabled, including reputation checks, browser isolation, and phishing-resistant authentication.
Practitioner takeaway: The important distinction is between encrypted delivery and trusted destination, because attackers can use both HTTPS and redirects to make a malicious site look ordinary long enough for the user to authenticate.
