Ytdyklly

I just join a project, and while browsing the code, I realize that some links redirect to another web page, in HTTP instead of HTTPS.

The linked website has an https version, and there was no reason to not use it so I fix the issue.

However, the first website is on production, so we should avoid rebuilding the whole server for minor correction but rather wait to regroup several minor fixes.

I'm just wondering if this is a minor fix, or if leading users to an HTTP website is a major problem.

The linked website is a showcase website belonging to the company I work for, and there is no interaction such as logging into an account, so I guess while man in the middle attack is still possible, there is no sensible content/data to steal. Besides that, the link is in the footer of the first website, and the website itself doesn't have major traffic, so the number of people clicking it shouldn't be that high

How critical is it? Can such issue wait several days, or should it be fixed as soon as possible?

In general, the risk is low, as other answers here indicate. However, there is a scenario where risk is introduced:

• You have session tokens being passed as cookie data


• The cookies are scoped in such a way that the other (non-https) site has access to them


• The cookies do not have the secure flag set

In the case that all of those are present, the session tokens may be intercepted via man-in-the-middle (MiTM) attack; since the browser will send them to the other site automatically, and they will be sent in plain text rather than over the encrypted HTTPS stream.

That's a fairly specific set of criteria, and MiTM attack is semi-tough to pull off, so how much real risk this presents should be decided based on 1) whether your site has all 3 of those criteria present, and 2) how sensitive the information in your application is.

If your website is purely static and doesn't contain any login or sensitive data, then the risk on a technical level is likely low, and may not warrant an out of cycle fix.

On the other hand there's a risk to reputation. If your business relies on a reputation of being "secure" then it may look bad to potential customers/clients that you aren't following best practices (https everywhere).

EDIT: As per Jason Ross' answer I should also mention that leaking credentials through cookies is possible when a user visits the insecure website, and has logged into a web app on the same domain and the cookies were also improperly set (missing SECURE bit)

In many modern enterprise deployment scenarios application developers do not worry about https at all as this is a concern of the infrastructure team. In these cases SSL is terminated on the Load Balancer, and the certs are managed by the infrastructure team. The Load Balancer also would serve the http -> https redirect by default.

With this view of the world, where the app redirects to does not really matter that much. For consistency it's better to use the current protocol and not http or https specifically, so your application works equally well in dev (without tls) or in prod (with tls).