Fixing mixed content


Fixing mixed content

1st Method 

Debug HTTPS Mixed Content Warnings
  1. Start Fiddler
  2. Clear the browser cache
  3. Hit CTRL+F5 to reload the page
  4. In Fiddler, click the Protocol column to sort by requests by protocol
  5. Determine which URLs have been delivered using HTTP
  6. Eliminate the use of those HTTP URLs or update any secure redirectors pointing to HTTP resources
By removing mixed content vulnerabilities, you can protect the integrity and privacy of the content on your secure pages, and avoid annoying your visitors with this security prompt.

 2nd Method

Contents

  1. Find and fix mixed content
  2. Handle mixed content at scale

TL;DR

  • Always use https:// URLs when loading resources on your page.
  • Use Content-Security-Policy-Report-Only header to monitor mixed content errors on your site.
  • Use upgrade-insecure-requests CSP directive to protect your visitors from insecure content.

Find and fix mixed content

Manually finding mixed content is rather simple, but can be time consuming depending on the number of issues you have. Chrome is used to describe the process here, however most modern browsers provide similar tools to help you with this process.

Finding mixed content by visiting your site

When visiting an HTTPS page in Google Chrome, the browser alerts you to mixed content as errors and warnings in the JavaScript console.
To see these alerts, visit the sample page from our passive mixed content or active mixed content examples, and open the Chrome JavaScript console. The console can be opened from the View menu, View -> Developer -> JavaScript Console or by right-clicking the page, selecting Inspect Element then selecting Console.
The passive mixed content example in our previous guide will cause mixed content warnings to be displayed, like the ones below:


Mixed Content: The page was loaded over HTTPS, but requested an insecure video. This content should also be served over HTTPS.

While the active mixed content example will cause mixed content errors to be displayed:


Mixed Content: The page was loaded over HTTPS, but requested an insecure resource. This request has been blocked; the content must be served over HTTPS.

The http:// URLs listed in these errors and warnings should be fixed in your site’s source, it helps to make a list of these URLs, along with the page you found them on, to help you fix them later.

Remember

  • Mixed content errors and warnings are only shown for the page your are currently viewing, and the JavaScript console is cleared every time you navigate to a new page. This means you will have to view every page of your site individually to find these errors. Some errors may only show up after you interact with part of the page, see the image gallery mixed content example from our previous guide.

Finding mixed content in your source code

You can search for mixed content directly in your source code. Search for http:// in your source and look for tags that include HTTP URL attributes. Specifically, you are looking for the tags listed in the mixed content types & security threats associated section of our previous guide. Note that having http:// in the href attribute of anchor tags () is often not a mixed content issue, with some notable exceptions discussed later.
If you have a list of HTTP URLs from Chrome mixed content errors and warnings, you can also search for these complete URLs in your source to find where they are included in your site.

Fixing mixed content

Once you’ve found where the mixed content is included in your site’s source, follow these steps to fix it.
Assuming you have the following mixed content error in Chrome:


Mixed Content: The page was loaded over HTTPS, but requested an insecure image. This content should also be served over HTTPS.
Which you found in source here:
 src="http://googlesamples.github.io/web-fundamentals/.../puppy.jpg">

Step 1

Check that the URL is available over HTTPS. Open a new tab in your browser, enter the URL in the address bar, and change http:// to https://
If the resource displayed is the same over HTTP and HTTPS, everything is OK, proceed to step 2.


HTTP image loads without error.
HTTPS image loads without error, and image is the same as HTTP. Go to step 2!
If you see a certificate warning, or if the content can’t be displayed over HTTPS, it means the resource is not available securely.


Resource not available over HTTPS.
Certificate warning when attempting to view resource over HTTPS.
In this case, you should consider one of the following options:
  • Include the resource from a different host, if one is available.
  • Download and host the content on your site directly, if you are legally allowed to do so.
  • Exclude the resource from your site altogether.

Step 2

Change the http:// URL to https://, save the source file, and redeploy the updated file if necessary.

Step 3

View the page where you found the error originally, verify that the error no longer appears.

Beware of non-standard tag usage

Beware of non-standard tag usage on your site. For instance, anchor () tag URLs don’t cause mixed content by themselves, as they cause the browser to navigate to a new page. This means they usually don’t need to be fixed. However some image gallery scripts overrides the functionality of the tag and load the HTTP resource specified by the href attribute into a lightbox display on the page, causing a mixed content problem.
 class="gallery" href="http://googlesamples.github.io/web-fundamentals/samples/
discovery-and-distribution/avoid-mixed-content/puppy.jpg">
   src="https://googlesamples.github.io/web-fundamentals/samples/discovery-and-distribution
/avoid-mixed-content/puppy-thumb.jpg">
Try full sample
In the code above, it may seem safe to leave the tags href as http://, however if you view the sample and click on the image, you’ll see that it loads a mixed content resources and displays it on the page.

Handle mixed content at scale

The manual steps above work well for smaller websites, but for large websites, or sites with many separate development teams, it can be tough to keep track of all the content being loaded. To help with this task, you can use content security policy to instruct the browser to notify you about mixed content and ensure that your pages never unexpectedly load insecure resources.

Content security policy

Content security policy (CSP) is a multi-purpose browser feature that you can use to manage mixed content at scale. The CSP reporting mechanism can be used to track the mixed content on your site; and the enforcement policy, to protect users by upgrading or blocking mixed content.
You can enable these features for a page by including the Content-Security-Policy or Content-Security-Policy-Report-Only header in the response sent from your server. Additionally, Content-Security-Policy (but not Content-Security-Policy-Report-Only) can be set using a tag in the section of your page. See examples in the following sections.
CSP is useful for many things outside of its mixed content uses, you can find more information about other CSP directives at the following resources:

Remember

  • Browsers enforce all content security policies they receive. Multiple CSP header values received by the browser in the response header or elements are combined and enforced as single policy; reporting policies are likewise combined. Policies are combined by taking the intersection of the policies; that is to say, each policy after the first can only further restrict the allowed content, not broaden it.

Finding mixed content with content security policy

You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.
Response header:
Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri 
https://example.com/reportingEndpoint
Whenever a user visits a page on your site, their browser sends JSON-formatted reports regarding anything that violates the content security policy to https://example.com/reportingEndpoint. In this case, anytime a subresource is loaded over HTTP, a report is sent. These reports include the page URL where the policy violation occurred and the subresource URL that violated the policy. If you configure your reporting endpoint to log these reports, you can track the mixed content on your site without visiting each page yourself.
The two caveats to this are:
  • Users have to visit your page in a browser that understands the CSP header. This is true for most modern browsers.
  • You only get reports for pages visited by your users. So if you have pages that don’t get much traffic, it might be some time before you get reports for your entire site.
For more information on CSP header format, see the Content Security Policy specification.
If you don’t want to configure a reporting endpoint yourself, https://report-uri.io/ is a reasonable alternative.

Upgrading insecure requests

One of the newest and best tools to automatically fix mixed content is the upgrade-insecure-requests CSP directive. This directive instructs the browser to upgrade insecure URLs before making network requests.
As an example, if a page contains an image tag with a HTTP URL:
 src="http://example.com/image.jpg">
The browser instead makes a secure request for https://example.com/image.jpg, thus saving the user from mixed content.
You can enable this behavior either by sending a Content-Security-Policy header with this directive:
Content-Security-Policy: upgrade-insecure-requests
Or by embedding that same directive inline in the document’s section using a element:
 http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
It is worth noting, that if the resource is not available over HTTPS, the upgraded request fails and the resource is not loaded. This maintains the security of your page.

No comments

Powered by Blogger.