How can I enable HTTP in Safari settings

I had exactly the same issue.

I managed to solve it by switching off “Not Secure Connection Warning” in Safari settings.

Settings App > Safari > Scroll to the Privacy & Security section > toggle off Not Secure Connection Warning

Hope this helps :-)

On a Mac, you can find this setting under the Security tab. Disable "Warn before connecting to a website over HTTP".

The latest version of Safari, v18.2 released in December, introduced this warning. It also introduced some features that will try HTTPS first and fallback to HTTP. From the release notes: Safari 18.2 Release Notes | Apple Developer Documentation

I only started seeing this today, but it might be due to the timing of when this update was (quietly) installed on my Mac.

I agree that this is a bug because this should be just a warning that lets you continue to the site and doesn't stop you from browsing. I've tried modifying other settings in Safari, but nothing else seems to let you through.

In the long run, it's best to ask the website owners to enable HTTPS and turn this warning back on, for our own security. This is the way....

HalfordZooming wrote:

lkrupp wrote:

It means of course that the website you are trying to access is insecure and not protected in any way from malware, hacking, and remote intrusions. It’s likely very dangerous to try and load that URL.

No, that is not what it means at all. It means that your connection to that website is not encrypted. That is all. On a website that only serves static content that is not personally sensitive, this has no security implications at all, because such as site wouldn't be vulnerable to malware or hacking anyway. But obviously if you are sending password, credit card numbers, any personal data of any kind to the site, then you would want that data encrypted.

Conversely, a site having the most highly-verified SSL certificate ONLY assures you that your connection to it is encrypted. It does not tell you that they don't have an open telnet port giving all and sundry access to their inner mcgubbins.

Those two are two ways to reference the same general risks, with different phrasing used.

With or without TLS, the web server itself might be secure, or might not.

No TLS means any website logins or tokens can be compromised, yours, others’, and the website maintainers’.

No TLS that it’s easier to determine what you are accessing on the web server or web page, and that access alone can potentially be sensitive, or can become sensitive.

No TLS also means the connection to the website is open to shenanigans by those with intermediary access, and it can mean you’re not even accessing the intended website. Or worse, you are, but somebody else can be “helping”. That “helping” access has happening with Tor, and may still be happening in places — Windows executables being transferred by non-HTTPS / non-TLS Tor connections were being dynamically-infested with malware.

No TLS also means password managers can potentially be fooled, though most of those should hopefully not pre-populate forms on an insecure webpage.

The DV and EV stuff isn’t something that most folks even recognize, though the math vendors are still happy to sell their more expensive EV McGuffins. For most folks, locked and blocked are the usual extent.

As for the OP and their question, check whether that web server itself is sending the Strict Transport Security header. That’ll cause this, should the website also return a mixture of HTTPS and HTTP.

If it’s not the OP’s website, contact the website maintainers. Or contact Fortinet, if it’s Fortinet gear and running current firmware.

Fortinet gear has been problematic for a while, and mixed transport security headers wouldn’t surprise, given some of the other errors recently surfaced in that gear.