I am currently integrating a third-party Web API into my frontend application. My site is hosted securely on HTTPS, but every time I trigger an API call, the browser console throws an error stating that the request has been blocked because it must be served over HTTPS. It seems like the API endpoint is using an insecure HTTP protocol. Is there a way to bypass this "Mixed Content" security policy in modern browsers like Chrome or Firefox, or do I need to implement a backend proxy to handle these requests?
3 answers
You could also try adding <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> to your HTML head. It tells the browser to automatically try to upgrade all HTTP requests to HTTPS before sending them.
This error is a security feature called "Mixed Content" blocking. Browsers strictly prevent an HTTPS site from making requests to insecure HTTP endpoints to protect user data from man-in-the-middle attacks. There is no client-side "bypass" for this that will work for your end-users. The correct fix is to use the HTTPS version of the API URL. If the provider doesn't support SSL, you must set up a server-side proxy. In this setup, your frontend calls your own secure server (Node.js, PHP, etc.), which then makes the insecure request to the API and passes the data back to you. This keeps the browser happy because the connection between the user and your server remains fully encrypted.
That makes sense for production, but I am seeing this while developing on my local machine. If I am running my dev server on localhost with a self-signed certificate, does the browser treat all outbound HTTP calls as blocked mixed content, or is there a specific flag I can toggle in the browser settings to ignore this during the testing phase of my project?
Mark, for local development, you can actually disable this check in Chrome by going to chrome://flags/#unsafely-treat-insecure-origin-as-secure and adding your origin. However, a better way is to use a tool like 'mkcert' to create a locally trusted SSL certificate. This way, your local environment mirrors production perfectly, and you won't be surprised by these blocks once you actually deploy your code to a live server.
I agree with Sandra, the upgrade-insecure-requests directive is a lifesaver if the API provider actually supports HTTPS but just has old links in their documentation. I tried this on my last project and it cleared up all the console warnings instantly without needing to rewrite every single fetch call manually.